From nobody Wed Jul 1 00:21:26 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 CE4F81B2A6E for ; Wed, 1 Jul 2015 00:21: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 Cc2xRb6JoM1t for ; Wed, 1 Jul 2015 00:21: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 0EE141B2A40 for ; Wed, 1 Jul 2015 00:21: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 40B2B16F7; Wed, 1 Jul 2015 09:21: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 4y7uKbRbGNWK; Wed, 1 Jul 2015 09:21: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, 1 Jul 2015 09:21:16 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E26022002B; Wed, 1 Jul 2015 09:21: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 FxU64u9wcHzU; Wed, 1 Jul 2015 09:21:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DF0B20013; Wed, 1 Jul 2015 09:21:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 50A6134E71B5; Wed, 1 Jul 2015 09:21:14 +0200 (CEST) Date: Wed, 1 Jul 2015 09:21:14 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150701072114.GA8001@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20150624145325.GB38016@elstar.local> <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@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 Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 07:21:24 -0000 On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: > >> > >> > On 30 Jun 2015, at 15:39, Juergen Schoenwaelder wrote: > >> > > >> > On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: > >> >> > >> >>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder wrote: > >> >>> > >> >>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > >> >>>> Juergen Schoenwaelder writes: > >> >>>> > >> >>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > >> >>>>>> Hi Juergen, > >> >>>>>> > >> >>>>>> thank you for the review. > >> >>>>>> > >> >>>>>> Juergen Schoenwaelder writes: > >> >>>>>> > >> >>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen wrote: > >> >>>>>>>> > >> >>>>>>>> This is a notice to start a NETMOD WG last call for the document "JSON Encoding of Data Modeled with YANG": > >> >>>>>>>> > >> >>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >> >>>>>>>> > >> >>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM EST. > >> >>>>>>> > >> >>>>>>> Hi, > >> >>>>>>> > >> >>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. > >> >>>>>>> > >> >>>>>>> - I am not sure I agree with the wording in section 3. Why is section > >> >>>>>>> 8.3.3 only applicable to XML encoded data? Validation applies to > >> >>>>>>> datastores. While constraints are defined using XML-based notations > >> >>>>>> > >> >>>>>> You are right that this section shouldn't talk about XML-encoded data, > >> >>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath > >> >>>>>> operates on the abstract, logical structure of an XML document, …". > >> >>>>>> > >> >>>>>> So I think a datastore needs to be represented, at least conceptually, > >> >>>>>> as XML infoset. > >> >>>>>> > >> >>>>>>> such as XPATH, how the validation is carried out is not defined in > >> >>>>>>> the YANG specifications. I guess I actually disagree with the > >> >>>>>> > >> >>>>>> I don't think this is true. YANG spec doesn't say how "must" and "when" > >> >>>>>> statements are evaluated, and relies on XPath. > >> >>>>> > >> >>>>> RFC 6020: > >> >>>>> > >> >>>>> When a datastore is validated, all "must" constraints are > >> >>>>> conceptually evaluated once for each data node in the data tree, and > >> >>>>> for all leafs with default values in use (see Section 7.6.1). If a > >> >>>>> data node does not exist in the data tree, and it does not have a > >> >>>>> default value, its "must" statements are not evaluated. > >> >>>>> > >> >>>>> [...] > > The text you substituted here with an ellipsis is actually quite > important for this discussion because it defines the context for XPath > evaluation (together with section 6.4), in particular the data tree on > which every XPath expression is evaluated. It is clear that the data > tree can also comprise state data, notification content or RPC > input/output, i.e. not only datastore content as you keep saying. > > Terms like "context node" refer to the XPath data model as described in > sec. 5 of the XPath spec: > > http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model > > (and section 6.4 in RFC 6020 says it explicitly). > > We need to know, at least conceptually, how to construct the XPath data > tree from JSON text. For example, it has to be clear that leaf-list > entries encoded as a JSON array appear as sibling nodes in the data > tree, otherwise a "must" constraint specified for the leaf-list won't > work correctly. I don't think this is anyhow evident and IMO it has to > be addressed. This is the purpose of section 3 in > draft-ietf-netmod-yang-json-04. > > Would it help if "validation" is replaced with "XPath evaluation" > throughout this section? No. I continue to believe (a) a datastore is validated and not an XML infoset (or something like that) and (b) that the evaluation of "must" constraints is conceptual. JSON is an encoding. It remains unclear why you think that the JSON encoding has any impact of what happens with a datastore. /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 Jul 1 00:48: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 C5B141B2B90 for ; Wed, 1 Jul 2015 00:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zSLkrnGMSpg for ; Wed, 1 Jul 2015 00:48:32 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C5D991B2B96 for ; Wed, 1 Jul 2015 00:48:31 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 87BCB1CC0337; Wed, 1 Jul 2015 09:48:36 +0200 (CEST) From: Ladislav Lhotka To: Alexander Kolchinsky , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 01 Jul 2015 09:48:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] YANG-JSON Encoding review comments 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 Jul 2015 07:48:37 -0000 Hi Alexander, thank you for reviewing the document. Alexander Kolchinsky writes: > My comments for reviewing: > > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > > > Comment #1: > > Question for section 4. > > Can I also use: > > > { > "barmod:top": { > "foo": 54, > "bar": true > } > } No, the "top" container is defined in "foomod" and thus belongs to its namespace. > > If barmod extends foobar:top, then barmod:top should also be valid, no? > > > Comment #2: > > Example: For the anyxml definition > > anyxml bar; > > the following is a valid JSON-encoded instance: > > "bar": [true, null, true] > > > > > I would rather have: > > > > > "bar": ""; > There have already been several ultra-long discussions about this in the NETMOD mailing list. The stance taken by this draft is that anyxml is just some data for which the schema is not known (in advance), or the schema is not YANG. The only requirement is that the document containing anyxml instance must remain valid for the given encoding. So JSON string may also be anyxml content but it's not limited to that. I believe this is a natural extension of the purpose that anyxml played when XML was the only encoding, and it can be used in the same way for other encodings that may be defined in the future, such as CBOR. The only problem, for me at least, is that it is a misnomer. > > My personal experience shows that it depends on what the client wants, and it should be controlled by the client. For example, it could be a union of different types: > > > (this will be encoded to whatever format is being used xml/json) > > anyxml (always embed xml with CDATA) > > anyjson (always embed json) > > anyxml-escaped (always embed xml escaped - no CDATA) This can be achieved using a choice. > > > > Comment #3: > > > It would be better to provide examples for sections 6.2-6.7 OK, I will add some. > > > Comment #4: > > > For section 6.8, it should be: > > > "type": "ietf-interfaces:ethernetCsmacd" > > > Not: > > > "type": "iana-if-type:ethernetCsmacd" > > > Because, the prefix is if, not ianaift. No, the identity "ethernetCsmacd" is defined in the "iana-if-type" module and belongs to its namespace, so "iana-if-type:ethernetCsmacd" is correct. https://tools.ietf.org/html/rfc7224#section-2 > > Comment #5: > > For section 6.10: > > What if we have: > > > leaf bar { > type union { > type uint64; > type string; > } > } > > > Then how can we determine which union this string refers to? If the string is syntactically correct uint64, it will be classified as such, otherwise it will be plain string. > > Seems like it would be more reliable to have a union selector: > > > "bar" { > > "union-selector": "uint64", > > "value": "99999999.99999" > > } I agree, but it is a deficiency of YANG union in general. I tried to propose the "type" annotation for this purpose: https://tools.ietf.org/html/draft-lhotka-netmod-yang-annotations-00#section-3.2 However, this idea didn't receive any support in the WG. Thanks, Lada > > > > > _______________________________________________ > 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 Jul 1 00:59:16 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 C47321B2BB4 for ; Wed, 1 Jul 2015 00:59: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 7ePccgXnBGyh for ; Wed, 1 Jul 2015 00:59: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 56E0D1B2BAD for ; Wed, 1 Jul 2015 00:59: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 CFC548C6; Wed, 1 Jul 2015 09:59:06 +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 VtoPd0hthPtF; Wed, 1 Jul 2015 09:59:07 +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 Jul 2015 09:59:06 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D22B2002B; Wed, 1 Jul 2015 09:59:07 +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 BYuIFrCubpE9; Wed, 1 Jul 2015 09:59: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 51A4C20013; Wed, 1 Jul 2015 09:59:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9593C34E7225; Wed, 1 Jul 2015 09:59:05 +0200 (CEST) Date: Wed, 1 Jul 2015 09:59:05 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150701075905.GA8073@elstar.local> Mail-Followup-To: Ladislav Lhotka , Alexander Kolchinsky , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Alexander Kolchinsky , "netmod@ietf.org" Subject: Re: [netmod] YANG-JSON Encoding review comments 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 Jul 2015 07:59:16 -0000 On Wed, Jul 01, 2015 at 09:48:31AM +0200, Ladislav Lhotka wrote: > > I would rather have: > > > > > > > > > > "bar": ""; > > > > There have already been several ultra-long discussions about this in the > NETMOD mailing list. The stance taken by this draft is that anyxml is > just some data for which the schema is not known (in advance), or the > schema is not YANG. The only requirement is that the document containing > anyxml instance must remain valid for the given encoding. So JSON string > may also be anyxml content but it's not limited to that. > > I believe this is a natural extension of the purpose that anyxml played > when XML was the only encoding, and it can be used in the same way for > other encodings that may be defined in the future, such as CBOR. The > only problem, for me at least, is that it is a misnomer. The WG settled this debate and there is no point in trying to start it again. The bottom line is that anyxml remains defined as it has been defined in RFC 6020 and that it is RECOMMENDED to use anydata for anything that is can be modelled in YANG since anyxml. /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 Jul 1 01:24:31 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 100301A005B for ; Wed, 1 Jul 2015 01:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_210=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 ITOZ8r43lrib for ; Wed, 1 Jul 2015 01:24:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A7A541A0041 for ; Wed, 1 Jul 2015 01:24:27 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6EEC41CC0337; Wed, 1 Jul 2015 10:24:32 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 01 Jul 2015 10:24:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 08:24:30 -0000 Hi Kent, thanks for reviewing the document. Kent Watsen writes: > [As an individual contributor] > > Already many comments have been made, hopefully he below comments are new: > > > 1. In Section 3, it says: > > "By advertising a YANG module in which metadata annotation A is > defined using the "md:annotation" statement, a server specifies > support for the syntax of annotation A. This means that > configuration or state data, RPC messages and notifications will be > considered syntactically valid if annotation A is attached to any > data node instance, provided that all rules stated in this document > are observed." > > > Does this mean that the annotation A can be used by *any* module > the server advertises, or just the modules that define/import > annotation A? For all modules implemented by the server, no import is needed. > > For example, could a YANG module be defined like this: > > module example-color-text { > namespace "http://example.org/example-color-text"; > prefix "rgb"; > import ietf-yang-metadata { prefix "md"; } > description > "Text is black, unless colored otherwise"; > md:annotation color { > type enumeration { > enum red; > enum green; > enum blue; > } > description > "This annotation only makes sense within this module. > Application of this annotation to any data node > Recursively applies to all its descendent nodes."; > } > container document { > list paragraph { > list sentence { > leaf-list word { > type string; > } > } > } > } > } > > > > I assume that the intent is for the annotation to apply to > the server as a whole, not any specific module. It might Yes. The description can also say that the annotation is ignored elsewhere. > help enforce this if annotations can only be defined in > modules that don't define any data-nodes and it is required > that the server advertises this module explicitly (not via > an import)... I expect this will be the normal way of defining annotations, and it could appear in the document as a guideline. I don't think though it is necessary to state it as a hard rule. > > > > 2. Also in Section 3, s/conditional:/conditional;/ > OK. > > > > 3. In Section 4.2.2, adding metadata to the first entry in a list doesn't > seem elegant. Can we instead create a special list element like the > following? Maybe I don't understand but the idea is that a separate metadata objects can be attached to any or all entries of a list. In the example it is added only to the first entry but another metadata object could be added to the second entry as well. It is not possible to add an annotation to the whole list, also because this cannot be represented in XML encoding (via attributes). > > "seq": [ > { > "@": { > "example-inactive:inactive": true > > } > }, > { > "name": "two", > ... > } > ] > > I don't think that '@' is a valid identifier string, so it's > syntactically OK, right? Right. > > > > 4. Also in Section 4.2.2, an anydata example would complete this section... > > > > 5. In Section 4.2.3, an anyxml example would complete this section... > OK, will add these examples. Thanks, Lada > > Thanks, > Kent > > > > _______________________________________________ > 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 Jul 1 02:56: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 055A21B2AD6; Wed, 1 Jul 2015 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 gPLO1qQ0pzsg; Wed, 1 Jul 2015 02:27:42 -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 300BA1B2AA3; Wed, 1 Jul 2015 02:27:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 0B80BDE2F33D9; Wed, 1 Jul 2015 09:27:39 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t619RaID028893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 11:27:37 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 11:27:36 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Susan Hares , "'Mahesh Jethanandani'" Thread-Topic: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQHQs3iywoO7BP7k/EicVuTrMAAx6p3Fa4wAgADr2RA= Date: Wed, 1 Jul 2015 09:27:35 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 02:56:23 -0700 Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , "'BRUNGARD, DEBORAH A'" , 'Netconf' , 'NETMOD Working Group' Subject: Re: [netmod] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) 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 Jul 2015 09:27:44 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gU3VzYW4sDQotICAgICAgICAgIFRvcG9sb2d5IG1vZGVsIHdoaWNoIGlzIGEgY29tcG9z aXRlIG9mOg0KbyAgIEdlbmVyaWMgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5n LW5ldHdvcmstdG9wby0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vPg0KbyAgIEwzIHRvcG9sb2d5IG1vZGVsOiBkcmFm dC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8+DQpvICAgTDIgdG9wb2xv Z3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDItbmV0 d29yay10b3BvbG9neS8+DQpvICAgTDEgVG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LXpoYW5nLWkycnMt bDEtdG9wby15YW5nLW1vZGVsLTAxICgtMDIgcmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVrKS4NCm8g ICBTZXJ2aWNlIHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2UtdG9wby15 YW5nLW1vZGVsLTAwIChyZWxlYXNlZCBvbiBXZWRuZXNkYXkpDQoNCkF0IHRoaXMgdGltZSwgbm9u ZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVlcmluZy4gIEl0 IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3VwcG9ydCB0cmFmZmljIGVu Z2luZWVyaW5nLg0KDQpSZWFkaW5nIHRoaXMgLCBteSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZXJl IGlzIGludGVudGlvbiBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZyBwYXJ0IG9mIHRvcG9sb2d5IG1v ZGVsIHRvIGV4cGxvaXQvY29vcmRpbmF0ZSB3aXRoIFRlYXMgLCBhbmQgcGFydGljdWxhcmx5IHdp dGgNCiBkcmFmdC1saXUtdGVhcy15YW5nLXRlLXRvcG8gb3IgdG8gcHJvY2VlZCB3aXRoIGRpc3Rp bmN0IGNvbnRyaWJ1dGlvbnMgaW50ZXJuYWwgdG8gSTJSUy4NCg0KVGhhbmtzDQpTZXJnaW8NCg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg5 MjMwMjU1NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTEzMjQ0Mjc4NzIgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IklUIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIFN1c2FuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+ VG9wb2xvZ3kNCiBtb2RlbCB3aGljaCBpcyBhIGNvbXBvc2l0ZSBvZjo8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5HZW5lcmlj DQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91bmQ6d2hpdGU7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0wMTwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIy MjtiYWNrZ3JvdW5kOndoaXRlIj5MMw0KIHRvcG9sb2d5IG1vZGVsOjwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7YmFja2dyb3VuZDojRjlGOUY5O3RleHQtZGVj b3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMDwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNG OUY5RjkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPkwyDQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMi1u ZXR3b3JrLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzNE MjJCMztiYWNrZ3JvdW5kOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWky cnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAwPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFj a2dyb3VuZDp3aGl0ZSI+TDENCiBUb3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtemhhbmctaTJycy1sMS10b3BvLXlhbmctbW9kZWwtMDEN CiAoLTAyIHJlbGVhc2VkIGxhdGVyIHRoaXMgd2VlaykuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPlNlcnZpY2UN CiB0b3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ ZHJhZnQtaGFyZXMtaTJycy1zZXJ2aWNlLXRvcG8teWFuZy1tb2RlbC0wMA0KIChyZWxlYXNlZCBv biBXZWRuZXNkYXkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjM2LjBw dDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0IHRoaXMg dGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVl cmluZy4mbmJzcDsgSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGVzZSBtb2RlbHMgd2lsbCBzdXBw b3J0IHRyYWZmaWMgZW5naW5lZXJpbmcuICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVhZGluZyB0 aGlzICwgbXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGVyZSBpcyBpbnRlbnRpb24gZm9yIFRyYWZm aWMgRW5naW5lZXJpbmcgcGFydCBvZiB0b3BvbG9neSBtb2RlbCB0byBleHBsb2l0L2Nvb3JkaW5h dGUgd2l0aCBUZWFzICwgYW5kIHBhcnRpY3VsYXJseSB3aXRoDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwO2RyYWZ0LWxpdS10ZWFzLXlhbmctdGUtdG9wbyBvciB0byBwcm9jZWVk IHdpdGggZGlzdGluY3QgY29udHJpYnV0aW9ucyBpbnRlcm5hbCB0byBJMlJTLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZXJnaW88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_-- From nobody Wed Jul 1 05:03: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 8DBA31A1B8B for ; Wed, 1 Jul 2015 05:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 sy8UG59Bn8UC for ; Wed, 1 Jul 2015 05:03:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F171A1B81 for ; Wed, 1 Jul 2015 05:03:17 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 7FBCC18170A; Wed, 1 Jul 2015 14:03:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1435752195; bh=4tiE2qjJaAe63GA4sk3Uhd0hr1d0eChfVwRYD2ERnWk=; h=From:Date:To; b=drDGWPYuoatRlipr/4J9DDKT/8KlTKB31hGdZ8x2fkR81D833iK4ii5O1qdwXP0wb DIIBHkf6fEm3cnSLjZvSShWWnfhzuvzQULW1hrMjH+BKwSBOsxA+mD3NWl0MvbLXNZ E30y2ux9cCRi3IALS+qxeZx+fxsrt1wgApuU6y+o= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <20150701072114.GA8001@elstar.local> Date: Wed, 1 Jul 2015 14:03:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> References: <20150624145325.GB38016@elstar.local> <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 12:03:25 -0000 > On 01 Jul 2015, at 09:21, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> On 30 Jun 2015, at 15:39, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>> On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder = wrote: >>>>>>>=20 >>>>>>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: >>>>>>>> Juergen Schoenwaelder = writes: >>>>>>>>=20 >>>>>>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka = wrote: >>>>>>>>>> Hi Juergen, >>>>>>>>>>=20 >>>>>>>>>> thank you for the review. >>>>>>>>>>=20 >>>>>>>>>> Juergen Schoenwaelder = writes: >>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> This is a notice to start a NETMOD WG last call for the = document "JSON Encoding of Data Modeled with YANG": >>>>>>>>>>>>=20 >>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 >>>>>>>>>>>>=20 >>>>>>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM = EST. >>>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. >>>>>>>>>>>=20 >>>>>>>>>>> - I am not sure I agree with the wording in section 3. Why = is section >>>>>>>>>>> 8.3.3 only applicable to XML encoded data? Validation = applies to >>>>>>>>>>> datastores. While constraints are defined using XML-based = notations >>>>>>>>>>=20 >>>>>>>>>> You are right that this section shouldn't talk about = XML-encoded data, >>>>>>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: = "XPath >>>>>>>>>> operates on the abstract, logical structure of an XML = document, =E2=80=A6". >>>>>>>>>>=20 >>>>>>>>>> So I think a datastore needs to be represented, at least = conceptually, >>>>>>>>>> as XML infoset. >>>>>>>>>>=20 >>>>>>>>>>> such as XPATH, how the validation is carried out is not = defined in >>>>>>>>>>> the YANG specifications. I guess I actually disagree with = the >>>>>>>>>>=20 >>>>>>>>>> I don't think this is true. YANG spec doesn't say how "must" = and "when" >>>>>>>>>> statements are evaluated, and relies on XPath. >>>>>>>>>=20 >>>>>>>>> RFC 6020: >>>>>>>>>=20 >>>>>>>>> When a datastore is validated, all "must" constraints are >>>>>>>>> conceptually evaluated once for each data node in the data = tree, and >>>>>>>>> for all leafs with default values in use (see Section 7.6.1). = If a >>>>>>>>> data node does not exist in the data tree, and it does not = have a >>>>>>>>> default value, its "must" statements are not evaluated. >>>>>>>>>=20 >>>>>>>>> [...] >>=20 >> The text you substituted here with an ellipsis is actually quite >> important for this discussion because it defines the context for = XPath >> evaluation (together with section 6.4), in particular the data tree = on >> which every XPath expression is evaluated. It is clear that the data >> tree can also comprise state data, notification content or RPC >> input/output, i.e. not only datastore content as you keep saying. >>=20 >> Terms like "context node" refer to the XPath data model as described = in >> sec. 5 of the XPath spec: >>=20 >> http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model >>=20 >> (and section 6.4 in RFC 6020 says it explicitly). >>=20 >> We need to know, at least conceptually, how to construct the XPath = data >> tree from JSON text. For example, it has to be clear that leaf-list >> entries encoded as a JSON array appear as sibling nodes in the data >> tree, otherwise a "must" constraint specified for the leaf-list won't >> work correctly. I don't think this is anyhow evident and IMO it has = to >> be addressed. This is the purpose of section 3 in >> draft-ietf-netmod-yang-json-04. >>=20 >> Would it help if "validation" is replaced with "XPath evaluation" >> throughout this section? >=20 > No. I continue to believe (a) a datastore is validated and not an XML > infoset (or something like that) and (b) that the evaluation of "must" > constraints is conceptual. Both NETCONF and YANG are absolutely silent about the data model of a = datastore, so I assume it can be pretty much anything. Can you explain = how a =E2=80=9Cmust=E2=80=9D constraint is conceptually evaluated on, = say, key-value database? Lada >=20 > JSON is an encoding. It remains unclear why you think that the JSON > encoding has any impact of what happens with a datastore. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 1 05:33:23 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 C9F4B1A6F20 for ; Wed, 1 Jul 2015 05:33: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 lAMjuD4rE4jF for ; Wed, 1 Jul 2015 05:33:19 -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 F0EF51A6EFE for ; Wed, 1 Jul 2015 05:33:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 483C61742; Wed, 1 Jul 2015 14:33:16 +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 ldk-dhfo6jB1; Wed, 1 Jul 2015 14:33: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; Wed, 1 Jul 2015 14:33:15 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 718DE2002B; Wed, 1 Jul 2015 14:33:16 +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 SlH2tlHmG5Nk; Wed, 1 Jul 2015 14:33: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 A881920013; Wed, 1 Jul 2015 14:33:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE0DB34E76E0; Wed, 1 Jul 2015 14:33:13 +0200 (CEST) Date: Wed, 1 Jul 2015 14:33:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150701123313.GA8880@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@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: <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 12:33:23 -0000 On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: > > > On 01 Jul 2015, at 09:21, Juergen Schoenwaelder wrote: > > > > On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder writes: > >> > >>> On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: > >>>> > >>>>> On 30 Jun 2015, at 15:39, Juergen Schoenwaelder wrote: > >>>>> > >>>>> On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder wrote: > >>>>>>> > >>>>>>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > >>>>>>>> Juergen Schoenwaelder writes: > >>>>>>>> > >>>>>>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: > >>>>>>>>>> Hi Juergen, > >>>>>>>>>> > >>>>>>>>>> thank you for the review. > >>>>>>>>>> > >>>>>>>>>> Juergen Schoenwaelder writes: > >>>>>>>>>> > >>>>>>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> This is a notice to start a NETMOD WG last call for the document "JSON Encoding of Data Modeled with YANG": > >>>>>>>>>>>> > >>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >>>>>>>>>>>> > >>>>>>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM EST. > >>>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. > >>>>>>>>>>> > >>>>>>>>>>> - I am not sure I agree with the wording in section 3. Why is section > >>>>>>>>>>> 8.3.3 only applicable to XML encoded data? Validation applies to > >>>>>>>>>>> datastores. While constraints are defined using XML-based notations > >>>>>>>>>> > >>>>>>>>>> You are right that this section shouldn't talk about XML-encoded data, > >>>>>>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath > >>>>>>>>>> operates on the abstract, logical structure of an XML document, …". > >>>>>>>>>> > >>>>>>>>>> So I think a datastore needs to be represented, at least conceptually, > >>>>>>>>>> as XML infoset. > >>>>>>>>>> > >>>>>>>>>>> such as XPATH, how the validation is carried out is not defined in > >>>>>>>>>>> the YANG specifications. I guess I actually disagree with the > >>>>>>>>>> > >>>>>>>>>> I don't think this is true. YANG spec doesn't say how "must" and "when" > >>>>>>>>>> statements are evaluated, and relies on XPath. > >>>>>>>>> > >>>>>>>>> RFC 6020: > >>>>>>>>> > >>>>>>>>> When a datastore is validated, all "must" constraints are > >>>>>>>>> conceptually evaluated once for each data node in the data tree, and > >>>>>>>>> for all leafs with default values in use (see Section 7.6.1). If a > >>>>>>>>> data node does not exist in the data tree, and it does not have a > >>>>>>>>> default value, its "must" statements are not evaluated. > >>>>>>>>> > >>>>>>>>> [...] > >> > >> The text you substituted here with an ellipsis is actually quite > >> important for this discussion because it defines the context for XPath > >> evaluation (together with section 6.4), in particular the data tree on > >> which every XPath expression is evaluated. It is clear that the data > >> tree can also comprise state data, notification content or RPC > >> input/output, i.e. not only datastore content as you keep saying. > >> > >> Terms like "context node" refer to the XPath data model as described in > >> sec. 5 of the XPath spec: > >> > >> http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model > >> > >> (and section 6.4 in RFC 6020 says it explicitly). > >> > >> We need to know, at least conceptually, how to construct the XPath data > >> tree from JSON text. For example, it has to be clear that leaf-list > >> entries encoded as a JSON array appear as sibling nodes in the data > >> tree, otherwise a "must" constraint specified for the leaf-list won't > >> work correctly. I don't think this is anyhow evident and IMO it has to > >> be addressed. This is the purpose of section 3 in > >> draft-ietf-netmod-yang-json-04. > >> > >> Would it help if "validation" is replaced with "XPath evaluation" > >> throughout this section? > > > > No. I continue to believe (a) a datastore is validated and not an XML > > infoset (or something like that) and (b) that the evaluation of "must" > > constraints is conceptual. > > Both NETCONF and YANG are absolutely silent about the data model of a datastore, so I assume it can be pretty much anything. Can you explain how a “must” constraint is conceptually evaluated on, say, key-value database? > This is a question to answer by someone who implements it on a key-value database. I feel we are wasting time and energy here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jul 1 06:01:51 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 A9F671A87BE for ; Wed, 1 Jul 2015 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 C89z9k8G_Y7p for ; Wed, 1 Jul 2015 06:01:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E0C1A87B3 for ; Wed, 1 Jul 2015 06:01:47 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:a0b5:7e86:4d7c:aeac] (unknown [IPv6:2001:718:1a02:1:a0b5:7e86:4d7c:aeac]) by mail.nic.cz (Postfix) with ESMTPSA id 523E71813D0 for ; Wed, 1 Jul 2015 15:01:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1435755706; bh=eyolNAM3/KpZ0KCvfbEXTunl5RFmvfgAfg2Tqfs0rRU=; h=From:Date:To; b=yT3PCICB+wJaLVmJ76f7JUhiw6r6mhaJI6OxohPDKoBGqzptcUG77u2Ak7sKN8ULH h/fFhuCx1PU0Pg/cAqmFUBYe0v8r3WeQ7zZwCMablbN7NA3uvsOMFDDDFY1EyKDwSD XDpOt6TlCw7XdRBpKFgNv3TiCLNBUWhmjiedSpHM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <20150701123313.GA8880@elstar.local> Date: Wed, 1 Jul 2015 15:01:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> References: <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> To: NETMOD Working Group X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 13:01:50 -0000 > On 01 Jul 2015, at 14:33, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 01 Jul 2015, at 09:21, Juergen Schoenwaelder = wrote: >>>=20 >>> On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 30 Jun 2015, at 15:39, Juergen Schoenwaelder = wrote: >>>>>>>=20 >>>>>>> On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder = wrote: >>>>>>>>>=20 >>>>>>>>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka = wrote: >>>>>>>>>> Juergen Schoenwaelder = writes: >>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka = wrote: >>>>>>>>>>>> Hi Juergen, >>>>>>>>>>>>=20 >>>>>>>>>>>> thank you for the review. >>>>>>>>>>>>=20 >>>>>>>>>>>> Juergen Schoenwaelder = writes: >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This is a notice to start a NETMOD WG last call for the = document "JSON Encoding of Data Modeled with YANG": >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Please indicate your support by Monday June 29, 2015 at = 9PM EST. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> - I am not sure I agree with the wording in section 3. Why = is section >>>>>>>>>>>>> 8.3.3 only applicable to XML encoded data? Validation = applies to >>>>>>>>>>>>> datastores. While constraints are defined using XML-based = notations >>>>>>>>>>>>=20 >>>>>>>>>>>> You are right that this section shouldn't talk about = XML-encoded data, >>>>>>>>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec = says: "XPath >>>>>>>>>>>> operates on the abstract, logical structure of an XML = document, =E2=80=A6". >>>>>>>>>>>>=20 >>>>>>>>>>>> So I think a datastore needs to be represented, at least = conceptually, >>>>>>>>>>>> as XML infoset. >>>>>>>>>>>>=20 >>>>>>>>>>>>> such as XPATH, how the validation is carried out is not = defined in >>>>>>>>>>>>> the YANG specifications. I guess I actually disagree with = the >>>>>>>>>>>>=20 >>>>>>>>>>>> I don't think this is true. YANG spec doesn't say how = "must" and "when" >>>>>>>>>>>> statements are evaluated, and relies on XPath. >>>>>>>>>>>=20 >>>>>>>>>>> RFC 6020: >>>>>>>>>>>=20 >>>>>>>>>>> When a datastore is validated, all "must" constraints are >>>>>>>>>>> conceptually evaluated once for each data node in the data = tree, and >>>>>>>>>>> for all leafs with default values in use (see Section = 7.6.1). If a >>>>>>>>>>> data node does not exist in the data tree, and it does not = have a >>>>>>>>>>> default value, its "must" statements are not evaluated. >>>>>>>>>>>=20 >>>>>>>>>>> [...] >>>>=20 >>>> The text you substituted here with an ellipsis is actually quite >>>> important for this discussion because it defines the context for = XPath >>>> evaluation (together with section 6.4), in particular the data tree = on >>>> which every XPath expression is evaluated. It is clear that the = data >>>> tree can also comprise state data, notification content or RPC >>>> input/output, i.e. not only datastore content as you keep saying. >>>>=20 >>>> Terms like "context node" refer to the XPath data model as = described in >>>> sec. 5 of the XPath spec: >>>>=20 >>>> http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model >>>>=20 >>>> (and section 6.4 in RFC 6020 says it explicitly). >>>>=20 >>>> We need to know, at least conceptually, how to construct the XPath = data >>>> tree from JSON text. For example, it has to be clear that leaf-list >>>> entries encoded as a JSON array appear as sibling nodes in the data >>>> tree, otherwise a "must" constraint specified for the leaf-list = won't >>>> work correctly. I don't think this is anyhow evident and IMO it has = to >>>> be addressed. This is the purpose of section 3 in >>>> draft-ietf-netmod-yang-json-04. >>>>=20 >>>> Would it help if "validation" is replaced with "XPath evaluation" >>>> throughout this section? >>>=20 >>> No. I continue to believe (a) a datastore is validated and not an = XML >>> infoset (or something like that) and (b) that the evaluation of = "must" >>> constraints is conceptual. >>=20 >> Both NETCONF and YANG are absolutely silent about the data model of a = datastore, so I assume it can be pretty much anything. Can you explain = how a =E2=80=9Cmust=E2=80=9D constraint is conceptually evaluated on, = say, key-value database? >>=20 >=20 > This is a question to answer by someone who implements it on a > key-value database. Note that RFC 6020 just has XML mapping sections and otherwise tells = nothing about how instances of data nodes are represented in a = datastore. I have thus always assumed that everything works fine because = the datastore model is essentially XML Infoset, except that =E2=80=9Cdata = tree=E2=80=9D is used instead of =E2=80=9Cinfoset=E2=80=9D, =E2=80=9Cdata= node=E2=80=9D instead of =E2=80=9Cinformation item=E2=80=9D etc. In any case, with RFC 6020 in hand I can only explain how JSON is mapped = to XML. I have no idea how to get JSON data into a datastore of unknown = data model (which you take for granted), and then conceptually evaluate = XPath expressions on it. >=20 > I feel we are wasting time and energy here. Indeed, and it is frustrating. However, I=E2=80=99d like to know what to = do with section 3 of the yang-json document. 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 1 07:20:11 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 2973D1A89FC for ; Wed, 1 Jul 2015 07:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 LCd-Ojg6EVih for ; Wed, 1 Jul 2015 07:20:06 -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 3CE931A8A05 for ; Wed, 1 Jul 2015 07:20:06 -0700 (PDT) Received: by lagx9 with SMTP id x9so41733056lag.1 for ; Wed, 01 Jul 2015 07:20: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=N+G89zxYYzh2mUh/+LZeIZ/C8iAZn9YAOGfzoopgmLI=; b=OObOvldmkz75483/Dr+zjMhKwRNUkg8GhLEPzA/4HAtRNv6o4IzzLXXVTcR1VrR9hh rITkJqJbiHjwZK1yMB5WGa1oCzy/D4LaXWUbJfe4qE3MOfz12lVIa2Hhgse3tA0GIrpv yFT9cbZWTkuT4JF7qkxYvjga7RqI5hVb4yXpiEyvU+M9EoCGI0/eq4cEzVGj2jPG3ZcN i9zdy+4aKbiuA2TT+ZM2czaOj4yqktoGmW81pOGRkWKE666rX/ZrB142lawA/xrHGbT2 SG71elnF7KdRx4Eqzgbom+sza2pgzrIHGd6R5JjSIrT6OGots9/MvY71V/wERB8UFB/o jEwg== X-Gm-Message-State: ALoCoQmwvYqm2ab51WO/m2WohMbMc79ffsdXHnVR84Gteuyy29b7MyF581mlDVG41Ir6lcZhiuK9 MIME-Version: 1.0 X-Received: by 10.112.147.233 with SMTP id tn9mr25365376lbb.119.1435760404584; Wed, 01 Jul 2015 07:20:04 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 07:20:04 -0700 (PDT) In-Reply-To: <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> References: <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> Date: Wed, 1 Jul 2015 07:20:04 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b3a8978e5f96a0519d1045d Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 14:20:10 -0000 --047d7b3a8978e5f96a0519d1045d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2015 at 6:01 AM, Ladislav Lhotka wrote: > > > On 01 Jul 2015, at 14:33, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: > >> > >>> On 01 Jul 2015, at 09:21, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: > >>>> Juergen Schoenwaelder writes: > >>>> > >>>>> On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 30 Jun 2015, at 15:39, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >>>>>>> > >>>>>>> On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: > >>>>>>>> > >>>>>>>>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >>>>>>>>> > >>>>>>>>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote= : > >>>>>>>>>> Juergen Schoenwaelder > writes: > >>>>>>>>>> > >>>>>>>>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka > wrote: > >>>>>>>>>>>> Hi Juergen, > >>>>>>>>>>>> > >>>>>>>>>>>> thank you for the review. > >>>>>>>>>>>> > >>>>>>>>>>>> Juergen Schoenwaelder > writes: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen wrote= : > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This is a notice to start a NETMOD WG last call for the > document "JSON Encoding of Data Modeled with YANG": > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please indicate your support by Monday June 29, 2015 at 9P= M > EST. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. > >>>>>>>>>>>>> > >>>>>>>>>>>>> - I am not sure I agree with the wording in section 3. Why > is section > >>>>>>>>>>>>> 8.3.3 only applicable to XML encoded data? Validation > applies to > >>>>>>>>>>>>> datastores. While constraints are defined using XML-based > notations > >>>>>>>>>>>> > >>>>>>>>>>>> You are right that this section shouldn't talk about > XML-encoded data, > >>>>>>>>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says= : > "XPath > >>>>>>>>>>>> operates on the abstract, logical structure of an XML > document, =E2=80=A6". > >>>>>>>>>>>> > >>>>>>>>>>>> So I think a datastore needs to be represented, at least > conceptually, > >>>>>>>>>>>> as XML infoset. > >>>>>>>>>>>> > >>>>>>>>>>>>> such as XPATH, how the validation is carried out is not > defined in > >>>>>>>>>>>>> the YANG specifications. I guess I actually disagree with t= he > >>>>>>>>>>>> > >>>>>>>>>>>> I don't think this is true. YANG spec doesn't say how "must" > and "when" > >>>>>>>>>>>> statements are evaluated, and relies on XPath. > >>>>>>>>>>> > >>>>>>>>>>> RFC 6020: > >>>>>>>>>>> > >>>>>>>>>>> When a datastore is validated, all "must" constraints are > >>>>>>>>>>> conceptually evaluated once for each data node in the data > tree, and > >>>>>>>>>>> for all leafs with default values in use (see Section 7.6.1). > If a > >>>>>>>>>>> data node does not exist in the data tree, and it does not > have a > >>>>>>>>>>> default value, its "must" statements are not evaluated. > >>>>>>>>>>> > >>>>>>>>>>> [...] > >>>> > >>>> The text you substituted here with an ellipsis is actually quite > >>>> important for this discussion because it defines the context for XPa= th > >>>> evaluation (together with section 6.4), in particular the data tree = on > >>>> which every XPath expression is evaluated. It is clear that the data > >>>> tree can also comprise state data, notification content or RPC > >>>> input/output, i.e. not only datastore content as you keep saying. > >>>> > >>>> Terms like "context node" refer to the XPath data model as described > in > >>>> sec. 5 of the XPath spec: > >>>> > >>>> http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model > >>>> > >>>> (and section 6.4 in RFC 6020 says it explicitly). > >>>> > >>>> We need to know, at least conceptually, how to construct the XPath > data > >>>> tree from JSON text. For example, it has to be clear that leaf-list > >>>> entries encoded as a JSON array appear as sibling nodes in the data > >>>> tree, otherwise a "must" constraint specified for the leaf-list won'= t > >>>> work correctly. I don't think this is anyhow evident and IMO it has = to > >>>> be addressed. This is the purpose of section 3 in > >>>> draft-ietf-netmod-yang-json-04. > >>>> > >>>> Would it help if "validation" is replaced with "XPath evaluation" > >>>> throughout this section? > >>> > >>> No. I continue to believe (a) a datastore is validated and not an XML > >>> infoset (or something like that) and (b) that the evaluation of "must= " > >>> constraints is conceptual. > >> > >> Both NETCONF and YANG are absolutely silent about the data model of a > datastore, so I assume it can be pretty much anything. Can you explain ho= w > a =E2=80=9Cmust=E2=80=9D constraint is conceptually evaluated on, say, ke= y-value database? > >> > > > > This is a question to answer by someone who implements it on a > > key-value database. > > Note that RFC 6020 just has XML mapping sections and otherwise tells > nothing about how instances of data nodes are represented in a datastore.= I > have thus always assumed that everything works fine because the datastore > model is essentially XML Infoset, except that =E2=80=9Cdata tree=E2=80=9D= is used instead > of =E2=80=9Cinfoset=E2=80=9D, =E2=80=9Cdata node=E2=80=9D instead of =E2= =80=9Cinformation item=E2=80=9D etc. > > In any case, with RFC 6020 in hand I can only explain how JSON is mapped > to XML. I have no idea how to get JSON data into a datastore of unknown > data model (which you take for granted), and then conceptually evaluate > XPath expressions on it. > > > > > I feel we are wasting time and energy here. > > Indeed, and it is frustrating. However, I=E2=80=99d like to know what to = do with > section 3 of the yang-json document. > > I agree with Juergen that the implementation of YANG constraints on a datastore is not XML-specific. The text refers to data nodes not XML elements. It is quite possible for a server to populate data nodes in a datastore without NETCONF of XML being involved. We keep getting stuck on the difference between resource representations on the wire, and implementation details within a client or server. There is no requirement that they be the same "XML or JSON". inside. 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b3a8978e5f96a0519d1045d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 6:01 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 01 Jul 2015, at 14:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
>
> On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote:
>>
>>> On 01 Jul 2015, at 09:21, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univer= sity.de> wrote:
>>>
>>> On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrot= e:
>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes= :
>>>>
>>>>> On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lho= tka wrote:
>>>>>>
>>>>>>> On 30 Jun 2015, at 15:39, Juergen Schoenwaelde= r <j.schoenwaeld= er@jacobs-university.de> wrote:
>>>>>>>
>>>>>>> On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladi= slav Lhotka wrote:
>>>>>>>>
>>>>>>>>> On 30 Jun 2015, at 15:20, Juergen Scho= enwaelder <j.sch= oenwaelder@jacobs-university.de> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Jun 30, 2015 at 02:56:30PM +02= 00, Ladislav Lhotka wrote:
>>>>>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de> writes:
>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 29, 2015 at 11:49:= 11AM +0200, Ladislav Lhotka wrote:
>>>>>>>>>>>> Hi Juergen,
>>>>>>>>>>>>
>>>>>>>>>>>> thank you for the review.<= br> >>>>>>>>>>>>
>>>>>>>>>>>> Juergen Schoenwaelder <= j.schoenwaelder@jac= obs-university.de> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jun 15, 2015 a= t 10:49:28PM +0000, Kent Watsen wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a notice t= o start a NETMOD WG last call for the document "JSON Encoding of Data = Modeled with YANG":
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please indicate yo= ur support by Monday June 29, 2015 at 9PM EST.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have reviewed draft-= ietf-netmod-yang-json-04.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - I am not sure I agre= e with the wording in section 3. Why is section
>>>>>>>>>>>>> 8.3.3 only applicable = to XML encoded data? Validation applies to
>>>>>>>>>>>>> datastores. While cons= traints are defined using XML-based notations
>>>>>>>>>>>>
>>>>>>>>>>>> You are right that this se= ction shouldn't talk about XML-encoded data,
>>>>>>>>>>>> i.e. serialized form. On t= he other hand, XPath 1.0 spec says: "XPath
>>>>>>>>>>>> operates on the abstract, = logical structure of an XML document, =E2=80=A6".
>>>>>>>>>>>>
>>>>>>>>>>>> So I think a datastore nee= ds to be represented, at least conceptually,
>>>>>>>>>>>> as XML infoset.
>>>>>>>>>>>>
>>>>>>>>>>>>> such as XPATH, how the= validation is carried out is not defined in
>>>>>>>>>>>>> the YANG specification= s. I guess I actually disagree with the
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think this is = true. YANG spec doesn't say how "must" and "when" >>>>>>>>>>>> statements are evaluated, = and relies on XPath.
>>>>>>>>>>>
>>>>>>>>>>> RFC 6020:
>>>>>>>>>>>
>>>>>>>>>>> When a datastore is validated,= all "must" constraints are
>>>>>>>>>>> conceptually evaluated once fo= r each data node in the data tree, and
>>>>>>>>>>> for all leafs with default val= ues in use (see Section 7.6.1).=C2=A0 If a
>>>>>>>>>>> data node does not exist in th= e data tree, and it does not have a
>>>>>>>>>>> default value, its "must&= quot; statements are not evaluated.
>>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>
>>>> The text you substituted here with an ellipsis is actually= quite
>>>> important for this discussion because it defines the conte= xt for XPath
>>>> evaluation (together with section 6.4), in particular the = data tree on
>>>> which every XPath expression is evaluated. It is clear tha= t the data
>>>> tree can also comprise state data, notification content or= RPC
>>>> input/output, i.e. not only datastore content as you keep = saying.
>>>>
>>>> Terms like "context node" refer to the XPath dat= a model as described in
>>>> sec. 5 of the XPath spec:
>>>>
>>>> http://www.w3.org/TR/1999/R= EC-xpath-19991116/#data-model
>>>>
>>>> (and section 6.4 in RFC 6020 says it explicitly).
>>>>
>>>> We need to know, at least conceptually, how to construct t= he XPath data
>>>> tree from JSON text. For example, it has to be clear that = leaf-list
>>>> entries encoded as a JSON array appear as sibling nodes in= the data
>>>> tree, otherwise a "must" constraint specified fo= r the leaf-list won't
>>>> work correctly. I don't think this is anyhow evident a= nd IMO it has to
>>>> be addressed. This is the purpose of section 3 in
>>>> draft-ietf-netmod-yang-json-04.
>>>>
>>>> Would it help if "validation" is replaced with &= quot;XPath evaluation"
>>>> throughout this section?
>>>
>>> No. I continue to believe (a) a datastore is validated and not= an XML
>>> infoset (or something like that) and (b) that the evaluation o= f "must"
>>> constraints is conceptual.
>>
>> Both NETCONF and YANG are absolutely silent about the data model o= f a datastore, so I assume it can be pretty much anything. Can you explain = how a =E2=80=9Cmust=E2=80=9D constraint is conceptually evaluated on, say, = key-value database?
>>
>
> This is a question to answer by someone who implements it on a
> key-value database.

Note that RFC 6020 just has XML mapping sections and otherwise tells nothin= g about how instances of data nodes are represented in a datastore. I have = thus always assumed that everything works fine because the datastore model = is essentially XML Infoset, except that =E2=80=9Cdata tree=E2=80=9D is used= instead of =E2=80=9Cinfoset=E2=80=9D,=C2=A0 =E2=80=9Cdata node=E2=80=9D in= stead of =E2=80=9Cinformation item=E2=80=9D etc.

In any case, with RFC 6020 in hand I can only explain how JSON is mapped to= XML. I have no idea how to get JSON data into a datastore of unknown data = model (which you take for granted), and then conceptually evaluate XPath ex= pressions on it.

>
> I feel we are wasting time and energy here.

Indeed, and it is frustrating. However, I=E2=80=99d like to know what to do= with section 3 of the yang-json document.


I agree with Juergen that the implemen= tation of YANG constraints
on =C2=A0a datastore is not XML-specif= ic.=C2=A0 The text refers to data nodes
not XML elements.=C2=A0 I= t is quite possible for a server to populate data
nodes in a data= store without NETCONF of XML being involved.

We ke= ep getting stuck on the difference between resource representations
on the wire, and implementation details within a client or server.
=
There is no requirement that they be the same "XML or JSON".=
inside.


Lada

>
> /js


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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

--047d7b3a8978e5f96a0519d1045d-- From nobody Wed Jul 1 07:25:10 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 06B6B1A8A76 for ; Wed, 1 Jul 2015 07:25:08 -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 F2D-wg4NPVHg for ; Wed, 1 Jul 2015 07:25:06 -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 CB9AF1A8A0C for ; Wed, 1 Jul 2015 07:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2001; q=dns/txt; s=iport; t=1435760706; x=1436970306; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=UG82ynPTySPIsLldVx+FYO5pYzKqErGjNQyFFYFENZU=; b=C0qEJLqKJUiX9ualectsr6LTLqGMgxoaKrUky17LMi+k+MFrWofgucDX SbhqouXuA4rugIdsr1GpObJmJeOU4UvYpYbPfU/c2HS/2j7dBvHpo925K q/IR21s8mzn119o8FuvuR9due2MYg7RIfj8YMjSNh2B3c/JjVWdZBKpJQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBAAt95NV/xbLJq1bg2VfvyWFeAKCDBABAQEBAQEBgQqEIwEBBB0bQBELIRYPCQMCAQIBRQYBDAgBAYgrDcwmAQEBAQEBAQEBAQEBAQEBAQEBARUEi0qBPYNQhCsBBJQQhF2HBIg5kAsmghkkgT88MQGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.15,386,1432598400"; d="scan'208";a="551330750" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Jul 2015 14:25:03 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t61EP1er026885; Wed, 1 Jul 2015 14:25:02 GMT To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" References: <5591D162.4010100@cisco.com> From: Benoit Claise Message-ID: <5593F83D.3050900@cisco.com> Date: Wed, 1 Jul 2015 16:25:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 14:25:08 -0000 Hi Lada, >> ay >> - >> The set of annotations must be extensible in a distributed manner >> so as to allow for defining new annotations without running into >> the risk of collisions with annotations defined and used by >> others. >> >> What does "in a distributed manner" mean? > It means that different parties needn't coordinate the names and use of > annotations, as long as they don't choose conflicting YANG module names > or namespace URIs. Ok, it was not too clear (to me) from the text. > >> >> >> - In the introduction, you mention: >> Typical use cases are: >> >> o Deactivating a subtree in a configuration datastore while keeping >> the data in place. >> >> o Complementing data model information with instance-specific data. >> >> o RPC operations may use metadata annotations for various purposes >> in both requests and responses. For example, the >> operation in the NETCONF protocol (seesection 7.2 of [RFC6241] ) >> uses annotations in the form of XML attributes for identifying the >> point in the configuration and type of the operation. >> >> >> Don't you have any other examples than those 3? >> What about showing these examples with the spec. in this document? >> Note: I see that the first one is documented with module >> example-inactive > Well, the backlash I received with > draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there > is consensus about general utility of annotations, practical definitions > may be controversial. Even as example? > I could add the annotations from the above draft > as examples here but I fear they could still make for unnecessary > discussions. > > Martin already pointed out in his review that it may be wiser to replace > the "inactive" annotation with something less controversial. ok. Regards, Benoit From nobody Wed Jul 1 07:34:37 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 9711B1A8A93 for ; Wed, 1 Jul 2015 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 svFXj1ICAxHB for ; Wed, 1 Jul 2015 07:34:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2AE1A8AD3 for ; Wed, 1 Jul 2015 07:31:24 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:a0b5:7e86:4d7c:aeac] (unknown [IPv6:2001:718:1a02:1:a0b5:7e86:4d7c:aeac]) by mail.nic.cz (Postfix) with ESMTPSA id 05B9418129E; Wed, 1 Jul 2015 16:31:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1435761083; bh=UDwYXjIgLm0gKb7YvtUgNuGFA5+Gf0znnqqgB8LX3Fw=; h=From:Date:To; b=obLm+b2vpGPv5RiUqyabtDQNSKCRAMumqd3zAh3W4V/MAXiFkocDn4QEamOfz20RJ 7kkSA0NvM/ub8OR95e8l/ArxFqgpXLr2EExYbGn7J/sdy5nPwtWIKGmacWsuV5d2qY uEXy6hzYhgXcH5Tf0dCroIhdY3EPjFtWSJGbdmNU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <5593F83D.3050900@cisco.com> Date: Wed, 1 Jul 2015 16:31:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5591D162.4010100@cisco.com> <5593F83D.3050900@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 14:34:36 -0000 > On 01 Jul 2015, at 16:25, Benoit Claise wrote: >=20 > Hi Lada, >>> ay >>> - >>> The set of annotations must be extensible in a distributed = manner >>> so as to allow for defining new annotations without running = into >>> the risk of collisions with annotations defined and used by >>> others. >>>=20 >>> What does "in a distributed manner" mean? >> It means that different parties needn't coordinate the names and use = of >> annotations, as long as they don't choose conflicting YANG module = names >> or namespace URIs. > Ok, it was not too clear (to me) from the text. I will add text to explain what =93distributed=94 means. >>=20 >>>=20 >>>=20 >>> - In the introduction, you mention: >>> Typical use cases are: >>>=20 >>> o Deactivating a subtree in a configuration datastore while = keeping >>> the data in place. >>>=20 >>> o Complementing data model information with instance-specific = data. >>>=20 >>> o RPC operations may use metadata annotations for various = purposes >>> in both requests and responses. For example, the = >>> operation in the NETCONF protocol (seesection 7.2 of = [RFC6241] ) >>> uses annotations in the form of XML attributes for = identifying the >>> point in the configuration and type of the operation. >>>=20 >>>=20 >>> Don't you have any other examples than those 3? >>> What about showing these examples with the spec. in this document? >>> Note: I see that the first one is documented with module >>> example-inactive >> Well, the backlash I received with >> draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst = there >> is consensus about general utility of annotations, practical = definitions >> may be controversial. > Even as example? Yes, I am afraid. Lada >> I could add the annotations from the above draft >> as examples here but I fear they could still make for unnecessary >> discussions. >>=20 >> Martin already pointed out in his review that it may be wiser to = replace >> the "inactive" annotation with something less controversial. > ok. >=20 > Regards, Benoit -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 1 07:41: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 605761A1BD1 for ; Wed, 1 Jul 2015 07:41:45 -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 HLBcaaVqrUAV for ; Wed, 1 Jul 2015 07:41:44 -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 A651F1A8AAE for ; Wed, 1 Jul 2015 07:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1405; q=dns/txt; s=iport; t=1435761701; x=1436971301; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=py8baM1sTPXIBgF29zyvuMstZISTc4W05/kZMLVIcMk=; b=j3K793XwXOJfVBaIoj5t53ajM5oNOtLcq+TKt81+UK3xokBSlKDZ0dBR tqqs2TVacZ80vypFMp45o9CJEr6kUqBX+ixsQzWxrnRnpqTBgRaTnXihA uUrIEFluSsfNSQjpvbYoor3LxK0RhL+sKyP+uNLQ3B26ujqBiTd2Lyc2+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBADN+5NV/xbLJq1bg2VfvyWFeAKCDBABAQEBAQEBgQqEIwEBBB0bQAEQCyEWDwkDAgECAUUGDQgBAYgrDcwhAQEBAQEBAQEBAQEBAQEBAQEBAQEUBItKgT2DSQeEKwEElBCEXYcEiDmQCyaCGSSBPzwxAYJHAQEB X-IronPort-AV: E=Sophos;i="5.15,386,1432598400"; d="scan'208";a="551343132" 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; 01 Jul 2015 14:41:32 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t61EfUqR009639; Wed, 1 Jul 2015 14:41:31 GMT To: Ladislav Lhotka References: <5591D162.4010100@cisco.com> <5593F83D.3050900@cisco.com> From: Benoit Claise Message-ID: <5593FC1A.4020501@cisco.com> Date: Wed, 1 Jul 2015 16:41:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 14:41:45 -0000 Hi Lada, > >>>> >>>> - In the introduction, you mention: >>>> Typical use cases are: >>>> >>>> o Deactivating a subtree in a configuration datastore while keeping >>>> the data in place. >>>> >>>> o Complementing data model information with instance-specific data. >>>> >>>> o RPC operations may use metadata annotations for various purposes >>>> in both requests and responses. For example, the >>>> operation in the NETCONF protocol (seesection 7.2 of [RFC6241] ) >>>> uses annotations in the form of XML attributes for identifying the >>>> point in the configuration and type of the operation. >>>> >>>> >>>> Don't you have any other examples than those 3? >>>> What about showing these examples with the spec. in this document? >>>> Note: I see that the first one is documented with module >>>> example-inactive >>> Well, the backlash I received with >>> draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there >>> is consensus about general utility of annotations, practical definitions >>> may be controversial. >> Even as example? > Yes, I am afraid. I would be in favor to have at the very minimum one example. Otherwise, it's difficult to visualize how these metadata should be used. Regards, Benoit (as a contributor) From nobody Wed Jul 1 08:13:32 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 7DD2E1A8F48 for ; Wed, 1 Jul 2015 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Zmb1NFv1MCJP for ; Wed, 1 Jul 2015 08:13:28 -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 2594D1A8F38 for ; Wed, 1 Jul 2015 08:13:28 -0700 (PDT) Received: by lbnk3 with SMTP id k3so14928401lbn.1 for ; Wed, 01 Jul 2015 08:13:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i6XzneObUBiWdxbLERX2B3gLWJTygAIEuX222ckpEdk=; b=Z5RGwM+Vb9amDHkxvhuWtZIizKOCqIiY7qHIhEmTITZCXVLkOQYLaIxxobRUp5okTd 1965WIl/y4t5hVs/2c/Z7EpiQiQdD19EDZ2SfBobpPwHro0OgctxsjPHgF+RraCBFNBJ Dya7v+TiwXlnoAPfmOT/M0PFfZemTr6hpSQf2o9AmY6o5QE0bw9u38X+DdEmTqYEDp82 3+nRXPFLm/+YjeaV5/fCKqdhySQK143HF8OLSi14LrG6pqvBxLKSM3PYwqb7V+RcDxpU yhFUHcWcFZXLoQMyPD5xFrejWYiGTfdhTdG2nWrsL7QpNmzWvgLR+kAKiy+EQ9lRsrNQ 9tHw== X-Gm-Message-State: ALoCoQlcqCjSW00QhBS+B5U/nqlO4V5TRxA76udt2hreyaRrc35+s2gaBbCkVuHakQC29PmcSYXy MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr25863304laj.123.1435763606578; Wed, 01 Jul 2015 08:13:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 08:13:26 -0700 (PDT) In-Reply-To: <5593FC1A.4020501@cisco.com> References: <5591D162.4010100@cisco.com> <5593F83D.3050900@cisco.com> <5593FC1A.4020501@cisco.com> Date: Wed, 1 Jul 2015 08:13:26 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=089e0158ba0ac07e9c0519d1c318 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 15:13:30 -0000 --089e0158ba0ac07e9c0519d1c318 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 1, 2015 at 7:41 AM, Benoit Claise wrote: > Hi Lada, > >> >> >>>>> - In the introduction, you mention: >>>>> Typical use cases are: >>>>> >>>>> o Deactivating a subtree in a configuration datastore while >>>>> keeping >>>>> the data in place. >>>>> >>>>> o Complementing data model information with instance-specific >>>>> data. >>>>> >>>>> o RPC operations may use metadata annotations for various >>>>> purposes >>>>> in both requests and responses. For example, the >>>>> operation in the NETCONF protocol (seesection 7.2 of [RFC6241] >>>>> ) >>>>> uses annotations in the form of XML attributes for identifying >>>>> the >>>>> point in the configuration and type of the operation. >>>>> >>>>> >>>>> Don't you have any other examples than those 3? >>>>> What about showing these examples with the spec. in this document? >>>>> Note: I see that the first one is documented with module >>>>> example-inactive >>>>> >>>> Well, the backlash I received with >>>> draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there >>>> is consensus about general utility of annotations, practical definitions >>>> may be controversial. >>>> >>> Even as example? >>> >> Yes, I am afraid. >> > I would be in favor to have at the very minimum one example. > Otherwise, it's difficult to visualize how these metadata should be used. > > We support an attribute called "owner" which is basically the I2RS client-id. At ;least one solution proposal for I2RS is going to allow retrieval of the metadata from the ephemeral datastore (e.g., client-id, secondary-id). Perhaps an example like this will not be controversial. > Regards, Benoit (as a contributor) > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0158ba0ac07e9c0519d1c318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 7:41 AM, Benoit Claise <bclaise@cisco.com&g= t; wrote:
Hi Lada,


- In the introduction, you mention:
=C2=A0 =C2=A0 =C2=A0Typical use cases are:

=C2=A0 =C2=A0 =C2=A0o=C2=A0 Deactivating a subtree in a configuration datas= tore while keeping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the data in place.

=C2=A0 =C2=A0 =C2=A0o=C2=A0 Complementing data model information with insta= nce-specific data.

=C2=A0 =C2=A0 =C2=A0o=C2=A0 RPC operations may use metadata annotations for= various purposes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in both requests and responses.=C2=A0 For examp= le, the <edit-config>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operation in the NETCONF protocol (seesection 7= .2 of [RFC6241] <https://tools.ietf.org/html/rfc62= 41#section-7.2>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses annotations in the form of XML attributes = for identifying the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 point in the configuration and type of the oper= ation.


Don't you have any other examples than those 3?
What about showing these examples with the spec. in this document?
Note: I see that the first one is documented with module
example-inactive
Well, the backlash I received with
draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there is consensus about general utility of annotations, practical definitions may be controversial.
Even as example?
Yes, I am afraid.
I would be in favor to have at the very minimum one example.
Otherwise, it's difficult to visualize how these metadata should be use= d.



We support an attribute= called "owner" which is basically the I2RS client-id.
= At ;least one solution proposal for I2RS is going to allow retrieval of the=
metadata from the ephemeral datastore (e.g., client-id, secondar= y-id).
Perhaps an example like this will not be controversial.

=C2=A0
Regards, Benoit (as a contributor)


=
Andy
=C2=A0

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

--089e0158ba0ac07e9c0519d1c318-- From nobody Wed Jul 1 09:01: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 DB5081A1BC2 for ; Wed, 1 Jul 2015 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WANT=2.3, SPF_HELO_PASS=-0.001, 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 T8y4dDCgJs_5 for ; Wed, 1 Jul 2015 09:01:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0D11A01FC for ; Wed, 1 Jul 2015 09:01:39 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB346.namprd05.prod.outlook.com (10.141.52.12) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 16:01:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 16:01:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) with mapi id 15.01.0207.004; Wed, 1 Jul 2015 16:01:20 +0000 From: Kent Watsen To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) Thread-Index: AQHQs3aEh3sCPrCqSkegq1SWU9kekZ3GR8OAgAA8lgA= Date: Wed, 1 Jul 2015 16:01:19 +0000 Message-ID: References: In-Reply-To: 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: nic.cz; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:xH8rY0+sqvdUjeiEl5jGNXFlCkR+u9jWNOn9SwLm249VUMjRavZXCPySirnMWiF9T3vFwCN3PlTB6VavwBdII6k06iDnleAHN8wGAOFbxMmOLyS26Fyoi9OK+mjn0sy0grNa01yK/hr5r+biL5tW5w==; 24:ZD9p5hjPPW6GkGSbhGbFgPv9rpc0RIj/pUuofMH3PaLDRCE4r/lVoLPzTS3Vsmh/tYrQSbo9UD15JDz6GvIBeI094yaFAHO2md0CyQHFRn0=; 20:9rhJa3L7p2odkmN/NI6PncpX8yKleAAHR2UGM4ruKqacwR/eFc3aOr0r8I2Ynb8XpIfgDsoJF/L17RZHtUNMDg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(5423002)(51704005)(5001960100002)(107886002)(54356999)(76176999)(92566002)(2900100001)(2950100001)(83506001)(50986999)(66066001)(62966003)(230783001)(46102003)(122556002)(40100003)(77156002)(102836002)(87936001)(2656002)(86362001)(4001350100001)(99286002)(2501003)(106116001)(5001770100001)(5890100001)(36756003)(189998001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1126A282FDDDAD4C8BAEEE98ACD8519D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 16:01:19.8514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB346; 2:jdKnL1+MsQ+xC2AN7gRUhxd0PPAOhL4x3oVO7lKNQi6lyhcawISbjRi2BeSoQcVM; 3:C/OD6s/m13iIduOofYAQKZFp7egNmcwCovHAnICKEJoQ/IaRZbsidz0bPZBvvDQFps3+3YBuZzd76g/4GIlrry+yoYqcXHEn1QLbf10g6OxwhxZ3bamHFSv7fK/Ii/pq+iarMHoqhwjVy5kiJNw5Qw==; 23:2cZnioi51SFLNL9tehI/691Iz+k2RIewjGhppgu/rZnXN5xic4HRv3VDjl8SRO/IK0jB5z5wE+bE2Gz+5UDVjwgvFa8EvwRSG+YSLJkHe9JWnqP8kgfzaqlddei+zZpMwnkn52nVihMLdMXUoZAwWuhyn1tbqc208Smc1I3OwUA197vaUwBbyEtFXPYhv1uUZPyBAD/2r7jHKGOdzjCOJd0Ehqr63Nh9bw0QXuGRJilLQJcpmYpuYRTdIQIAyWwk X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 16:01:42 -0000 >>1. In Section 3, it says: >> >> >> Does this mean that the annotation A can be used by *any* module >> the server advertises, or just the modules that define/import >> annotation A? > >For all modules implemented by the server, no import is needed. Good, but I think the text should say this explicitly. >> I assume that the intent is for the annotation to apply to >> the server as a whole, not any specific module. It might > >Yes. The description can also say that the annotation is ignored >elsewhere. Maybe I don't understand your response, but if we agree that annotations are a server-level thing (not module-specific), then I do not agree that a module's description should be able to say that an annotation should be ignored in other modules. >> help enforce this if annotations can only be defined in >> modules that don't define any data-nodes and it is required >> that the server advertises this module explicitly (not via >> an import)... > >I expect this will be the normal way of defining annotations, and it >could appear in the document as a guideline. I don't think though it is >necessary to state it as a hard rule. OK, a SHOULD or RECOMMENDED statement would help to clarify this. >>3. In Section 4.2.2, adding metadata to the first entry in a list doesn't >> seem elegant. Can we instead create a special list element like the >> following? > >Maybe I don't understand but the idea is that a separate metadata objects >can be attached to any or all entries of a list. In the example it is >added only to the first entry but another metadata object could be added >to the second entry as well. I see, but then this make the example misleading. I thought it was trying to show how to place an annotation on the list as a whole. I see now it says "list instance", but this seems uninteresting example, as list instances are just nodes for which how to apply annotations is already known - there's nothing special about the node being a list element - right? >It is not possible to add an annotation to the whole list, also because >this cannot be represented in XML encoding (via attributes). An annotation cannot be attached to a list as a whole? - that seems fundamentally broken, though I understand why you say it cannot be easily represented in XML (via attributes). Should we consider alternative representations? That said, if unavoidable, the draft needs to call that out as a limitation somewhere, because it wan't clear to me. Are there other limitations that are not also not being called out? Thanks, Kent (as a contributor) From nobody Wed Jul 1 10:56:13 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 367FA1B29B6 for ; Wed, 1 Jul 2015 10:56:12 -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 vSodlMWzCJl3 for ; Wed, 1 Jul 2015 10:56:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 143391AD10A for ; Wed, 1 Jul 2015 10:56:05 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 824CB1AE0630; Wed, 1 Jul 2015 19:56:03 +0200 (CEST) Date: Wed, 01 Jul 2015 19:56:02 +0200 (CEST) Message-Id: <20150701.195602.2107505021524637233.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <5593F83D.3050900@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 17:56:12 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDEgSnVs IDIwMTUsIGF0IDE2OjI1LCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gSGkgTGFkYSwNCj4gPj4+IGF5DQo+ID4+PiAtDQo+ID4+PiAgICAgICAgIFRo ZSBzZXQgb2YgYW5ub3RhdGlvbnMgbXVzdCBiZSBleHRlbnNpYmxlIGluIGEgZGlzdHJpYnV0ZWQg bWFubmVyDQo+ID4+PiAgICAgICAgIHNvIGFzIHRvIGFsbG93IGZvciBkZWZpbmluZyBuZXcgYW5u b3RhdGlvbnMgd2l0aG91dCBydW5uaW5nIGludG8NCj4gPj4+ICAgICAgICAgdGhlIHJpc2sgb2Yg Y29sbGlzaW9ucyB3aXRoIGFubm90YXRpb25zIGRlZmluZWQgYW5kIHVzZWQgYnkNCj4gPj4+ICAg ICAgICAgb3RoZXJzLg0KPiA+Pj4gDQo+ID4+PiBXaGF0IGRvZXMgImluIGEgZGlzdHJpYnV0ZWQg bWFubmVyIiBtZWFuPw0KPiA+PiBJdCBtZWFucyB0aGF0IGRpZmZlcmVudCBwYXJ0aWVzIG5lZWRu J3QgY29vcmRpbmF0ZSB0aGUgbmFtZXMgYW5kIHVzZSBvZg0KPiA+PiBhbm5vdGF0aW9ucywgYXMg bG9uZyBhcyB0aGV5IGRvbid0IGNob29zZSBjb25mbGljdGluZyBZQU5HIG1vZHVsZSBuYW1lcw0K PiA+PiBvciBuYW1lc3BhY2UgVVJJcy4NCj4gPiBPaywgaXQgd2FzIG5vdCB0b28gY2xlYXIgKHRv IG1lKSBmcm9tIHRoZSB0ZXh0Lg0KPiANCj4gSSB3aWxsIGFkZCB0ZXh0IHRvIGV4cGxhaW4gd2hh dCDigJxkaXN0cmlidXRlZOKAnSBtZWFucy4NCg0KTWF5YmUgY2FsbCBpdCAiZGVjZW50cmFsaXpl ZCI/DQoNCg0KDQovbWFydGluDQo= From nobody Wed Jul 1 11:57:36 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 5B6441B2A46 for ; Wed, 1 Jul 2015 11:57:34 -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 TEwiGC8A3zas for ; Wed, 1 Jul 2015 11:57:32 -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 18A481B2A24 for ; Wed, 1 Jul 2015 11:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20687; q=dns/txt; s=iport; t=1435777052; x=1436986652; h=from:to:subject:date:message-id:mime-version; bh=LMSE4tF3BarkWOUJfJ6/dah9MALGE/v68pbSIk/02s0=; b=dW8Df0J2RP28ZupHm0RpsEgm+dYWkPQtp0o9g6KALqGgwj7VjJikQ619 02GnZ1U+WRkux8xHJmwMpNByie8ss2Srw9LajzCgHemuj3HQSA6p+bDx6 siaer6py+uU1wo7+L5plXpJUBtPme3yQEeTPqz9JKx4PPoo1nZScZ40j3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ACBABUN5RV/5ldJa1bgkVMVF8Ggxm6EwmBZAEJhS5KAhyBOjgUAQEBAQEBAYEKhCIBAQEEAQEBKkEXBgEIEQMBAQEoBQQlCxQJCgQBEogvDZhqnREGlwsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItKhFsHCQoNEYJcgUkFkS6CYgGEXIcEgTqPB4Qmg10mg3pvgUaBAgEBAQ X-IronPort-AV: E=Sophos; i="5.15,387,1432598400"; d="scan'208,217"; a="11901873" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 01 Jul 2015 18:57:31 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t61IvULF022922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 18:57:30 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.32]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 13:57:30 -0500 From: "Aseem Choudhary (asechoud)" To: FERDINAND Pienaar , "netmod@ietf.org" Thread-Topic: [netmod] three color meters in diffserv model Thread-Index: AQHQtC41RHpx0ScADk6EujuzutlwWg== Date: Wed, 1 Jul 2015 18:57:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.24.110.164] Content-Type: multipart/alternative; boundary="_000_D1B978FDD9C60asechoudciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] three color meters in diffserv model 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 Jul 2015 18:57:34 -0000 --_000_D1B978FDD9C60asechoudciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGVsbG8gRmVyZGksDQoNCldlIGhhdmUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiAzIG9mIHRo ZSBkcmFmdDoNCg0KIg0KDQogICBBIG1ldGVyIHF1YWxpZmllcyBpZiB0aGUgdHJhZmZpYyBhcnJp dmFsIHJhdGUgaXMgYmFzZWQgb24gYWdyZWVkIHVwb24NCiAgIHJhdGUgYW5kIHZhcmlhYmlsaXR5 LiAgQSBtZXRlciBpcyBnZW5lcmljYWxseSBtb2RlbGVkIGFzIHF1YWxpZnlpbmcNCiAgIHJhdGUg YW5kIHZhcmlhYmlsaXR5IGRlZmluZWQgYXMgYSB0b2tlbiBidWNrZXQuICBTaW5nbGUgcmF0ZSBt ZXRlcg0KICAgW1JGQzI2OTc8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI2OTc+XSBj YW4gYmUgZGVmaW5lZCBhcyB0d28gc3VjaCB0b2tlbiBidWNrZXRzIHdpdGggZmlyc3QNCiAgIGRl ZmluaW5nIHRoZSByYXRlIGFuZCBjb21taXR0ZWQgYnVyc3QgYW5kIGV4Y2VzcyBidXJzdCBmb3Ig c2Vjb25kIGJ1Y2tldC4NCg0KobANCg0KSSB0aGluayBpdCBjb3ZlcnMgcXVpdGUgd2hhdCB5b3Ug YXJlIHN1Z2dlc3RpbmcuIKGwT3ZlcmZsb3ehsSBpcyBpbXBsaWVkIGJ5IHRoZSBhbGdvcml0aG0u DQoNClJlZ2FyZHMsDQpBc2VlbQ0KDQpGcm9tOiBGRVJESU5BTkQgUGllbmFhciA8UGllbmFhci5G ZXJkaW5hbmRAYWxjYXRlbC1zYmVsbC5jb20uY248bWFpbHRvOlBpZW5hYXIuRmVyZGluYW5kQGFs Y2F0ZWwtc2JlbGwuY29tLmNuPj4NCkRhdGU6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgYXQgNTo1 OSBQTQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1v ZF0gdGhyZWUgY29sb3IgbWV0ZXJzIGluIGRpZmZzZXJ2IG1vZGVsDQoNCg0KSGVsbG8gQXNlZW0N Cg0KDQoNClRoYW5rcyBmb3IgeW91ciBhbnN3ZXIhIElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHks IHRoZSBhYnNlbmNlIG9mIHRoZSBsZWFmIG1ldGVyLXJhdGUgaGFzIHNwZWNpYWwgbWVhbmluZzog dGhlIGJ1Y2tldCBnZXRzIHRva2VucyBieSBvdmVyZmxvdyBmcm9tIGFub3RoZXIgYnVja2V0LiBT byBmb3IgUkZDIDI2OTcsIGJ1Y2tldCBDIGlzIGhhcyByYXRlIENJUiwgYW5kIGl0cyBmYWlsLWFj dGlvbiBuZXh0LW1ldGVyLWlkIHBvaW50cyB0byBidWNrZXQgRS4gQnVja2V0IEUgaGFzIG5vIGxl YWYgbWV0ZXItcmF0ZSwgc28gaXRzIHRva2VuIGluY3JlbWVudCBjb21lcyBmcm9tIGJ1Y2tldCBD J3Mgb3ZlcmZsb3cuDQoNCg0KDQpIb3cgaXMgaXQgZGV0ZXJtaW5lZCB3aGVyZSBhIGJ1Y2tldCdz IG92ZXJmbG93IGdvZXM/IEknbSBhc3N1bWluZyBpdCBpcyB0byB0aGUgYnVja2V0IHBvaW50ZWQg dG8gYnkgdGhlIG5leHQtbWV0ZXItaWQgaW4gaXRzIGZhaWwtYWN0aW9uIChpZiB0aGUgdGFyZ2V0 IGhhcyBubyByYXRlKSwgYnV0IHRoaXMgaXMgbm90IG9idmlvdXMgdG8gbWUgLS0gZG9lc24ndCB0 aGlzIHdob2xlIG1lY2hhbmlzbSBkZXNlcnZlIGEgbWVudGlvbiBpbiB0aGUgZGVzY3JpcHRpb24g b2YgdGhlIG1ldGVyLXJhdGUgYW5kL29yIGZhaWwtYWN0aW9uPyBPciBtYXliZSBpdKGvcyBzaW1w bGVyIHRoYW4gdGhhdCwgYW5kIHRva2VuIG92ZXJmbG93IGlzIGltcGxpZWQgb25seSBmb3IgYSBs aXN0IHdpdGggdHdvIG1ldGVycywgb25lIHdpdGggYSBtZXRlciByYXRlIGFuZCB0aGUgb3RoZXIg d2l0aG91dD8NCg0KDQoNClJlZ2FyZHMNCg0KDQoNCkZlcmRpDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQXNlZW0gQ2hvdWRoYXJ5IChhc2VjaG91ZCkgW21haWx0bzph c2VjaG91ZEBjaXNjby5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDEsIDIwMTUgMDQ6NDcN ClRvOiBGRVJESU5BTkQgUGllbmFhcjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gdGhyZWUgY29sb3IgbWV0ZXJzIGluIGRpZmZz ZXJ2IG1vZGVsDQoNCg0KDQpIZWxsbyBGZXJkaSwNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBxdWVz dGlvbiENCg0KDQoNClNpbmdsZSBSYXRlIFRocmVlIENvbG9yIE1hcmtpbmcgY2FuIGJlIHN1cHBv cnRlZCBieSBjb25maWd1cmluZyB0d28gbWV0ZXJzLCBvbmUgd2l0aCByYXRlIGFuZCBidXJzdCwg c2Vjb25kIHdpdGgganVzdCBidXJzdC4NCg0KDQoNCqn4Q291cGxpbmcgZmxhZ6n3IGZ1bmN0aW9u YWxpdHksIHdoaWNoIGlzIG1vcmUgZWZmZWN0aXZlIGluIGNvbG9yIGF3YXJlIG1vZGUsIGlzIG5v dCBkZWZpbmVkIGJ5IGFueSBvZiBkaWZmc2VydiBSRkOp9nMsIGFuZCBoZW5jZSBub3QgaW5jbHVk ZWQgaW4gdGhlIGN1cnJlbnQgbW9kZWwuDQoNCg0KDQpUaGlzIGZ1bmN0aW9uYWxpdHkgY2FuIGJl IGFkZGVkIGFzIHNlcGFyYXRlIGF1Z21lbnRhdGlvbiCp+G1lZqn3IG1vZHVsZSB0byBiYXNlIGRp ZmZzZXJ2IG1vZHVsZS4NCg0KDQoNClJlZ2FyZHMsDQoNCkFzZWVtDQoNCg0KDQpPbiA2LzI5LzE1 LCA5OjMwIFBNLCAiRkVSRElOQU5EIFBpZW5hYXIiDQoNCjxQaWVuYWFyLkZlcmRpbmFuZEBhbGNh dGVsLXNiZWxsLmNvbS5jbjxtYWlsdG86UGllbmFhci5GZXJkaW5hbmRAYWxjYXRlbC1zYmVsbC5j b20uY24+PiB3cm90ZToNCg0KDQoNCj5IZWxsbw0KDQo+DQoNCj5JIHRoaW5rIEkgc2VlIGhvdyBj b250YWluZXIgbWV0ZXItY2ZnIGlzIGludGVuZGVkIHRvIGFsbG93DQoNCj5jb25maWd1cmF0aW9u IG9mIFJGQyAyNjk3IGFuZCAyNjk4IHN0eWxlIG1ldGVycyAoYnkgbGlua2luZyB0d28gbWV0ZXJz DQoNCj5pbiB0aGUgbWV0ZXItbGlzdCB2aWEgdGhlIHBvaW50ZXIgbmV4dC1tZXRlci1pZCkuIEJ1 dCBpdCBzZWVtcyB0byBtZQ0KDQo+dGhhdCBhIHdheSB0byBpbmRpY2F0ZSBvdmVyZmxvdyBmcm9t IG9uZSBidWNrZXQgdG8gYW5vdGhlciBkdXJpbmcgdG9rZW4NCg0KPnVwZGF0ZSBpcyBuZWVkZWQu IEluIFJGQyAyNjk3LCBidWNrZXQgRSBpcyBpbmNyZW1lbnRlZCBvbmx5IGlmIGJ1Y2tldCBDDQoN Cj5pcyBmdWxsLCBpLmUuIEMgb3ZlcmZsb3dzIGludG8gRS4gSW4gUkZDIDI2OTgsIGJ1Y2tldHMg QyBhbmQgUCBhcmUNCg0KPnVwZGF0ZWQgaW5kZXBlbmRlbnRseS4NCg0KPg0KDQo+VGhlIE1ldHJv IEV0aGVybmV0IEZvcnVtJ3MgQmFuZHdpZHRoIFByb2ZpbGUgQWxnb3JpdGhtIGV4cGxpY2l0bHkN Cg0KPnN1cHBvcnRzIGNvbmZpZ3VyaW5nIHRoaXMgdHlwZSBvZiBjb3VwbGluZywgdmlhIHBhcmFt ZXRlciBDRiwgImNvdXBsaW5nDQoNCj5mbGFnIi4NCg0KPg0KDQo+SXQncyBub3QgY2xlYXIgdG8g bWUgaG93IFJGQyAyNjk3IGNhbiBiZSBzdXBwb3J0ZWQgYnkgY29uY2F0ZW5hdGluZyB0aGUNCg0K Pm1ldGVycyBpbiB0aGUgWUFORyBtb2RlbCwgdW5sZXNzIHRoZXJlIGlzIGEgd2F5IHRvIGluZGlj YXRlIG92ZXJmbG93DQoNCj5iZXR3ZWVuIHRoZW0uDQoNCj4NCg0KPkZlcmRpIFBpZW5hYXINCg0K PkFsY2F0ZWwgU2hhbmdoYWktQmVsbA0KDQo+DQoNCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KDQo+bmV0bW9k QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg== --_000_D1B978FDD9C60asechoudciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <07F42EF61CB3A946B6A5078ACA134FB4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGVsbG8gRmVy ZGksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XZSBoYXZlIGZvbGxvd2luZyB0ZXh0 IGluIHNlY3Rpb24gMyBvZiB0aGUgZHJhZnQ6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4mcXVvdDs8L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1z aXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czsiPiAgIEEgbWV0ZXIgcXVhbGlmaWVzIGlmIHRoZSB0cmFmZmljIGFy cml2YWwgcmF0ZSBpcyBiYXNlZCBvbiBhZ3JlZWQgdXBvbg0KICAgcmF0ZSBhbmQgdmFyaWFiaWxp dHkuICBBIG1ldGVyIGlzIGdlbmVyaWNhbGx5IG1vZGVsZWQgYXMgcXVhbGlmeWluZw0KICAgcmF0 ZSBhbmQgdmFyaWFiaWxpdHkgZGVmaW5lZCBhcyBhIHRva2VuIGJ1Y2tldC4gIFNpbmdsZSByYXRl IG1ldGVyDQogICBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI2OTci IHRpdGxlPSImcXVvdDtBIFNpbmdsZSBSYXRlIFRocmVlIENvbG9yIE1hcmtlciZxdW90OyI+UkZD MjY5NzwvYT5dIGNhbiBiZSBkZWZpbmVkIGFzIHR3byBzdWNoIHRva2VuIGJ1Y2tldHMgd2l0aCBm aXJzdA0KICAgZGVmaW5pbmcgdGhlIHJhdGUgYW5kIGNvbW1pdHRlZCBidXJzdCBhbmQgZXhjZXNz IGJ1cnN0IGZvciBzZWNvbmQgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyI+YnVja2V0Ljwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj6hsDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayBpdCBjb3ZlcnMgcXVpdGUgd2hhdCB5b3UgYXJl IHN1Z2dlc3RpbmcuIKGwT3ZlcmZsb3ehsSBpcyBpbXBsaWVkIGJ5IHRoZSBhbGdvcml0aG0uPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5Bc2VlbTwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1h bGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRF Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAw aW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJP UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5GRVJESU5BTkQgUGllbmFhciAmbHQ7PGEg aHJlZj0ibWFpbHRvOlBpZW5hYXIuRmVyZGluYW5kQGFsY2F0ZWwtc2JlbGwuY29tLmNuIj5QaWVu YWFyLkZlcmRpbmFuZEBhbGNhdGVsLXNiZWxsLmNvbS5jbjwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBKdW5lIDMwLCAyMDE1 IGF0IDU6NTkgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+UmU6IFtuZXRtb2RdIHRocmVlIGNvbG9yIG1ldGVycyBpbiBkaWZmc2VydiBtb2Rl bDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5l cmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRl ci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLyogUGFnZSBEZWZp bml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIiBzdHlsZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5IZWxsbyBBc2VlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZv ciB5b3VyIGFuc3dlciEgSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGFic2VuY2Ugb2Yg dGhlIGxlYWYgbWV0ZXItcmF0ZSBoYXMgc3BlY2lhbCBtZWFuaW5nOiB0aGUgYnVja2V0IGdldHMg dG9rZW5zIGJ5IG92ZXJmbG93IGZyb20gYW5vdGhlciBidWNrZXQuIFNvIGZvciBSRkMgMjY5Nywg YnVja2V0IEMgaXMgaGFzIHJhdGUgQ0lSLCBhbmQgaXRzDQogZmFpbC1hY3Rpb24gbmV4dC1tZXRl ci1pZCBwb2ludHMgdG8gYnVja2V0IEUuIEJ1Y2tldCBFIGhhcyBubyBsZWFmIG1ldGVyLXJhdGUs IHNvIGl0cyB0b2tlbiBpbmNyZW1lbnQgY29tZXMgZnJvbSBidWNrZXQgQydzIG92ZXJmbG93Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SG93IGlzIGl0IGRldGVybWluZWQgd2hlcmUgYSBidWNr ZXQncyBvdmVyZmxvdyBnb2VzPyBJJ20gYXNzdW1pbmcgaXQgaXMgdG8gdGhlIGJ1Y2tldCBwb2lu dGVkIHRvIGJ5IHRoZSBuZXh0LW1ldGVyLWlkIGluIGl0cyBmYWlsLWFjdGlvbiAoaWYgdGhlIHRh cmdldCBoYXMgbm8gcmF0ZSksIGJ1dCB0aGlzIGlzIG5vdCBvYnZpb3VzIHRvIG1lIC0tIGRvZXNu J3QgdGhpcyB3aG9sZQ0KIG1lY2hhbmlzbSBkZXNlcnZlIGEgbWVudGlvbiBpbiB0aGUgZGVzY3Jp cHRpb24gb2YgdGhlIG1ldGVyLXJhdGUgYW5kL29yIGZhaWwtYWN0aW9uPyBPciBtYXliZSBpdDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyI+oa88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPnMgc2ltcGxlciB0aGFuIHRoYXQsIGFuZCB0 b2tlbiBvdmVyZmxvdyBpcyBpbXBsaWVkIG9ubHkgZm9yIGEgbGlzdCB3aXRoDQogdHdvIG1ldGVy cywgb25lIHdpdGggYSBtZXRlciByYXRlIGFuZCB0aGUgb3RoZXIgd2l0aG91dD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZlcmRpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IEFzZWVtIENob3VkaGFyeSAoYXNlY2hvdWQpIFs8YSBocmVmPSJtYWlsdG86YXNlY2hvdWRA Y2lzY28uY29tIj5tYWlsdG86YXNlY2hvdWRAY2lzY28uY29tPC9hPl0NCjxicj4NClNlbnQ6IFdl ZG5lc2RheSwgSnVseSAwMSwgMjAxNSAwNDo0Nzxicj4NClRvOiBGRVJESU5BTkQgUGllbmFhcjsg PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4N ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSB0aHJlZSBjb2xvciBtZXRlcnMgaW4gZGlmZnNlcnYgbW9k ZWw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBGZXJkaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyBmb3IgeW91ciBxdWVzdGlvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNpbmdsZSBS YXRlIFRocmVlIENvbG9yIE1hcmtpbmcgY2FuIGJlIHN1cHBvcnRlZCBieSBjb25maWd1cmluZyB0 d28gbWV0ZXJzLCBvbmUgd2l0aCByYXRlIGFuZCBidXJzdCwgc2Vjb25kIHdpdGgganVzdCBidXJz dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+qfg8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPkNvdXBsaW5nIGZsYWc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPqn3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4gZnVuY3Rpb25hbGl0eSwgd2hpY2ggaXMgbW9yZSBlZmZlY3RpdmUgaW4gY29sb3IgYXdhcmUg bW9kZSwgaXMgbm90IGRlZmluZWQNCiBieSBhbnkgb2YgZGlmZnNlcnYgUkZDPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij6p9jwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+cywgYW5kIGhlbmNlIG5vdCBpbmNsdWRlZCBpbiB0aGUgY3Vy cmVudCBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgZnVuY3Rpb25hbGl0eSBj YW4gYmUgYWRkZWQgYXMgc2VwYXJhdGUgYXVnbWVudGF0aW9uDQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPqn4PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj5tZWY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTogJ0NvdXJpZXIgTmV3JzsiPqn3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gbW9kdWxl IHRvIGJhc2UgZGlmZnNlcnYgbW9kdWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+QXNlZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDYvMjkvMTUsIDk6 MzAgUE0sICZxdW90O0ZFUkRJTkFORCBQaWVuYWFyJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZsdDs8YSBocmVm PSJtYWlsdG86UGllbmFhci5GZXJkaW5hbmRAYWxjYXRlbC1zYmVsbC5jb20uY24iPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5QaWVuYWFyLkZlcmRp bmFuZEBhbGNhdGVsLXNiZWxsLmNvbS5jbjwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDtIZWxsbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDtJIHRoaW5rIEkgc2VlIGhvdyBjb250YWluZXIgbWV0ZXItY2ZnIGlzIGludGVuZGVkIHRvIGFs bG93DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0O2NvbmZpZ3VyYXRpb24gb2YgUkZDIDI2OTcgYW5kIDI2OTggc3R5 bGUgbWV0ZXJzIChieSBsaW5raW5nIHR3byBtZXRlcnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7aW4gdGhlIG1l dGVyLWxpc3QgdmlhIHRoZSBwb2ludGVyIG5leHQtbWV0ZXItaWQpLiBCdXQgaXQgc2VlbXMgdG8g bWUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7dGhhdCBhIHdheSB0byBpbmRpY2F0ZSBvdmVyZmxvdyBmcm9tIG9u ZSBidWNrZXQgdG8gYW5vdGhlciBkdXJpbmcgdG9rZW4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7dXBkYXRlIGlz IG5lZWRlZC4gSW4gUkZDIDI2OTcsIGJ1Y2tldCBFIGlzIGluY3JlbWVudGVkIG9ubHkgaWYgYnVj a2V0IEMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7aXMgZnVsbCwgaS5lLiBDIG92ZXJmbG93cyBpbnRvIEUuIElu IFJGQyAyNjk4LCBidWNrZXRzIEMgYW5kIFAgYXJlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O3VwZGF0ZWQgaW5k ZXBlbmRlbnRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7VGhlIE1ldHJvIEV0 aGVybmV0IEZvcnVtJ3MgQmFuZHdpZHRoIFByb2ZpbGUgQWxnb3JpdGhtIGV4cGxpY2l0bHkNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7c3VwcG9ydHMgY29uZmlndXJpbmcgdGhpcyB0eXBlIG9mIGNvdXBsaW5nLCB2 aWEgcGFyYW1ldGVyIENGLCAmcXVvdDtjb3VwbGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtmbGFnJnF1b3Q7 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtJdCdzIG5vdCBjbGVhciB0byBtZSBo b3cgUkZDIDI2OTcgY2FuIGJlIHN1cHBvcnRlZCBieSBjb25jYXRlbmF0aW5nIHRoZQ0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDttZXRlcnMgaW4gdGhlIFlBTkcgbW9kZWwsIHVubGVzcyB0aGVyZSBpcyBhIHdheSB0 byBpbmRpY2F0ZSBvdmVyZmxvdw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtiZXR3ZWVuIHRoZW0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0ZlcmRpIFBpZW5hYXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0FsY2F0 ZWwgU2hhbmdoYWktQmVsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7bmV0 bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D1B978FDD9C60asechoudciscocom_-- From nobody Wed Jul 1 13:04:28 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 D8FC61A8928; Wed, 1 Jul 2015 13:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 X3UF-7Du7e4z; Wed, 1 Jul 2015 13:04:25 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 C7D471A8920; Wed, 1 Jul 2015 13:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1435781043; bh=/jxqvAXjWH61Cd4haozZvt92+IPK//uE1uVwC/myMaY=; h=From:Subject:Date:To; b=NzNhiI+m9t462woQT5uDiXOZ/YK2fI1ekJ3TOvzJ/Rj7OAabxEfNljE9oi6akJZGM HTpmKxlCW/L9VE4rd6O40E7loeHPx4uFDxiGIjqHERuN2gY5HSJXiSA6Gx42nM9zls Gm/ogTh2ABXcMzLVl4OsXEeYKLFJJ/cGPFi5Nc/E= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <68398E44-38BB-4E7F-8FF2-D435852CC017@lucidvision.com> Date: Wed, 1 Jul 2015 16:03:51 -0400 To: rtg-yang-coord@ietf.org, NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=9 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 47, in=384, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Subject: [netmod] Initial IEEE Yang Models Committed 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 Jul 2015 20:04:27 -0000 =09 FYI, There was discussion of IEEE/Ethernet models a while back. I = wanted to let everyone know that an initial one was just pushed.=20 https://github.com/YangModels/yang/tree/master/experimental/ieee =E2=80=94Tom From nobody Wed Jul 1 17:45: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 F10DD1B2C70 for ; Wed, 1 Jul 2015 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjGpvz-MfUHo for ; Wed, 1 Jul 2015 17:44:58 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 8551B1B2C40 for ; Wed, 1 Jul 2015 17:44:57 -0700 (PDT) Received: by lagx9 with SMTP id x9so51035918lag.1 for ; Wed, 01 Jul 2015 17:44:56 -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=WxiCcsjkFmn25SbrY5XpPWvwLrliWrIKhHKa6yDo9Vk=; b=d/0CoPR9dc1oR0N08RqgFg1lshsBFLGuA6m0TYzBY4/jb1/mbCcXtwRrxGETq8cJGX ApDRz1HQqUVC1PCqnPoGeFtSLrp0lusOyWGSv5yyGrIoaBbuwwdu1G7p9ccizEUlMQVT tdp3RxiMSb3+qbRIcigPS27Cgu89tjf8zOGSbq7ixdDF1v5rsKG8kWHCJ/GJsJ+ijQJ7 /NCKaXrlDTbYWKYam6hz+4WXD0LEtiCcFEpCca+ct7JMBQKNA+ZwrJZC9pbjYAHmKP9X EL/qKQ/axR09/5phXBeXzCABf6tuqCLB26iQHTYVLg30F2pAP1h8dNX2NtGGRaKuOPj6 0O6w== X-Gm-Message-State: ALoCoQmjPRM5P1rd642z9K96M6DXGUNmxXPwDlPRNAOJW+xC3uSMa4Hn5L4lS0hFYpeQODOIqUE+ MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr27796246lab.82.1435797895889; Wed, 01 Jul 2015 17:44:55 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Jul 2015 17:44:55 -0700 (PDT) In-Reply-To: References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> <20150630124503.GA5406@elstar.local> Date: Wed, 1 Jul 2015 17:44:55 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3677e8de18c0519d9bfbe Archived-At: Subject: Re: [netmod] Y45-04 and ietf-yang-library 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 Jul 2015 00:45:01 -0000 --001a11c3677e8de18c0519d9bfbe Content-Type: text/plain; charset=UTF-8 Hi, I am going to update the draft so the conformance leaf is an enumeration with 'implement' and 'import' enums. The 'none' enum is not needed because the deviations are listed inside the module entry. A module server would return the conformance for the proxied server, not itself. No new objects will be added. Only item # is being addressed. Every module the server implements with be listed once with conformance=implement. Every module and revision that those modules import (rippled through all imports) will be listed in the library, with conformance=import, except of course if the imported module is also an implemented module. No other modules will be listed. Andy On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman wrote: > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Writing as technical contributor... >> >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: >> > Hi, >> > >> > Here's a short summary, and then some questions for the WG. >> > >> > The ietf-yang-library module is designed to serve two purposes: >> > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 >> > modules. >> > >> > 2. A list of the YANG modules stored in a server. >> > >> > >> > Q1. Do you agree with these goals? >> >> I primarily care about goal 1. >> >> > Q2. Should this module be designed to work with both YANG 1.0 and >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? >> > >> > If it should not be defined using YANG 1.1, why is this module >> > special? >> >> I assume this module will sooner or later be YANG 1.1 anyway. >> >> > Q3. Should the /modules/module list be designed to store both YANG >> > 1.0 and YANG 1.1 modules? >> >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have >> revised all published YANG data models that were written using YANG >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG >> 1.1 modules. >> > > > Yes -- We also agreed that we would not be republishing modules > just to change the yang-version to 1.1. > > There are lots of YANG modules in progress at this time. > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > It seems rather disruptive to declare all module must be YANG 1.1 > since it has not even made it through WGLC yat, let alone > be published as an RFC, let alone be implemented > in real tool-chains. > > I suspect if people find out the only think YANG 1.1 in their module > (preventing their existing tools from working) is a yang-version-stmt, > they might not be too happy. > > > Andy > > >> >> > Q4. Consider these modules, which both import foo without revision: >> > >> > module a { ... import foo; ... } >> > module b { ... import foo; ... } >> > >> > Do we require a server that implements both a and b to use the >> > same revision of foo? >> > >> > If the answer is yes, we need to indicate the default revision >> > that the server uses in the model: >> > >> > container modules { >> > ... >> > list module { >> > ... >> > leaf default-revision { >> > type boolean; >> > default false; >> > description >> > "Indicates that this revision is used by the server if >> > this module is imported without a specific revision >> > date."; >> > } >> > } >> > } >> > >> > If the answer is no, note that this puts an implementation burden >> > on the client. A client cannot simply download all listed >> > modules, and load/compile/process them as one set. >> > >> > If the anwser is no, I propose that we extend the module as such: >> > >> > container modules { >> > ... >> > list module { >> > ... >> > list imported-without-revision { >> > key "name revision"; >> > ... >> > } >> > } >> > } >> > >> > A server could then list: >> > >> > >> > a >> > 2015-01-01 >> > >> > foo >> > 2002-02-02 >> > >> > >> > >> > b >> > 2015-01-01 >> > >> > foo >> > 2001-01-01 >> > >> > >> >> I believe truth is advertisement is a good thing. In the SNMP world, >> not all pieces of the instrumentation were moving at the same pace and >> I would be somewhat surprised if this would be the case for all >> implementations in the NETCONF world. Hence, I rather accept that an >> import of foo without revision may resolve to different versions of >> foo for different imports. >> >> /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 >> > > --001a11c3677e8de18c0519d9bfbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am going to update the draft so t= he conformance leaf
is an enumeration with 'implement' an= d 'import' enums.
The 'none' enum is not needed b= ecause the deviations are
listed inside the module entry.=C2=A0 A= module server would return
the conformance for the proxied serve= r, not itself.

No new objects will be added.
=
Only item # is being addressed.

Every module = the server implements with be listed once
with conformance=3Dimpl= ement.=C2=A0 Every module and revision
that those modules import = (rippled through all imports) will be listed
in the library, with= conformance=3Dimport, except of
course if the imported module is= also an implemented module.
No other modules will be listed.


Andy


On Tue, Jun 30, 2015 at = 11:10 AM, Andy Bierman <andy@yumaworks.com> wrote:

<= br>
On Tue, Jun 30, 2015 at 5:45 AM, Juergen Scho= enwaelder <j.schoenwaelder@jacobs-university.de>= wrote:
Writing as technical contr= ibutor...

On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
> Hi,
>
> Here's a short summary, and then some questions for the WG.
>
> The ietf-yang-library module is designed to serve two purposes:
>
>=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisement mechanism fo= r YANG 1.1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
>
>=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored in a server. >
>
> Q1.=C2=A0 Do you agree with these goals?

I primarily care about goal 1.

> Q2.=C2=A0 Should this module be designed to work with both YANG 1.0 an= d
>=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it have yang-versi= on 1.1 or not?
>
>=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YANG 1.1, why is= this module
>=C2=A0 =C2=A0 =C2=A0 special?

I assume this module will sooner or later be YANG 1.1 anyway.

> Q3.=C2=A0 Should the /modules/module list be designed to store both YA= NG
>=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?

Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.


Yes -- We a= lso agreed that we would not be republishing modules
just to chan= ge the yang-version to 1.1.

There are lots of YANG= modules in progress at this time.
Perhaps 3 out of 100 are relyi= ng on YANG 1.1 statements.
It seems rather disruptive to declare = all module must be YANG 1.1
since it has not even made it through= WGLC yat, let alone
be published as an RFC, let alone be impleme= nted
in real tool-chains.

I suspect if p= eople find out the only think YANG 1.1 in their module
(preventin= g their existing tools from working) is a yang-version-stmt,
they= might not be too happy.


Andy
=
=C2=A0

> Q4.=C2=A0 Consider these modules, which both import foo without revisi= on:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ... }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ... }
>
>=C2=A0 =C2=A0 =C2=A0 Do we require a server that implements both a and = b to use the
>=C2=A0 =C2=A0 =C2=A0 same revision of foo?
>
>=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to indicate the defa= ult revision
>=C2=A0 =C2=A0 =C2=A0 that the server uses in the model:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-revision {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indicates= that this revision is used by the server if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this modu= le is imported without a specific revision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0date.&quo= t;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this puts an implem= entation burden
>=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot simply downlo= ad all listed
>=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process them as one set.=
>
>=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that we extend the = module as such:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-without-revisio= n {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name revisio= n";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 A server could then list:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</revisi= on>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2002-02-02<= /revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</revisi= on>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2001-01-01<= /revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>

I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.

/js

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

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


--001a11c3677e8de18c0519d9bfbe-- From nobody Wed Jul 1 23:33: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 4C6CF1B2F8D for ; Wed, 1 Jul 2015 23:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2BqSEj6BBX4e for ; Wed, 1 Jul 2015 23:33:08 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 21D931B2F8C for ; Wed, 1 Jul 2015 23:33:07 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id F1EB41CC035D; Thu, 2 Jul 2015 08:33:11 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jul 2015 08:33:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 06:33:10 -0000 Andy Bierman writes: > I agree with Juergen that the implementation of YANG constraints > on a datastore is not XML-specific. The text refers to data nodes > not XML elements. It is quite possible for a server to populate data The text says in sec. 6.4: "The data model used in the XPath expressions is the same as that used in XPath 1.0 [XPATH], =E2=80=A6", and the data mod= el in [XPATH] is about elements, attributes, namespaces etc. In order to correctly interpret [XPATH], one needs to map (conceptually, if you wish) the data tree onto the XPath data model. > nodes in a datastore without NETCONF of XML being involved. And what about RPCs and notifications? In this case the accessible data tree is defined as the corresponding XML instance document. Consider this definition: rpc foo { input { leaf x { type uint8; must ". =3D ../y"; } leaf y { type string; } } } Then what's the result of conceptual XPath evaluation for this RPC request? +1 1 And how about this RPC input in JSON? { "foorpc:input": { "x": +1, "y": "1" } } > > We keep getting stuck on the difference between resource representations > on the wire, and implementation details within a client or server. This is not my problem here. Lada > There is no requirement that they be the same "XML or JSON". > inside. > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 2 03:55: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 538B41B3193 for ; Thu, 2 Jul 2015 03:55:00 -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 nxiolrWPp0Vc for ; Thu, 2 Jul 2015 03:54:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EB4121B3192 for ; Thu, 2 Jul 2015 03:54:57 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0D45B1CC046E; Thu, 2 Jul 2015 12:55:01 +0200 (CEST) From: Ladislav Lhotka To: Benoit Claise In-Reply-To: <5593FC1A.4020501@cisco.com> References: <5591D162.4010100@cisco.com> <5593F83D.3050900@cisco.com> <5593FC1A.4020501@cisco.com> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jul 2015 12:54:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 10:55:00 -0000 Benoit Claise writes: > Hi Lada, >> >>>>> >>>>> - In the introduction, you mention: >>>>> Typical use cases are: >>>>> >>>>> o Deactivating a subtree in a configuration datastore while keeping >>>>> the data in place. >>>>> >>>>> o Complementing data model information with instance-specific data. >>>>> >>>>> o RPC operations may use metadata annotations for various purposes >>>>> in both requests and responses. For example, the >>>>> operation in the NETCONF protocol (seesection 7.2 of [RFC6241] ) >>>>> uses annotations in the form of XML attributes for identifying the >>>>> point in the configuration and type of the operation. >>>>> >>>>> >>>>> Don't you have any other examples than those 3? >>>>> What about showing these examples with the spec. in this document? >>>>> Note: I see that the first one is documented with module >>>>> example-inactive >>>> Well, the backlash I received with >>>> draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there >>>> is consensus about general utility of annotations, practical definitions >>>> may be controversial. >>> Even as example? >> Yes, I am afraid. > I would be in favor to have at the very minimum one example. > Otherwise, it's difficult to visualize how these metadata should be > used. Sure, there will be at least one. I just have to select an appropriate one to demonstrate the intended use without stirring up some ghosts. Lada > > Regards, Benoit (as a contributor) -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 2 03:56: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 B83531B3193 for ; Thu, 2 Jul 2015 03:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 H1iqdqzQhtbg for ; Thu, 2 Jul 2015 03:55:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2FD1B3194 for ; Thu, 2 Jul 2015 03:55:58 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 1CD561CC046E; Thu, 2 Jul 2015 12:56:03 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Benoit Claise In-Reply-To: References: <5591D162.4010100@cisco.com> <5593F83D.3050900@cisco.com> <5593FC1A.4020501@cisco.com> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jul 2015 12:55:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 10:55:59 -0000 Andy Bierman writes: > On Wed, Jul 1, 2015 at 7:41 AM, Benoit Claise wrote: > >> Hi Lada, >> >>> >>> >>>>>> - In the introduction, you mention: >>>>>> Typical use cases are: >>>>>> >>>>>> o Deactivating a subtree in a configuration datastore while >>>>>> keeping >>>>>> the data in place. >>>>>> >>>>>> o Complementing data model information with instance-specific >>>>>> data. >>>>>> >>>>>> o RPC operations may use metadata annotations for various >>>>>> purposes >>>>>> in both requests and responses. For example, the >>>>>> operation in the NETCONF protocol (seesection 7.2 of [RFC6241] >>>>>> ) >>>>>> uses annotations in the form of XML attributes for identifying >>>>>> the >>>>>> point in the configuration and type of the operation. >>>>>> >>>>>> >>>>>> Don't you have any other examples than those 3? >>>>>> What about showing these examples with the spec. in this document? >>>>>> Note: I see that the first one is documented with module >>>>>> example-inactive >>>>>> >>>>> Well, the backlash I received with >>>>> draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there >>>>> is consensus about general utility of annotations, practical definitions >>>>> may be controversial. >>>>> >>>> Even as example? >>>> >>> Yes, I am afraid. >>> >> I would be in favor to have at the very minimum one example. >> Otherwise, it's difficult to visualize how these metadata should be used. >> >> > > We support an attribute called "owner" which is basically the I2RS > client-id. > At ;least one solution proposal for I2RS is going to allow retrieval of the > metadata from the ephemeral datastore (e.g., client-id, secondary-id). > Perhaps an example like this will not be controversial. Yes, this looks like a good one, thanks. Lada > > > >> Regards, Benoit (as a contributor) >> > > > Andy > > >> >> _______________________________________________ >> 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 Jul 2 03:56: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 60C091B3193 for ; Thu, 2 Jul 2015 03:56: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 NgRTjSfoVn68 for ; Thu, 2 Jul 2015 03:56:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 468BC1B3189 for ; Thu, 2 Jul 2015 03:56:57 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3559F1CC046E; Thu, 2 Jul 2015 12:57:02 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150701.195602.2107505021524637233.mbj@tail-f.com> References: <5593F83D.3050900@cisco.com> <20150701.195602.2107505021524637233.mbj@tail-f.com> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jul 2015 12:56:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 10:56:58 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >>=20 >> > On 01 Jul 2015, at 16:25, Benoit Claise wrote: >> >=20 >> > Hi Lada, >> >>> ay >> >>> - >> >>> The set of annotations must be extensible in a distributed m= anner >> >>> so as to allow for defining new annotations without running = into >> >>> the risk of collisions with annotations defined and used by >> >>> others. >> >>>=20 >> >>> What does "in a distributed manner" mean? >> >> It means that different parties needn't coordinate the names and use = of >> >> annotations, as long as they don't choose conflicting YANG module nam= es >> >> or namespace URIs. >> > Ok, it was not too clear (to me) from the text. >>=20 >> I will add text to explain what =E2=80=9Cdistributed=E2=80=9D means. > > Maybe call it "decentralized"? Yes, this looks better. Lada > > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 2 04:28:48 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 732F31B31C6 for ; Thu, 2 Jul 2015 04:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WANT=2.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 Ci-O9ICYXBmT for ; Thu, 2 Jul 2015 04:28:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 799C41B31DB for ; Thu, 2 Jul 2015 04:28:41 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A68C61CC046E; Thu, 2 Jul 2015 13:28:46 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Jul 2015 13:28:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 11:28:46 -0000 Kent Watsen writes: >>>1. In Section 3, it says: >>> >>> >>> Does this mean that the annotation A can be used by *any* module >>> the server advertises, or just the modules that define/import >>> annotation A? >> >>For all modules implemented by the server, no import is needed. > > > Good, but I think the text should say this explicitly. OK. > > > >>> I assume that the intent is for the annotation to apply to >>> the server as a whole, not any specific module. It might >> >>Yes. The description can also say that the annotation is ignored >>elsewhere. > > Maybe I don't understand your response, but if we agree that annotations > are a server-level thing (not module-specific), then I do not agree that a > module's description should be able to say that an annotation should be > ignored in other modules. > It depends on the annotation's semantics, and it may be designed to do something only for certain node instances (such as leafs with union type), or for nodes in a given namespace etc. Do you think it may be a problem? > > >>> help enforce this if annotations can only be defined in >>> modules that don't define any data-nodes and it is required >>> that the server advertises this module explicitly (not via >>> an import)... >> >>I expect this will be the normal way of defining annotations, and it >>could appear in the document as a guideline. I don't think though it is >>necessary to state it as a hard rule. > > OK, a SHOULD or RECOMMENDED statement would help to clarify this. > OK. > > >>>3. In Section 4.2.2, adding metadata to the first entry in a list doesn't >>> seem elegant. Can we instead create a special list element like the >>> following? >> >>Maybe I don't understand but the idea is that a separate metadata objects >>can be attached to any or all entries of a list. In the example it is >>added only to the first entry but another metadata object could be added >>to the second entry as well. > > I see, but then this make the example misleading. I thought it was trying > to show how to place an annotation on the list as a whole. I see now > it says "list instance", but this seems uninteresting example, as list I will use "list entry" because the term "instance" in not defined in YANG. > instances are just nodes for which how to apply annotations is already > known - there's nothing special about the node being a list element - > right? Do you suggest to remove the second example in that section? But you also wanted to add an example on "anydata" that is arguable even more alike to a container. > > > > >>It is not possible to add an annotation to the whole list, also because >>this cannot be represented in XML encoding (via attributes). > > An annotation cannot be attached to a list as a whole? - that seems > fundamentally broken, though I understand why you say it cannot be easily > represented in XML (via attributes). Should we consider alternative > representations? I agree it might be useful, and I was thinking about it but I haven't found any good way for encoding it in XML, also because in XML list entries can be interspersed with other elements. > > That said, if unavoidable, the draft needs to call that out as a > limitation somewhere, because it wan't clear to me. Are there other > limitations that are not also not being called out? Well, one could e.g. think about structured annotations but this is again not exactly easy with XML attributes. I don't think though we can really call it limitations - after all, the motivation for this document was to "officialize" the use of XML attributes, so it would be a bit weird to to make it incompatible with them. Lada > > > > > Thanks, > Kent (as a contributor) > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 2 09:55: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 280281A0127 for ; Thu, 2 Jul 2015 09:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WANT=2.3, SPF_HELO_PASS=-0.001, 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 NEiqMUeRpvlS for ; Thu, 2 Jul 2015 09:55:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE271A011E for ; Thu, 2 Jul 2015 09:55:40 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.195.15; Thu, 2 Jul 2015 16:55:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Thu, 2 Jul 2015 16:55:19 +0000 From: Kent Watsen To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) Thread-Index: AQHQs3aEh3sCPrCqSkegq1SWU9kekZ3GR8OAgAA8lgCAAYk0AIAAGDUA Date: Thu, 2 Jul 2015 16:55:19 +0000 Message-ID: References: In-Reply-To: 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: nic.cz; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:OSKfNuGrZ9QAqn3GUVPASLCBySKERhCdPpHVkoJo2S64CpKicp0uKYaG3o5BAYLFYBMI2h84xuj6PsHX/xD98IqC/qepiu/lyF2aGEsXREOAR53iiGGICt87xX/YMyHzPpt6hisZ+2+fN8/iqdtBYw==; 24:GuQ2rxwTvumfstrb3bwmn6v3JbOofuge9EBPvEHQBdCco4gZ3LK4EduW6W1F5kiIryRd5yjaU9Df9RUXZ9OuQraLWNfZF34cUOL53M7lOi8=; 20:6bov87Eyztk1I+Y/urg7Zsul97sm63/1aSPO2scWfoDbEcUWFRO9dbo68D+YXC3qXjqtjFJfGdpeWaBeLVhzwg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06259BA5A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(5423002)(46102003)(107886002)(66066001)(2950100001)(36756003)(5001960100002)(40100003)(2900100001)(83506001)(230783001)(122556002)(77156002)(62966003)(189998001)(102836002)(5002640100001)(106116001)(99286002)(86362001)(5001770100001)(76176999)(87936001)(54356999)(2656002)(93886004)(2501003)(5890100001)(50986999)(92566002)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <7791022FABEC354295B9D4BEDFBEFC71@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2015 16:55:19.2492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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 Jul 2015 16:55:42 -0000 >>>Maybe I don't understand your response, but if we agree that annotations >> are a server-level thing (not module-specific), then I do not agree >>that a >> module's description should be able to say that an annotation should be >> ignored in other modules. >> > >It depends on the annotation's semantics, and it may be designed to do >something only for certain node instances (such as leafs with union >type), or for nodes in a given namespace etc. Do you think it may be a >problem? Those kinds of uses are fine, as they are not module-specific. I just want to ensure we don't ever wind up with module-specific annotations.... >> I see, but then this make the example misleading. I thought it was >>trying >> to show how to place an annotation on the list as a whole. I see now >> it says "list instance", but this seems uninteresting example, as list > >I will use "list entry" because the term "instance" in not defined in >YANG. > >> instances are just nodes for which how to apply annotations is already >> known - there's nothing special about the node being a list element - >> right? > >Do you suggest to remove the second example in that section? But you >also wanted to add an example on "anydata" that is arguable even more >alike to a container. Yes, an example for each item discussed (including anydata) is desired. What I'm questioning here is why we need to discuss annotating list entries at all, since they seem to follow normal rules. If true, I recommend removing a special section for list entries/instances entirely. >>>An annotation cannot be attached to a list as a whole? - that seems >> fundamentally broken, though I understand why you say it cannot be >>easily >> represented in XML (via attributes). Should we consider alternative >> representations? > >I agree it might be useful, and I was thinking about it but I haven't >found any good way for encoding it in XML, also because in XML list >entries can be interspersed with other elements. Interspersed with other elements? - I don't understand. For instance, assuming: container foobars { list foo { ... } list bar { } } The XML would be: ... ... ... ... ... ... Where is the interspersion? As for how to place annotations on an XML list as a whole, I was thinking we could use a fake first element. For instance, the following shows an annotation on the "bar" list: ... ... ... // colors entire list "red" (notice empty element) ... ... ... But this is most likely illegal since it's not a valid instance document. So then maybe we could use an XML comment like this: ... ... ... ... ... ... Ugh, this isn't great either. Anybody else have an idea? >>That said, if unavoidable, the draft needs to call that out as a >> limitation somewhere, because it wan't clear to me. Are there other >> limitations that are not also not being called out? > >Well, one could e.g. think about structured annotations but this is >again not exactly easy with XML attributes. I don't think though we can >really call it limitations - after all, the motivation for this document >was to "officialize" the use of XML attributes, so it would be a bit >weird to to make it incompatible with them. True, I'd rather we can find a solution for annotating XML lists. Until then, the draft SHOULD explicitly call it out as not supported. Maybe put in into an OPEN ISSUES section? Thanks, Kent (as a contributor) From nobody Thu Jul 2 13:08:09 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 2FF541A8F34 for ; Thu, 2 Jul 2015 13:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 X4BxguH28xBl for ; Thu, 2 Jul 2015 13:08:06 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 D13471A8BAF for ; Thu, 2 Jul 2015 13:08:05 -0700 (PDT) Received: by laar3 with SMTP id r3so68298861laa.0 for ; Thu, 02 Jul 2015 13:08: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=xtpQAkI9l/W31SX4FO6XW7v12bAKDfp+4KKx5qZSmj4=; b=EbX1AIZPADfBVpVoYpoYNlI/Vg3Ks9LweZtdn0fUxCj8vdCTtJecKx+qMJjU0CHOKh vq9392oBf+ztsJeIiNoCU9ogd/1ZeAzh2UxKJehyL6J1bBvseQwu6AaX4sbubiYPyX+i D7MDVilmV+74d8wuRyCfb65AvI134W6giH78VchKZa5z15vszunWIEvFDC8tSwoqxMZi tltlsv6Fxu/MIKr7xohS0YDIcxbdHlnuAOGL2j97QDmsqaS7TGF6jvt5hU9FZjVP6svP ihNgHFRPsaXIWgHVxNnfFG3YJXjWsuAqRIWbkV3tPMGxY+rCPf3ND0HyUw3muIuGWXte 8ZOg== X-Gm-Message-State: ALoCoQkjFriGq4lSRby9QJXkLwnQ8TG7mZvVx3i4yc0HCMK+C222lQSFjX4fchSxyqydMA1IPvKM MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr32321411lbp.88.1435867684215; Thu, 02 Jul 2015 13:08:04 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Jul 2015 13:08:04 -0700 (PDT) In-Reply-To: References: <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> Date: Thu, 2 Jul 2015 13:08:04 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113403d84336990519e9ffa0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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 Jul 2015 20:08:08 -0000 --001a113403d84336990519e9ffa0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2015 at 11:33 PM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > I agree with Juergen that the implementation of YANG constraints > > on a datastore is not XML-specific. The text refers to data nodes > > not XML elements. It is quite possible for a server to populate data > > The text says in sec. 6.4: "The data model used in the XPath expressions > is the same as that used in XPath 1.0 [XPATH], =E2=80=A6", and the data m= odel in > [XPATH] is about elements, attributes, namespaces etc. In order to > correctly interpret [XPATH], one needs to map (conceptually, if you > wish) the data tree onto the XPath data model. > > > nodes in a datastore without NETCONF of XML being involved. > > And what about RPCs and notifications? In this case the accessible data > tree is defined as the corresponding XML instance document. > > There is no possibility for data to be converted between XML and JSON if this is the case. > Consider this definition: > > rpc foo { > input { > leaf x { > type uint8; > must ". =3D ../y"; > } > leaf y { > type string; > } > } > } > > Then what's the result of conceptual XPath evaluation for this RPC > request? > > Just because you can construct a pathological case comparing strings and numbers doesn't mean anything. Use "number(foo) < number(bar)" to ensure that numeric comparisons are done correctly. > > +1 > 1 > > > > And how about this RPC input in JSON? > > { > "foorpc:input": { > "x": +1, > "y": "1" > } > } > > > > > We keep getting stuck on the difference between resource representation= s > > on the wire, and implementation details within a client or server. > > This is not my problem here. > > There are lots of XPath expressions that can be constructed that create problems because of the way XPath converts types by default. That is why there are functions number(), string(), etc. > Lada > Andy > > > There is no requirement that they be the same "XML or JSON". > > inside. > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a113403d84336990519e9ffa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 11:33 PM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> I agree with Juergen that the implementation of YANG constraints
> on=C2=A0 a datastore is not XML-specific.=C2=A0 The text refers to dat= a nodes
> not XML elements.=C2=A0 It is quite possible for a server to populate = data

The text says in sec. 6.4: "The data model used in the XPath expressio= ns
is the same as that used in XPath 1.0 [XPATH], =E2=80=A6", and the dat= a model in
[XPATH] is about elements, attributes, namespaces etc. In order to
correctly interpret [XPATH], one needs to map (conceptually, if you
wish) the data tree onto the XPath data model.

> nodes in a datastore without NETCONF of XML being involved.

And what about RPCs and notifications? In this case the accessible data
tree is defined as the corresponding XML instance document.



There is no possibility= for data to be converted between
XML and JSON if this is the cas= e.

=C2=A0
Consider this definition:

=C2=A0 rpc foo {
=C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 leaf x {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint8;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 must ". =3D ../y";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 leaf y {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }

Then what's the result of conceptual XPath evaluation for this RPC
request?



Just because you can co= nstruct a pathological
case comparing strings and numbers doesn&#= 39;t
mean anything.

Use "number(foo= ) < number(bar)" to ensure that
numeric comparisons are d= one correctly.



<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" message= -id=3D"101">
=C2=A0 <foo xmlns=3D"http://example.com/xtest">
=C2=A0 =C2=A0 <x>+1</x>
=C2=A0 =C2=A0 <y>1</y>
=C2=A0 </foo>
</rpc>

And how about this RPC input in JSON?

{
=C2=A0 "foorpc:input": {
=C2=A0 =C2=A0 "x": +1,
=C2=A0 =C2=A0 "y": "1"
=C2=A0 }
}

>
> We keep getting stuck on the difference between resource representatio= ns
> on the wire, and implementation details within a client or server.

This is not my problem here.



There are lots of XPath= expressions that can be constructed
that create problems because= of the way XPath converts
types by default.=C2=A0 That is why th= ere are functions number(), string(), etc.


=C2=A0
Lada

Andy
=C2=A0

> There is no requirement that they be the same "XML or JSON".=
> inside.
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a113403d84336990519e9ffa0-- From nobody Thu Jul 2 14:04:05 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 8C1801A0266; Thu, 2 Jul 2015 14:04:01 -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 to04q0UljmoK; Thu, 2 Jul 2015 14:04:00 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 3AD161A038D; Thu, 2 Jul 2015 14:04:00 -0700 (PDT) Received: by pactm7 with SMTP id tm7so45867066pac.2; Thu, 02 Jul 2015 14:04:00 -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=B2aatS6Q2+3086S98M3ZVrpdLWDlq3Q3nEuxtuWo2a8=; b=MhlecoPhng17aOir3fnn3BYHI2TH/Jibmyn+rd1ygg0/Zpo+kgU1/Zm/BJu+duK/60 fpwabbHI9GQ3Kx4Iet6kzyOXocAbRvF9W8qSf7BYujgcb89gcBfnMg61CjQDPZ78aLdS fsogZnswq8MbjSH9GNQJuAE1CFznUFfRqmLDKl65R8Wt+R91EdP9iv52SWWA574ScD7f EDHxY3gCj3Ixt4z3wJ2XWemxiKMSDJ+h+NSe6Rk5tnBRldpqfnKuzAkfX2AUU7if7msC gGNepSmrSt2S6K+qeECyoq0Y93Js7iHcVTMYmcRCYySFM2nNzB6VVuaSPBaOLgvtE4BK eTeA== X-Received: by 10.66.121.230 with SMTP id ln6mr13230571pab.17.1435871039973; Thu, 02 Jul 2015 14:03:59 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id mk6sm6691816pab.9.2015.07.02.14.03.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 14:03:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 2 Jul 2015 14:06:00 -0700 Message-Id: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , NETMOD Working Group , "BRUNGARD, DEBORAH A" , Netconf , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) 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 Jul 2015 21:04:01 -0000 --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) = wrote: >=20 > What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2= =80=9D are met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. =46rom a = personal perspective it would certainly help to have examples of how the = requirements could be met. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

What might be = interesting for a NETCONF speaking slot is an analysis of what = requirements from =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D = are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. 

Susan or somebody from i2rs WG can = decide whether the suggested presentation would help clarify i2rs = requirements to NETCONF. =46rom a personal perspective it would = certainly help to have examples of how the requirements could be = met.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59-- From nobody Thu Jul 2 14:06:49 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 A8BA01A1A59; Thu, 2 Jul 2015 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Skv4ZI2vbl91; Thu, 2 Jul 2015 14:06:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 253CC1A1A78; Thu, 2 Jul 2015 14:06:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" , "'Eric Voit \(evoit\)'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> In-Reply-To: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> Date: Thu, 2 Jul 2015 17:06:41 -0400 Message-ID: <01d801d0b50a$feeed5f0$fccc81d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01D0B4E9.77DEBC90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCCiG/twIuXbN7nP05VtA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , 'Netconf' Subject: Re: [netmod] [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) 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 Jul 2015 21:06:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D9_01D0B4E9.77DEBC90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 I think this would really help show how the requirements can be met. = Let=E2=80=99s plan on Eric doing an analysis of what requirements are = met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani Sent: Thursday, July 02, 2015 5:06 PM To: Eric Voit (evoit) Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; = BRUNGARD, DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS = protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 =20 On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) wrote: =20 What might be interesting for a NETCONF speaking slot is an analysis of = what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. From a = personal perspective it would certainly help to have examples of how the = requirements could be met. =20 Cheers. =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_01D9_01D0B4E9.77DEBC90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

I think this would really help show how the requirements can be met. = Let=E2=80=99s plan on Eric doing an analysis of what requirements are = met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. =

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Thursday, July 02, 2015 5:06 = PM
To: Eric Voit (evoit)
Cc: = Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; BRUNGARD, = DEBORAH A; Alexander Clemm (alex); Netconf; Susan = Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] = Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - = 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. <= /p>

 

Susan or somebody from i2rs WG can decide whether the = suggested presentation would help clarify i2rs requirements to NETCONF. = >From a personal perspective it would certainly help to have examples of = how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_01D9_01D0B4E9.77DEBC90-- From nobody Thu Jul 2 14:43:19 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 248BF1A8824; Thu, 2 Jul 2015 14:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 zLx1XA06lFnp; Thu, 2 Jul 2015 14:35:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 5323F1A87A8; Thu, 2 Jul 2015 14:35:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" , "'Eric Voit \(evoit\)'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> In-Reply-To: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> Date: Thu, 2 Jul 2015 17:35:04 -0400 Message-ID: <021301d0b50e$f62a20b0$e27e6210$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0214_01D0B4ED.6F1A0750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCCiG/twIuXbN7nP08VQA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 14:43:18 -0700 Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , 'Netconf' Subject: Re: [netmod] [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) 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 Jul 2015 21:35:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0214_01D0B4ED.6F1A0750 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 I=E2=80=99m trying to schedule a set of meeting before I2RS presents at = NETCONF so it would be helpful to know when the I2RS session would be = schedule in NETCONF.=20 =20 Is I2RS requirements presentation at the Tuesday meeting with Netconf = [15:20 =E2=80=93 17:20] which is just before the I2RS meeting [17:40- = 18:40]. This back-to-back session would allow us to encourage people to = hear the presentations in NETCONF and then come to I2RS to discuss any = open issues for I2RS. =20 =20 Do you think we should present the NETMOD requirements before the = NETCONF requirements? I can request a brief presentation in NETMOD. I = am working on a draft to express I2RS requirements for netmod. The = requirements for NETMO will not be an I2RS WG document =E2=80=93 only a = chair=E2=80=99s observations on the differences between the yang = modules.=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani Sent: Thursday, July 02, 2015 5:06 PM To: Eric Voit (evoit) Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; = BRUNGARD, DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS = protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 =20 On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) wrote: =20 What might be interesting for a NETCONF speaking slot is an analysis of = what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. From a = personal perspective it would certainly help to have examples of how the = requirements could be met. =20 Cheers. =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_0214_01D0B4ED.6F1A0750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

I=E2=80=99m trying to schedule a set of meeting before I2RS presents = at NETCONF so it would be helpful to know when the I2RS session would be = schedule in NETCONF.

 

Is I2RS requirements presentation at the Tuesday meeting with Netconf = [15:20 =E2=80=93 17:20] which is just before the I2RS meeting [17:40- = 18:40]. =C2=A0This back-to-back session would allow us to encourage = people to hear the presentations in NETCONF and then come to I2RS to = discuss any open issues for I2RS.=C2=A0

 

Do you think we should present the NETMOD requirements before the = NETCONF requirements? =C2=A0I can request a brief presentation in = NETMOD.=C2=A0 I am working on a draft to express I2RS requirements for = netmod.=C2=A0 The requirements for NETMO will not be an I2RS WG document = =E2=80=93 only a chair=E2=80=99s observations on the differences between = the yang modules.

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Thursday, July 02, 2015 5:06 = PM
To: Eric Voit (evoit)
Cc: = Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; BRUNGARD, = DEBORAH A; Alexander Clemm (alex); Netconf; Susan = Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] = Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - = 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. <= /p>

 

Susan or somebody from i2rs WG can decide whether the = suggested presentation would help clarify i2rs requirements to NETCONF. = >From a personal perspective it would certainly help to have examples of = how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_0214_01D0B4ED.6F1A0750-- From nobody Fri Jul 3 01:06: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 B596A1A8AED for ; Fri, 3 Jul 2015 01:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 QzSzZsD6Mot0 for ; Fri, 3 Jul 2015 01:06:55 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E6F8A1A1A8B for ; Fri, 3 Jul 2015 01:06:54 -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 416ABC4175C1 for ; Fri, 3 Jul 2015 10:06:53 +0200 (CEST) Message-ID: <5596429B.7090608@mg-soft.si> Date: Fri, 03 Jul 2015 10:06:51 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] yang:xpath1.0 values and JSON encoding 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: Fri, 03 Jul 2015 08:06:57 -0000 Hi, since draft-ietf-netmod-yang-json-04 describes a special mapping for instance-identifiers, I'm wondering about how to handle values which are constrained using the standard XML specific yang:xpath1.0 type or a derivative of it. I assume the same or similar rules should apply to any XPath expression that appears in a JSON instance, right? Perhaps this deserves mention in the I-D? Jernej From nobody Fri Jul 3 12:39:32 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 143291A7005; Fri, 3 Jul 2015 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 qd_brI25Worl; Fri, 3 Jul 2015 12:39:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 DAC061A7000; Fri, 3 Jul 2015 12:39:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'BELOTTI, SERGIO \(SERGIO\)'" , "'Mahesh Jethanandani'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: Date: Fri, 3 Jul 2015 15:39:23 -0400 Message-ID: <01c801d0b5c7$f7058d80$e510a880$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C9_01D0B5A6.6FF65E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCOt7Bop0On+6Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Netconf' , 'NETMOD Working Group' Subject: Re: [netmod] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) 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: Fri, 03 Jul 2015 19:39:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C9_01D0B5A6.6FF65E80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sergio:=20 =20 Just in case you missed in the rest of the email threads:=20 =20 Yes =E2=80=93 I2RS plans to coordinate the topology model with the TEAS = Topology model. The work began with the authors last week, and will = continue in a discussion of the TEAS And Topology authors next week = (7/8) in a conference call, and at IETF on Sunday (7/19 from 6-7pm).=20 =20 The I2RS WG will provide an update on the merging of these two models. = If you are a TEAS author, please let me know. If you wish to help on = an I2RS Topology model, the I2RS working group would appreciate your = review of any model.=20 =20 I am personally working on the service layer model.=20 =20 Sue Hares=20 From: BELOTTI, SERGIO (SERGIO) = [mailto:sergio.belotti@alcatel-lucent.com]=20 Sent: Wednesday, July 01, 2015 5:28 AM To: Susan Hares; 'Mahesh Jethanandani' Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'NETMOD Working Group'; = 'Netconf'; 'BRUNGARD, DEBORAH A' Subject: RE: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol = and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 Hello Susan, - Topology model which is a composite of: o Generic topology model: = = draft-ietf-i2rs-yang-network-topo-01=20 o L3 topology model: = = draft-ietf-i2rs-yang-l3-topology-00=20 o L2 topology model: = draft-ietf-i2rs-yang-l2-network-topology-00=20 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 = (released on Wednesday) =20 At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. =20 =20 Reading this , my question is whether there is intention for Traffic = Engineering part of topology model to exploit/coordinate with Teas , and = particularly with=20 draft-liu-teas-yang-te-topo or to proceed with distinct contributions = internal to I2RS. =20 Thanks Sergio =20 ------=_NextPart_000_01C9_01D0B5A6.6FF65E80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sergio:

 

Just in case you missed in the rest of the email threads: =

 

Yes =E2=80=93 I2RS plans to coordinate the topology model with the = TEAS Topology model.=C2=A0 The work began with the authors last week, = and will continue in a discussion of the TEAS And Topology authors next = week (7/8) =C2=A0in a conference call, and at IETF on Sunday (7/19 from = 6-7pm).

 

The I2RS WG will provide an update on the merging of these two = models.=C2=A0 If you are a TEAS author, please let me know. = =C2=A0=C2=A0If you wish to help on an I2RS Topology model, the I2RS = working group would appreciate your review of any model. =

 

I am personally working on the service layer model. =

 

Sue Hares

From:= = BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] =
Sent: Wednesday, July 01, 2015 5:28 AM
To: Susan = Hares; 'Mahesh Jethanandani'
Cc: Rtg-yang-coord@ietf.org; = i2rs@ietf.org; 'NETMOD Working Group'; 'Netconf'; 'BRUNGARD, DEBORAH = A'
Subject: RE: [Rtg-yang-coord] [netmod] Requirements for = I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am = ET)

 

Hello Susan,

-        = ;  Topology model which is a composite = of:=

o   Generic topology model: draft-ietf-i2rs-yang-network-topo-01 =

o   L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 =

o   L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 =

o   L1 Topology model: draft-zhang= -i2rs-l1-topo-yang-model-01 (-02 released later this week). 

o   Service topology model: draft-hares= -i2rs-service-topo-yang-model-00 (released on = Wednesday)

 =

At this = time, none of the Topology models utilize Traffic engineering.  It = is anticipated that these models will support traffic engineering. =  

 

Reading this , my question is whether there is = intention for Traffic Engineering part of topology model to = exploit/coordinate with Teas , and particularly with =

 draft-liu-teas-yang-te-topo or to proceed = with distinct contributions internal to I2RS.

 

Thanks

Sergio

 

------=_NextPart_000_01C9_01D0B5A6.6FF65E80-- From nobody Fri Jul 3 13:45: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 0F95E1A87B0; Fri, 3 Jul 2015 13:45:35 -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 kv5q678g2fsY; Fri, 3 Jul 2015 13:45: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 969C21A87AF; Fri, 3 Jul 2015 13:45:30 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 57E841AE047F; Fri, 3 Jul 2015 22:45:28 +0200 (CEST) Date: Fri, 03 Jul 2015 22:45:27 +0200 (CEST) Message-Id: <20150703.224527.1947263992217736555.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150630124503.GA5406@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: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Fri, 03 Jul 2015 20:45:35 -0000 Andy Bierman wrote: > Hi, > > I am going to update the draft so the conformance leaf > is an enumeration with 'implement' and 'import' enums. > The 'none' enum is not needed because the deviations are > listed inside the module entry. Don't we have to list the deviation module's revision as well? As you noted, the revision is needed in . If we don't list the deviation module in the main list, it won't be possible to download such modules over RESTCONF. > A module server would return > the conformance for the proxied server, not itself. > > No new objects will be added. This is up to the WG to decide. So far, three people (myself included) have said that they want to solve the advertisement problem, "indicate the import tree" as you put it, and the two proposed solutions require new nodes in the module. It would be good to hear from more people. I think your objection to addressing this problem is that if import w/o revision is used, the client by design cannot/should not know which revision the server used. Did I get that right? /martin > Only item # is being addressed. > > Every module the server implements with be listed once > with conformance=implement. Every module and revision > that those modules import (rippled through all imports) will be listed > in the library, with conformance=import, except of > course if the imported module is also an implemented module. > No other modules will be listed. > > > Andy > > > On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman wrote: > > > > > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> Writing as technical contributor... > >> > >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > >> > Hi, > >> > > >> > Here's a short summary, and then some questions for the WG. > >> > > >> > The ietf-yang-library module is designed to serve two purposes: > >> > > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 > >> > modules. > >> > > >> > 2. A list of the YANG modules stored in a server. > >> > > >> > > >> > Q1. Do you agree with these goals? > >> > >> I primarily care about goal 1. > >> > >> > Q2. Should this module be designed to work with both YANG 1.0 and > >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > >> > > >> > If it should not be defined using YANG 1.1, why is this module > >> > special? > >> > >> I assume this module will sooner or later be YANG 1.1 anyway. > >> > >> > Q3. Should the /modules/module list be designed to store both YANG > >> > 1.0 and YANG 1.1 modules? > >> > >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > >> revised all published YANG data models that were written using YANG > >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > >> 1.1 modules. > >> > > > > > > Yes -- We also agreed that we would not be republishing modules > > just to change the yang-version to 1.1. > > > > There are lots of YANG modules in progress at this time. > > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > > It seems rather disruptive to declare all module must be YANG 1.1 > > since it has not even made it through WGLC yat, let alone > > be published as an RFC, let alone be implemented > > in real tool-chains. > > > > I suspect if people find out the only think YANG 1.1 in their module > > (preventing their existing tools from working) is a yang-version-stmt, > > they might not be too happy. > > > > > > Andy > > > > > >> > >> > Q4. Consider these modules, which both import foo without revision: > >> > > >> > module a { ... import foo; ... } > >> > module b { ... import foo; ... } > >> > > >> > Do we require a server that implements both a and b to use the > >> > same revision of foo? > >> > > >> > If the answer is yes, we need to indicate the default revision > >> > that the server uses in the model: > >> > > >> > container modules { > >> > ... > >> > list module { > >> > ... > >> > leaf default-revision { > >> > type boolean; > >> > default false; > >> > description > >> > "Indicates that this revision is used by the server if > >> > this module is imported without a specific revision > >> > date."; > >> > } > >> > } > >> > } > >> > > >> > If the answer is no, note that this puts an implementation burden > >> > on the client. A client cannot simply download all listed > >> > modules, and load/compile/process them as one set. > >> > > >> > If the anwser is no, I propose that we extend the module as such: > >> > > >> > container modules { > >> > ... > >> > list module { > >> > ... > >> > list imported-without-revision { > >> > key "name revision"; > >> > ... > >> > } > >> > } > >> > } > >> > > >> > A server could then list: > >> > > >> > > >> > a > >> > 2015-01-01 > >> > > >> > foo > >> > 2002-02-02 > >> > > >> > > >> > > >> > b > >> > 2015-01-01 > >> > > >> > foo > >> > 2001-01-01 > >> > > >> > > >> > >> I believe truth is advertisement is a good thing. In the SNMP world, > >> not all pieces of the instrumentation were moving at the same pace and > >> I would be somewhat surprised if this would be the case for all > >> implementations in the NETCONF world. Hence, I rather accept that an > >> import of foo without revision may resolve to different versions of > >> foo for different imports. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > From nobody Fri Jul 3 14:12:37 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 D96C31A8833 for ; Fri, 3 Jul 2015 14:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4S89iVn8_Zaq for ; Fri, 3 Jul 2015 14:12:32 -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 C42DC1A882E for ; Fri, 3 Jul 2015 14:12:31 -0700 (PDT) Received: by lagx9 with SMTP id x9so96701681lag.1 for ; Fri, 03 Jul 2015 14:12: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; bh=au5mkzqpOJ2ywsotbopAqIiB5ix+ouKeSgeVswCLs1w=; b=jALrPeaW1QOgMdvcKzvgdAYWeP83+660zhcckGcE9Kilvf9YtEScs5eaZI250tgPJq FEtT4uGuUZAmPk/GxUv9jwX7RxxKJpRzbhcw9CA4/Ce+mZyMEiBQtOp/W8oE5fiyJT/I K+MCYqZOpaLJWhxZMnMG6+MNtfZGzF9S8dI//coLP5O7Yfmqb/hBZV4sTS31NTSoy2Ua KTjbrxA/qY6lmvU0kbC26Yox1V67myzFzdsYzRUQCZlvHRk/o7G0qt29c0aMHGachRiO KVwMWto5uQmBA9YUXStQwi6u+5EBmXJIJkYILwEppnCVrNKx9fPcSIjgsXK/fsRRN5gw qocA== X-Gm-Message-State: ALoCoQk7k9+4IKfXYrPg+xqRah/uI7+VpLeA9faH2N9cDKu02fkiELBAl9lBI2V8T1Ea6jdQSvBr MIME-Version: 1.0 X-Received: by 10.152.43.69 with SMTP id u5mr37340642lal.119.1435957950144; Fri, 03 Jul 2015 14:12:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Jul 2015 14:12:30 -0700 (PDT) In-Reply-To: <20150703.224527.1947263992217736555.mbj@tail-f.com> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> Date: Fri, 3 Jul 2015 14:12:30 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3666087f8860519ff03f1 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Fri, 03 Jul 2015 21:12:36 -0000 --001a11c3666087f8860519ff03f1 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I am going to update the draft so the conformance leaf > > is an enumeration with 'implement' and 'import' enums. > > The 'none' enum is not needed because the deviations are > > listed inside the module entry. > > Don't we have to list the deviation module's revision as well? As you > noted, the revision is needed in . > > If we don't list the deviation module in the main list, it won't be > possible to download such modules over RESTCONF. > > That means that the deviation leaf-list has to be a list to include name and revision. Then there can be a schema leaf in each of those entries. If the deviations module also has other definitions (a bad practice) then it can be present in the 'module' list for 'implements' or 'imports'. This should be rare. > > A module server would return > > the conformance for the proxied server, not itself. > > > > No new objects will be added. > > This is up to the WG to decide. So far, three people (myself > included) have said that they want to solve the advertisement problem, > "indicate the import tree" as you put it, and the two proposed > solutions require new nodes in the module. > > I should say no new objects to this release. The WG can always decide another revision is needed. It would be good to hear from more people. > > I think your objection to addressing this problem is that if import > w/o revision is used, the client by design cannot/should not know > which revision the server used. Did I get that right? > > I propose this text in the conformance leaf: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server."; It seems like a lot of data will be needed to model the dependency tree for every import-stmt in every module. Don't forget every include-stmt as well, since submodules can import with or without revision. IMO "SHOULD use latest" is good enough. Perhaps modules should use import-by-revision when they are published as RFCs (as Lada suggested). As Jeff pointed out, the only time it is safe to use import/include without revision is if you are sure the imported module (or included submodule) is the one and only revision that has, or ever will exist. Even within a single naming organization this might be a bad assumption to make. > /martin > Andy > > > > > Only item # is being addressed. > > > > Every module the server implements with be listed once > > with conformance=implement. Every module and revision > > that those modules import (rippled through all imports) will be listed > > in the library, with conformance=import, except of > > course if the imported module is also an implemented module. > > No other modules will be listed. > > > > > > Andy > > > > > > On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman > wrote: > > > > > > > > > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> Writing as technical contributor... > > >> > > >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > > >> > Hi, > > >> > > > >> > Here's a short summary, and then some questions for the WG. > > >> > > > >> > The ietf-yang-library module is designed to serve two purposes: > > >> > > > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > >> > modules. > > >> > > > >> > 2. A list of the YANG modules stored in a server. > > >> > > > >> > > > >> > Q1. Do you agree with these goals? > > >> > > >> I primarily care about goal 1. > > >> > > >> > Q2. Should this module be designed to work with both YANG 1.0 and > > >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or > not? > > >> > > > >> > If it should not be defined using YANG 1.1, why is this module > > >> > special? > > >> > > >> I assume this module will sooner or later be YANG 1.1 anyway. > > >> > > >> > Q3. Should the /modules/module list be designed to store both YANG > > >> > 1.0 and YANG 1.1 modules? > > >> > > >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > > >> revised all published YANG data models that were written using YANG > > >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > > >> 1.1 modules. > > >> > > > > > > > > > Yes -- We also agreed that we would not be republishing modules > > > just to change the yang-version to 1.1. > > > > > > There are lots of YANG modules in progress at this time. > > > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > > > It seems rather disruptive to declare all module must be YANG 1.1 > > > since it has not even made it through WGLC yat, let alone > > > be published as an RFC, let alone be implemented > > > in real tool-chains. > > > > > > I suspect if people find out the only think YANG 1.1 in their module > > > (preventing their existing tools from working) is a yang-version-stmt, > > > they might not be too happy. > > > > > > > > > Andy > > > > > > > > >> > > >> > Q4. Consider these modules, which both import foo without revision: > > >> > > > >> > module a { ... import foo; ... } > > >> > module b { ... import foo; ... } > > >> > > > >> > Do we require a server that implements both a and b to use the > > >> > same revision of foo? > > >> > > > >> > If the answer is yes, we need to indicate the default revision > > >> > that the server uses in the model: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > leaf default-revision { > > >> > type boolean; > > >> > default false; > > >> > description > > >> > "Indicates that this revision is used by the server > if > > >> > this module is imported without a specific revision > > >> > date."; > > >> > } > > >> > } > > >> > } > > >> > > > >> > If the answer is no, note that this puts an implementation > burden > > >> > on the client. A client cannot simply download all listed > > >> > modules, and load/compile/process them as one set. > > >> > > > >> > If the anwser is no, I propose that we extend the module as > such: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > list imported-without-revision { > > >> > key "name revision"; > > >> > ... > > >> > } > > >> > } > > >> > } > > >> > > > >> > A server could then list: > > >> > > > >> > > > >> > a > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2002-02-02 > > >> > > > >> > > > >> > > > >> > b > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2001-01-01 > > >> > > > >> > > > >> > > >> I believe truth is advertisement is a good thing. In the SNMP world, > > >> not all pieces of the instrumentation were moving at the same pace and > > >> I would be somewhat surprised if this would be the case for all > > >> implementations in the NETCONF world. Hence, I rather accept that an > > >> import of foo without revision may resolve to different versions of > > >> foo for different imports. > > >> > > >> /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 > > >> > > > > > > > --001a11c3666087f8860519ff03f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I am going to update the draft so the conformance leaf
> is an enumeration with 'implement' and 'import' enums.=
> The 'none' enum is not needed because the deviations are
> listed inside the module entry.

Don't we have to list the deviation module's revision as well?=C2= =A0 As you
noted, the revision is needed in <get-schema>.

If we don't list the deviation module in the main list, it won't be=
possible to download such modules over RESTCONF.


That means that the deviation leaf-lis= t has to be a list
to include name and revision.=C2=A0 Then there= can be a schema leaf
in each of those entries.

If the deviations module also has other definitions
(a ba= d practice) then it can be present in the 'module' list
f= or 'implements' or 'imports'.=C2=A0 This should be rare.

=C2=A0
> A module server would return
> the conformance for the proxied server, not itself.
>
> No new objects will be added.

This is up to the WG to decide.=C2=A0 So far, three people (myself
included) have said that they want to solve the advertisement problem,
"indicate the import tree" as you put it, and the two proposed solutions require new nodes in the module.


I should say no new objects to this re= lease.
The WG can always decide another revision is needed.
=


It would be good to hear from more people.

I think your objection to addressing this problem is that if import
w/o revision is used, the client by design cannot/should not know
which revision the server used.=C2=A0 Did I get that right?


I propose this text in the conformance= leaf:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0For import statements that do not specify a revision
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0date, the most = recent revision in the library SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0be used by the server.";
<= br>
It seems like a lot of data will be needed to model the depen= dency tree
for every import-stmt in every module.=C2=A0 Don't= forget every include-stmt
as well, since submodules can import w= ith or without revision.

IMO "SHOULD use late= st" is good enough.
Perhaps modules should use import-by-rev= ision when they
are published as RFCs (as Lada suggested).
<= div>
As Jeff pointed out, the only time it is safe to use
import/include without revision is if you are sure the imported
module (or included submodule) is the one and only
revision= that has, or ever will exist.

Even within a singl= e naming organization this might be
a bad assumption to make.




/martin

Andy
=C2=A0



> Only item # is being addressed.
>
> Every module the server implements with be listed once
> with conformance=3Dimplement.=C2=A0 Every module and revision
> that those modules import (rippled through all imports) will be listed=
> in the library, with conformance=3Dimport, except of
> course if the imported module is also an implemented module.
> No other modules will be listed.
>
>
> Andy
>
>
> On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <
> > j.schoenw= aelder@jacobs-university.de> wrote:
> >
> >> Writing as technical contributor...
> >>
> >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wr= ote:
> >> > Hi,
> >> >
> >> > Here's a short summary, and then some questions for = the WG.
> >> >
> >> > The ietf-yang-library module is designed to serve two pu= rposes:
> >> >
> >> >=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisemen= t mechanism for YANG 1.1
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
> >> >
> >> >=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored i= n a server.
> >> >
> >> >
> >> > Q1.=C2=A0 Do you agree with these goals?
> >>
> >> I primarily care about goal 1.
> >>
> >> > Q2.=C2=A0 Should this module be designed to work with bo= th YANG 1.0 and
> >> >=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it h= ave yang-version 1.1 or not?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YA= NG 1.1, why is this module
> >> >=C2=A0 =C2=A0 =C2=A0 special?
> >>
> >> I assume this module will sooner or later be YANG 1.1 anyway.=
> >>
> >> > Q3.=C2=A0 Should the /modules/module list be designed to= store both YANG
> >> >=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?
> >>
> >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not h= ave
> >> revised all published YANG data models that were written usin= g YANG
> >> 1.0. So a server needs to be able to announce both YANG 1.0 a= nd YANG
> >> 1.1 modules.
> >>
> >
> >
> > Yes -- We also agreed that we would not be republishing modules > > just to change the yang-version to 1.1.
> >
> > There are lots of YANG modules in progress at this time.
> > Perhaps 3 out of 100 are relying on YANG 1.1 statements.
> > It seems rather disruptive to declare all module must be YANG 1.1=
> > since it has not even made it through WGLC yat, let alone
> > be published as an RFC, let alone be implemented
> > in real tool-chains.
> >
> > I suspect if people find out the only think YANG 1.1 in their mod= ule
> > (preventing their existing tools from working) is a yang-version-= stmt,
> > they might not be too happy.
> >
> >
> > Andy
> >
> >
> >>
> >> > Q4.=C2=A0 Consider these modules, which both import foo = without revision:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ..= . }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ..= . }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 Do we require a server that implemen= ts both a and b to use the
> >> >=C2=A0 =C2=A0 =C2=A0 same revision of foo?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to ind= icate the default revision
> >> >=C2=A0 =C2=A0 =C2=A0 that the server uses in the model: > >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-re= vision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boo= lean;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default = false;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descript= ion
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;Indicates that this revision is used by the server if
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0this module is imported without a specific revision
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date.";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this = puts an implementation burden
> >> >=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot= simply download all listed
> >> >=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process th= em as one set.
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that = we extend the module as such:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-w= ithout-revision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key &quo= t;name revision";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 A server could then list:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2002-02-02</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2001-01-01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >>
> >> I believe truth is advertisement is a good thing. In the SNMP= world,
> >> not all pieces of the instrumentation were moving at the same= pace and
> >> I would be somewhat surprised if this would be the case for a= ll
> >> implementations in the NETCONF world. Hence, I rather accept = that an
> >> import of foo without revision may resolve to different versi= ons of
> >> foo for different imports.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= mod
> >>
> >
> >

--001a11c3666087f8860519ff03f1-- From nobody Fri Jul 3 14:16:50 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 33A5A1A8845 for ; Fri, 3 Jul 2015 14:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Qu31HnANq1qS for ; Fri, 3 Jul 2015 14:16:46 -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 930C11A883E for ; Fri, 3 Jul 2015 14:16:45 -0700 (PDT) Received: by lagc2 with SMTP id c2so96837602lag.3 for ; Fri, 03 Jul 2015 14:16: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=koGJ4TlZ312Xa1O4H7ez/eZXA06WN3gZYPOHpEzxYHI=; b=WCMqPzj0mguOUjOFM7MnOK0bBSdfEjCJFBVF97xfLIq9Edg0xeLbLaPQOQuu86FNoJ 8FhRl4kf6mC1/CfupnZZQ95q2aza44ME365lS53qrKb5gb0UubxcGKbiEWF52LK+a+yS qIMXzExzTvSTihe7LcCSYxyoS6qnBZb7OjZlvjQrN47qPcne+xHR73vBFC/EgvCHE9oy XyaX9NbHfT4KQPRDkwexNTTS6cVcVmKc2RjFos+4eB6IkEfNINwgMsVkCRfj03cqBw0T rxX9+Hysmtu85m99H+j/S/6kTv/i6rGPdjMaJx4jnpiMe3FXwc0YQyqWKK4wbHKdD4wN APiQ== X-Gm-Message-State: ALoCoQnekx2OtufaFD9Ss4d3V7YmNIvI69VLgzLnzifR+CmUgp9ds8Wwu51uzlheWHLRMyDIw++F MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr37367683lab.82.1435958203933; Fri, 03 Jul 2015 14:16:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Jul 2015 14:16:43 -0700 (PDT) In-Reply-To: <20150703.224527.1947263992217736555.mbj@tail-f.com> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> Date: Fri, 3 Jul 2015 14:16:43 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3677ea87cb10519ff124e Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Fri, 03 Jul 2015 21:16:49 -0000 --001a11c3677ea87cb10519ff124e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I am going to update the draft so the conformance leaf > > is an enumeration with 'implement' and 'import' enums. > > The 'none' enum is not needed because the deviations are > > listed inside the module entry. > > Don't we have to list the deviation module's revision as well? As you > noted, the revision is needed in . > > If we don't list the deviation module in the main list, it won't be > possible to download such modules over RESTCONF. > > I will add 'none' to the enumeration for deviations It would be bad if any file was listed for download more than once Andy > > A module server would return > > the conformance for the proxied server, not itself. > > > > No new objects will be added. > > This is up to the WG to decide. So far, three people (myself > included) have said that they want to solve the advertisement problem, > "indicate the import tree" as you put it, and the two proposed > solutions require new nodes in the module. > > It would be good to hear from more people. > > I think your objection to addressing this problem is that if import > w/o revision is used, the client by design cannot/should not know > which revision the server used. Did I get that right? > > > /martin > > > > > Only item # is being addressed. > > > > Every module the server implements with be listed once > > with conformance=implement. Every module and revision > > that those modules import (rippled through all imports) will be listed > > in the library, with conformance=import, except of > > course if the imported module is also an implemented module. > > No other modules will be listed. > > > > > > Andy > > > > > > On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman > wrote: > > > > > > > > > > > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> Writing as technical contributor... > > >> > > >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > > >> > Hi, > > >> > > > >> > Here's a short summary, and then some questions for the WG. > > >> > > > >> > The ietf-yang-library module is designed to serve two purposes: > > >> > > > >> > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > >> > modules. > > >> > > > >> > 2. A list of the YANG modules stored in a server. > > >> > > > >> > > > >> > Q1. Do you agree with these goals? > > >> > > >> I primarily care about goal 1. > > >> > > >> > Q2. Should this module be designed to work with both YANG 1.0 and > > >> > YANG 1.1 servers - i.e., should it have yang-version 1.1 or > not? > > >> > > > >> > If it should not be defined using YANG 1.1, why is this module > > >> > special? > > >> > > >> I assume this module will sooner or later be YANG 1.1 anyway. > > >> > > >> > Q3. Should the /modules/module list be designed to store both YANG > > >> > 1.0 and YANG 1.1 modules? > > >> > > >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > > >> revised all published YANG data models that were written using YANG > > >> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > > >> 1.1 modules. > > >> > > > > > > > > > Yes -- We also agreed that we would not be republishing modules > > > just to change the yang-version to 1.1. > > > > > > There are lots of YANG modules in progress at this time. > > > Perhaps 3 out of 100 are relying on YANG 1.1 statements. > > > It seems rather disruptive to declare all module must be YANG 1.1 > > > since it has not even made it through WGLC yat, let alone > > > be published as an RFC, let alone be implemented > > > in real tool-chains. > > > > > > I suspect if people find out the only think YANG 1.1 in their module > > > (preventing their existing tools from working) is a yang-version-stmt, > > > they might not be too happy. > > > > > > > > > Andy > > > > > > > > >> > > >> > Q4. Consider these modules, which both import foo without revision: > > >> > > > >> > module a { ... import foo; ... } > > >> > module b { ... import foo; ... } > > >> > > > >> > Do we require a server that implements both a and b to use the > > >> > same revision of foo? > > >> > > > >> > If the answer is yes, we need to indicate the default revision > > >> > that the server uses in the model: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > leaf default-revision { > > >> > type boolean; > > >> > default false; > > >> > description > > >> > "Indicates that this revision is used by the server > if > > >> > this module is imported without a specific revision > > >> > date."; > > >> > } > > >> > } > > >> > } > > >> > > > >> > If the answer is no, note that this puts an implementation > burden > > >> > on the client. A client cannot simply download all listed > > >> > modules, and load/compile/process them as one set. > > >> > > > >> > If the anwser is no, I propose that we extend the module as > such: > > >> > > > >> > container modules { > > >> > ... > > >> > list module { > > >> > ... > > >> > list imported-without-revision { > > >> > key "name revision"; > > >> > ... > > >> > } > > >> > } > > >> > } > > >> > > > >> > A server could then list: > > >> > > > >> > > > >> > a > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2002-02-02 > > >> > > > >> > > > >> > > > >> > b > > >> > 2015-01-01 > > >> > > > >> > foo > > >> > 2001-01-01 > > >> > > > >> > > > >> > > >> I believe truth is advertisement is a good thing. In the SNMP world, > > >> not all pieces of the instrumentation were moving at the same pace and > > >> I would be somewhat surprised if this would be the case for all > > >> implementations in the NETCONF world. Hence, I rather accept that an > > >> import of foo without revision may resolve to different versions of > > >> foo for different imports. > > >> > > >> /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 > > >> > > > > > > > --001a11c3677ea87cb10519ff124e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I am going to update the draft so the conformance leaf
> is an enumeration with 'implement' and 'import' enums.=
> The 'none' enum is not needed because the deviations are
> listed inside the module entry.

Don't we have to list the deviation module's revision as well?=C2= =A0 As you
noted, the revision is needed in <get-schema>.

If we don't list the deviation module in the main list, it won't be=
possible to download such modules over RESTCONF.



I will add 'none= 9; to the enumeration for deviations
It would be bad if any file = was listed for download more than once


<= div>Andy
=C2=A0
> A module server would return
> the conformance for the proxied server, not itself.
>
> No new objects will be added.

This is up to the WG to decide.=C2=A0 So far, three people (myself
included) have said that they want to solve the advertisement problem,
"indicate the import tree" as you put it, and the two proposed solutions require new nodes in the module.

It would be good to hear from more people.

I think your objection to addressing this problem is that if import
w/o revision is used, the client by design cannot/should not know
which revision the server used.=C2=A0 Did I get that right?


/martin



> Only item # is being addressed.
>
> Every module the server implements with be listed once
> with conformance=3Dimplement.=C2=A0 Every module and revision
> that those modules import (rippled through all imports) will be listed=
> in the library, with conformance=3Dimport, except of
> course if the imported module is also an implemented module.
> No other modules will be listed.
>
>
> Andy
>
>
> On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> > On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <
> > j.schoenw= aelder@jacobs-university.de> wrote:
> >
> >> Writing as technical contributor...
> >>
> >> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wr= ote:
> >> > Hi,
> >> >
> >> > Here's a short summary, and then some questions for = the WG.
> >> >
> >> > The ietf-yang-library module is designed to serve two pu= rposes:
> >> >
> >> >=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisemen= t mechanism for YANG 1.1
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
> >> >
> >> >=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored i= n a server.
> >> >
> >> >
> >> > Q1.=C2=A0 Do you agree with these goals?
> >>
> >> I primarily care about goal 1.
> >>
> >> > Q2.=C2=A0 Should this module be designed to work with bo= th YANG 1.0 and
> >> >=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it h= ave yang-version 1.1 or not?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YA= NG 1.1, why is this module
> >> >=C2=A0 =C2=A0 =C2=A0 special?
> >>
> >> I assume this module will sooner or later be YANG 1.1 anyway.=
> >>
> >> > Q3.=C2=A0 Should the /modules/module list be designed to= store both YANG
> >> >=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?
> >>
> >> Yes. Even if YANG 1.1 hits the street tomorrow, we will not h= ave
> >> revised all published YANG data models that were written usin= g YANG
> >> 1.0. So a server needs to be able to announce both YANG 1.0 a= nd YANG
> >> 1.1 modules.
> >>
> >
> >
> > Yes -- We also agreed that we would not be republishing modules > > just to change the yang-version to 1.1.
> >
> > There are lots of YANG modules in progress at this time.
> > Perhaps 3 out of 100 are relying on YANG 1.1 statements.
> > It seems rather disruptive to declare all module must be YANG 1.1=
> > since it has not even made it through WGLC yat, let alone
> > be published as an RFC, let alone be implemented
> > in real tool-chains.
> >
> > I suspect if people find out the only think YANG 1.1 in their mod= ule
> > (preventing their existing tools from working) is a yang-version-= stmt,
> > they might not be too happy.
> >
> >
> > Andy
> >
> >
> >>
> >> > Q4.=C2=A0 Consider these modules, which both import foo = without revision:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ..= . }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ..= . }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 Do we require a server that implemen= ts both a and b to use the
> >> >=C2=A0 =C2=A0 =C2=A0 same revision of foo?
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to ind= icate the default revision
> >> >=C2=A0 =C2=A0 =C2=A0 that the server uses in the model: > >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-re= vision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boo= lean;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default = false;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descript= ion
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;Indicates that this revision is used by the server if
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0this module is imported without a specific revision
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date.";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this = puts an implementation burden
> >> >=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot= simply download all listed
> >> >=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process th= em as one set.
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that = we extend the module as such:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-w= ithout-revision {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key &quo= t;name revision";
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 A server could then list:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2002-02-02</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name&= gt;
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01= -01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-re= vision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo&= lt;/name>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>= 2001-01-01</revision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-r= evision>
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >>
> >> I believe truth is advertisement is a good thing. In the SNMP= world,
> >> not all pieces of the instrumentation were moving at the same= pace and
> >> I would be somewhat surprised if this would be the case for a= ll
> >> implementations in the NETCONF world. Hence, I rather accept = that an
> >> import of foo without revision may resolve to different versi= ons of
> >> foo for different imports.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= mod
> >>
> >
> >

--001a11c3677ea87cb10519ff124e-- From nobody Fri Jul 3 23:32:11 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 D56BF1A8826 for ; Fri, 3 Jul 2015 23:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 w_X0E0TffHKn for ; Fri, 3 Jul 2015 23:32:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80091A87DB for ; Fri, 3 Jul 2015 23:32:06 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:2c91:95bd:c41a:3e43] (unknown [IPv6:2a01:5e0:29:ffff:2c91:95bd:c41a:3e43]) by mail.nic.cz (Postfix) with ESMTPSA id 4B83A180F3E; Sat, 4 Jul 2015 08:32:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1435991525; bh=IuKNLQ8qQbxIGXChEgEwjERH3tVESkYLItVO6yTYn9s=; h=From:Date:To; b=g7L14aHmOYBr4eoZmNbVQmrfhLnj+YjRgWU/572cawYhN0G/h/xIuDYtNIWLx59FI XonUEW3G8ChwuhGYFCqnFxOssTJcFw0aQYNQHahjQ4OTVC+2R/BsfmVU8KMdYMB9zY mekGPgxsYbwnMP5K631tHuWZaQvFM5CrDILX8K2Y= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 4 Jul 2015 08:32:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150630095600.GA4836@elstar.local> <20150630132059.GC5406@elstar.local> <90672C21-8E4C-4B9B-81DD-BBCB5F529D20@nic.cz> <20150630133908.GC5604@elstar.local> <969A179E-2EB4-4E08-A55F-A4A8B0B0C0A1@nic.cz> <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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: Sat, 04 Jul 2015 06:32:10 -0000 > On 02 Jul 2015, at 22:08, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jul 1, 2015 at 11:33 PM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > I agree with Juergen that the implementation of YANG constraints > > on a datastore is not XML-specific. The text refers to data nodes > > not XML elements. It is quite possible for a server to populate = data >=20 > The text says in sec. 6.4: "The data model used in the XPath = expressions > is the same as that used in XPath 1.0 [XPATH], =E2=80=A6", and the = data model in > [XPATH] is about elements, attributes, namespaces etc. In order to > correctly interpret [XPATH], one needs to map (conceptually, if you > wish) the data tree onto the XPath data model. >=20 > > nodes in a datastore without NETCONF of XML being involved. >=20 > And what about RPCs and notifications? In this case the accessible = data > tree is defined as the corresponding XML instance document. >=20 >=20 >=20 > There is no possibility for data to be converted between > XML and JSON if this is the case. I don=E2=80=99t know why, and it=E2=80=99s not about converting. Are you = saying JSON encoding of RPC operations is ill-defined? =20 >=20 > =20 > Consider this definition: >=20 > rpc foo { > input { > leaf x { > type uint8; > must ". =3D ../y"; > } > leaf y { > type string; > } > } > } >=20 > Then what's the result of conceptual XPath evaluation for this RPC > request? >=20 >=20 >=20 > Just because you can construct a pathological > case comparing strings and numbers doesn't > mean anything. Pathological?? Don=E2=80=99t forget that uint64 numbers are encoded as = strings in JSON. Moreover, comparisons of two nodesets are *always* = performed on string values, even if both have numeric types in YANG. >=20 > Use "number(foo) < number(bar)" to ensure that > numeric comparisons are done correctly. >=20 That=E2=80=99s not the point. The above XPath expression is perfectly = valid so its result should be deterministic and identical to = "non-conceptual=E2=80=9D XPath evaluation.=20 Saying that all gaps in the spec are pathological examples is an = extremely slippery slope. >=20 >=20 > > > +1 > 1 > > >=20 > And how about this RPC input in JSON? >=20 > { > "foorpc:input": { > "x": +1, > "y": "1" > } > } >=20 > > > > We keep getting stuck on the difference between resource = representations > > on the wire, and implementation details within a client or server. >=20 > This is not my problem here. >=20 >=20 >=20 > There are lots of XPath expressions that can be constructed > that create problems because of the way XPath converts > types by default. That is why there are functions number(), string(), = etc. Funny enough, 6087bis says: The 'local-name', 'namespace-uri', 'name', 'string', and 'number' functions SHOULD NOT be used if the argument is a node-set. Lada >=20 >=20 > =20 > Lada >=20 > Andy > =20 >=20 > > There is no requirement that they be the same "XML or JSON". > > inside. > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Jul 4 01:09:55 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 4532B1A8A89 for ; Sat, 4 Jul 2015 01:09: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 iHlMd891wePG for ; Sat, 4 Jul 2015 01:09: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 DD6831A8A81 for ; Sat, 4 Jul 2015 01:09:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 29ADD10DB; Sat, 4 Jul 2015 10:09: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 laD_3RMFOPka; Sat, 4 Jul 2015 10:09:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 4 Jul 2015 10:09:45 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 255772002B; Sat, 4 Jul 2015 10:09:49 +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 Y1Nt5vgOOzOG; Sat, 4 Jul 2015 10:10: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 0312620013; Sat, 4 Jul 2015 10:09:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E18D34ED7AB; Sat, 4 Jul 2015 10:09:46 +0200 (CEST) Date: Sat, 4 Jul 2015 10:09:45 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150704080945.GA2182@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> <70B4070E-B655-4864-A4F6-FD79FD49577C@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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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: Sat, 04 Jul 2015 08:09:54 -0000 On Sat, Jul 04, 2015 at 08:32:04AM +0200, Ladislav Lhotka wrote: > > > > > Consider this definition: > > > > rpc foo { > > input { > > leaf x { > > type uint8; > > must ". = ../y"; > > } > > leaf y { > > type string; > > } > > } > > } > > > > Then what's the result of conceptual XPath evaluation for this RPC > > request? > > > > Just because you can construct a pathological > > case comparing strings and numbers doesn't > > mean anything. > > Pathological?? Don’t forget that uint64 numbers are encoded as strings in JSON. Moreover, comparisons of two nodesets are *always* performed on string values, even if both have numeric types in YANG. > > > > > Use "number(foo) < number(bar)" to ensure that > > numeric comparisons are done correctly. > > If this +1 != "1" needs fixing, I think it needs fixing in the YANG specification. For datastores, things are kind of handled since RFC 6020 says: Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Sections 7.6 and 7.7), any XPath comparisons are done on the canonical value. For notifications, this is kind of handled as well: When a NETCONF server sends data, it MUST be in the canonical form. And of course, we expect the server to only send notifcations that are valid anyway. For RPCs, the obvious things to do would be to require that XPATH evaluation of RPC arguments also takes place on the canonical representation of values. /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 Sat Jul 4 02:24:29 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 6A24D1ACD27 for ; Sat, 4 Jul 2015 02:24: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 eYev-nnuFvta for ; Sat, 4 Jul 2015 02:24:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A55B1ACD11 for ; Sat, 4 Jul 2015 02:24:27 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 508281AE046E; Sat, 4 Jul 2015 11:24:26 +0200 (CEST) Date: Sat, 04 Jul 2015 11:24:26 +0200 (CEST) Message-Id: <20150704.112426.1126186353777471582.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <67D6D0D5-B1E2-4CF8-ADFC-A02C6BF808ED@nic.cz> References: <4A6BBA96-3A42-4E17-A4D0-EF8DFCD22BE7@nic.cz> <67D6D0D5-B1E2-4CF8-ADFC-A02C6BF808ED@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] IANA Consideration 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: Sat, 04 Jul 2015 09:24:28 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMzAgSnVu IDIwMTUsIGF0IDE2OjExLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90 ZToNCj4gPiANCj4gPiBIaSBMYWRhLCANCj4gPiANCj4gPiBPbiA2LzMwLzE1LCA0OjUyIEFNLCAi TGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4gDQo+ID4+IEhpLA0K PiA+PiANCj4gPj4gaXMgaXQgT0sgdGhhdCA2MDIwYmlzIGFnYWluIGRlZmluZXMg4oCcWUFORyBN b2R1bGUgTmFtZXPigJ0gcmVnaXN0cnk/IEl0IHdhcw0KPiA+PiBhbHJlYWR5IGRlZmluZWQgaW4g UkZDIDYwMjAgc28gSeKAmWQgc2F5IGl0IHNob3VsZG7igJl0IGJlIHJlcGVhdGVkLg0KPiA+IA0K PiA+IE5vcm1hbGx5IHdoZW4gYW4gUkZDIGlzIG9ic29sZXRlZCBieSBhIGJpcyB2ZXJzaW9uLCB0 aGUgb3JpZ2luYWwgSUFOQQ0KPiA+IGNvbnNpZGVyYXRpb25zIGFyZSByZXRhaW5lZC4gQXQgbGVh c3QgdGhhdCBoYXMgYmVlbiBteSBleHBlcmllbmNlIGJvdGggZm9yDQo+ID4gYmlzIHZlcnNpb25z IHRoYXQgSSBoYXZlIGF1dGhvcmVkIGFuZCBiaXMgdmVyc2lvbiB0aGF0IEkgaGF2ZSByZXZpZXdl ZC4NCg0KWWVzLiAgSG93ZXZlciwgbm90ZSB0aGUgb3BlbiBpc3N1ZSBZNjA6DQoNCmh0dHA6Ly9z dm4udG9vbHMuaWV0Zi5vcmcvc3ZuL3dnL25ldG1vZC95YW5nLTEuMS9pc3N1ZXMuaHRtbCNzZWMt NjENCg0KDQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiBPSywgdGhhbmtzLiBMYWRhDQo+IA0KPiA+IA0K PiA+IFRoYW5rcywNCj4gPiBBY2VlIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+PiANCj4gPj4gQWxz bywgdGhlIHR3byByZWdpc3RlcmVkIG5hbWVzcGFjZSBVUklzIHNob3VsZCBJTU8gYmUNCj4gPj4g DQo+ID4+ICAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOnlpbjoxLjENCj4gPj4g ICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6MS4xDQo+ID4+IA0KPiA+PiBMYWRh DQo+ID4+IA0KPiA+PiAtLQ0KPiA+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+ID4+ IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBuZXRt b2QgbWFpbGluZyBsaXN0DQo+ID4+IG5ldG1vZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+IA0KPiANCj4gLS0NCj4gTGFkaXNs YXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiANCj4gDQo+ IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Sun Jul 5 21:07:11 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 EF0791A1EFF for ; Sun, 5 Jul 2015 21:07: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 dQV_SYVpzHzt for ; Sun, 5 Jul 2015 21:07:05 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0541B1A1EB7 for ; Sun, 5 Jul 2015 21:07:01 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06B7qwUd35lVU3hJCg==.54766S2; Mon, 06 Jul 2015 09:51:40 +0800 (CST) From: "Aijun Wang" To: References: In-Reply-To: Date: Mon, 6 Jul 2015 12:06:40 +0800 Message-ID: <00de01d0b7a1$323339e0$9699ada0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC1aS5+MGhNFaRnRB+3N3QiaZsrPgCNPyowAAC8jdA= Content-Language: zh-cn X-CM-TRANSID: Z0GX06B7qwUd35lVU3hJCg==.54766S2 X-Coremail-Antispam: 1U3129KBjvJXoW7WFWrur4DKr18KryDXF4Utwb_yoW8AFyxpa 4UWrW5KF1Fqa4Ska48Xr4DZF4rXa93K393ZFsrGr10va13X3Wjq3y0kF4rZFyjqFyrGrWq qF47Zr15Z395XrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjllb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUJVWUXwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY 1x0267AKxVWUJVW8JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4U0xZFpf9x0JUd8nOUUUUU= Archived-At: Subject: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.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: Mon, 06 Jul 2015 04:07:10 -0000 Hi, all: We submitted one new draft = (https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00) that = described one general model for the tunnel services used within service = provider network. It summaries the common characteristic of the current = various tunnel protocols and can be used as one fundamental model for = the specific tunnel technology.=20 Any feedback is welcome. Best Regard. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, July 03, 2015 4:21 PM To: Zitao Wang; Yan Zhuang; Aijun Wang; Zhuangyan; Zitao Wang; Aijun = Wang Subject: New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt A new version of I-D, draft-wwz-netmod-yang-tunnel-cfg-00.txt has been successfully submitted by Zitao Wang and posted to the IETF = repository. Name: draft-wwz-netmod-yang-tunnel-cfg Revision: 00 Title: YANG Data Model for Tunnel Management Document date: 2015-07-03 Group: Individual Submission Pages: 21 URL: = https://www.ietf.org/internet-drafts/draft-wwz-netmod-yang-tunnel-cfg-00.= txt Status: = https://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/ Htmlized: = https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00 Abstract: This document defines a YANG data model for the configuration and management of generic tunnels. The data model includes configuration data and state data. And it can serve as a base model which is augmented with technology-specific details in other, more specific tunnel models. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Sun Jul 5 23:58:08 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 D7A331A011E; Sun, 5 Jul 2015 23:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 VDn9YeSI4HOp; Sun, 5 Jul 2015 23:58: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 B45181A0113; Sun, 5 Jul 2015 23:58:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D85B0727; Mon, 6 Jul 2015 08:58: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 4fObVwtZgnum; Mon, 6 Jul 2015 08:57: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; Mon, 6 Jul 2015 08:58:01 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C23B2002B; Mon, 6 Jul 2015 08:58:01 +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 z_R7M233y5W4; Mon, 6 Jul 2015 08:58: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 3A5E520013; Mon, 6 Jul 2015 08:58:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2AFA334EE212; Mon, 6 Jul 2015 08:57:55 +0200 (CEST) Date: Mon, 6 Jul 2015 08:57:55 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150706065755.GA6056@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Mon, 06 Jul 2015 06:58:06 -0000 On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > I propose this text in the conformance leaf: > > For import statements that do not specify a revision > date, the most recent revision in the library SHOULD > be used by the server."; > > It seems like a lot of data will be needed to model the dependency tree > for every import-stmt in every module. Don't forget every include-stmt > as well, since submodules can import with or without revision. > > IMO "SHOULD use latest" is good enough. > Perhaps modules should use import-by-revision when they > are published as RFCs (as Lada suggested). This sounds like "lets pretend the world is simple so we have less work to do". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 6 00:39:26 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 E0D6C1A8F3E for ; Mon, 6 Jul 2015 00:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Zcpxu1l5D-ub for ; Mon, 6 Jul 2015 00:39:23 -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 E42FD1A8BC3 for ; Mon, 6 Jul 2015 00:39:22 -0700 (PDT) Received: by lagx9 with SMTP id x9so143809643lag.1 for ; Mon, 06 Jul 2015 00:39:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5Jwodf+4y+Yhwvpv5gdr7fjKazycXICkHith4S5E26o=; b=NS+lWUGZN/zmq3PZ+DQROsGzRaRAkNcCIIcHw642ZpZJc9fKcXH+IyhVAo19JIAqwL okAPWjjxYYiSdjG9I4Rr7/MJukWFbVcqqi92peu3oH20yk2EfTZRNPEMPirSZ2rcA5uA E2yU8oJORD8/atEDlukXmRTzoqQWorEkFfd4EZXt2wNFRlXfUKnTrnBtY/Z45SelTSRY 1t1YUYdzj/+omPzIDr2dN8nhOtqbltE2u+Ysx5qzMDDt869Mai+2afBAEDwKcZew4jFV WQlsPqm3ZKUc23wSL0AF81VI7Kg2VPvH841pXlwhOWyxCSRLjNivXwDuWXzCPyJvwkdd gxlQ== X-Gm-Message-State: ALoCoQka20aQ+MIE7zJLM3bnBL723VPCQL325NZH2Np3bh7tOtHNbB7PFA47v+I7Ukzp74PVdbaB MIME-Version: 1.0 X-Received: by 10.152.121.99 with SMTP id lj3mr46489323lab.37.1436168361418; Mon, 06 Jul 2015 00:39:21 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 00:39:21 -0700 (PDT) In-Reply-To: <20150706065755.GA6056@elstar.local> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> Date: Mon, 6 Jul 2015 00:39:21 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e0115e882053d22051a30011d Archived-At: Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Mon, 06 Jul 2015 07:39:25 -0000 --089e0115e882053d22051a30011d Content-Type: text/plain; charset=UTF-8 On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > I propose this text in the conformance leaf: > > > > For import statements that do not specify a revision > > date, the most recent revision in the library SHOULD > > be used by the server."; > > > > It seems like a lot of data will be needed to model the dependency tree > > for every import-stmt in every module. Don't forget every include-stmt > > as well, since submodules can import with or without revision. > > > > IMO "SHOULD use latest" is good enough. > > Perhaps modules should use import-by-revision when they > > are published as RFCs (as Lada suggested). > > This sounds like "lets pretend the world is simple so we have less > work to do". > > No -- YANG currently says if there is no revision date then the implementation can use any revision, This is also good enough. Prove that this is causing interoperability problems. I don't think it is -- especially not such that the server has to model all its imports so the client can retrieve the data. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e0115e882053d22051a30011d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierm= an wrote:

> I propose this text in the conformance leaf:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For import stat= ements that do not specify a revision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 date, the most = recent revision in the library SHOULD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used by the = server.";
>
> It seems like a lot of data will be needed to model the dependency tre= e
> for every import-stmt in every module.=C2=A0 Don't forget every in= clude-stmt
> as well, since submodules can import with or without revision.
>
> IMO "SHOULD use latest" is good enough.
> Perhaps modules should use import-by-revision when they
> are published as RFCs (as Lada suggested).

This sounds like "lets pretend the world is simple so we have less
work to do".


No -- YANG currently says if there is no revision da= te
then the implementation can use any revision,
This i= s also good enough.=C2=A0 Prove that this is causing interoperability
=
problems.=C2=A0 I don't think it is -- especially not such that th= e server
has to model all its imports so the client can retrieve = the data.

=C2=A0
/js

Andy
=C2=A0=

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

--089e0115e882053d22051a30011d-- From nobody Mon Jul 6 00:46:11 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 D807F1A8F3F; Mon, 6 Jul 2015 00:46:07 -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 Skt97PXS6eik; Mon, 6 Jul 2015 00:46: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 4A67C1A8F38; Mon, 6 Jul 2015 00:46: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 B69EC747; Mon, 6 Jul 2015 09:46: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 Za_SBOriMuOK; Mon, 6 Jul 2015 09:46: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; Mon, 6 Jul 2015 09:46:03 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D31320035; Mon, 6 Jul 2015 09:46: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 jsHcv769d4YI; Mon, 6 Jul 2015 09:46:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18F312002B; Mon, 6 Jul 2015 09:46:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 47FB534EE349; Mon, 6 Jul 2015 09:45:59 +0200 (CEST) Date: Mon, 6 Jul 2015 09:45:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150706074558.GA6272@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Mon, 06 Jul 2015 07:46:08 -0000 On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > I propose this text in the conformance leaf: > > > > > > For import statements that do not specify a revision > > > date, the most recent revision in the library SHOULD > > > be used by the server."; > > > > > > It seems like a lot of data will be needed to model the dependency tree > > > for every import-stmt in every module. Don't forget every include-stmt > > > as well, since submodules can import with or without revision. > > > > > > IMO "SHOULD use latest" is good enough. > > > Perhaps modules should use import-by-revision when they > > > are published as RFCs (as Lada suggested). > > > > This sounds like "lets pretend the world is simple so we have less > > work to do". > > > > > No -- YANG currently says if there is no revision date > then the implementation can use any revision, Exactly - any revision. > This is also good enough. Prove that this is causing interoperability > problems. I don't think it is -- especially not such that the server > has to model all its imports so the client can retrieve the data. Did I say all imports? No. I think a server should announce which revision was picked to resolve imports without a revision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 6 02:37:34 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 F2CA21A9302 for ; Mon, 6 Jul 2015 02:37:32 -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 n1Qy0DDZQuw6 for ; Mon, 6 Jul 2015 02:37:31 -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 58B661A9251 for ; Mon, 6 Jul 2015 02:37:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B2EB58EA for ; Mon, 6 Jul 2015 11:37:29 +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 ZZAKo4c03nsP for ; Mon, 6 Jul 2015 11:37:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 6 Jul 2015 11:37:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED9602002C for ; Mon, 6 Jul 2015 11:37:28 +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 ys7RcqL24v0V; Mon, 6 Jul 2015 11:37: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 1EDDE2002B; Mon, 6 Jul 2015 11:37:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D608234EE951; Mon, 6 Jul 2015 11:37:22 +0200 (CEST) Date: Mon, 6 Jul 2015 11:37:21 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150706093721.GA429@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] YANG Models Required for Managing CPE Devices 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: Mon, 06 Jul 2015 09:37:33 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, while there is a lot of YANG activity outside this WG that usually does not get echoed here (which is goodness since we can't really track everything here), I thought this one deserves some recognition here because it provides a good overview of what we have, what is ongoing, and what is missing for managing a CPE using YANG data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --Nq2Wo0NMKNjxTN9z Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS01.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jul 2015 11:29:31 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atlas1.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 528B220013 for ; Mon, 6 Jul 2015 11:29:31 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 7DDFF6F6 for ; Mon, 6 Jul 2015 11:29:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.5, RP_MATCHES_RCVD=-1.051, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: demetrius1.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas1a.jacobs-university.de ([212.201.44.13]) by localhost (demetrius1.jacobs-university.de [212.201.44.46]) (amavisd-new, port 10030) with ESMTP id R84Z7VWLPsIU for ; Mon, 6 Jul 2015 11:29:29 +0200 (CEST) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -6.1 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by atlas1a.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 6 Jul 2015 11:29:24 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F25A21A92DD; Mon, 6 Jul 2015 02:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1436174953; bh=eLsYCV0vQjQav3wmrYAgSXkbR4mMNQhogFgJIOmKrBE=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=xa6VLZVUgpAUF7Cz/YEDHhDXhlzjEGMe4VAJGPhhDez2SNA6mruD6r/Fq1KTWsX6o rUJkB1uccov1IanhTTdbWEnkS/QrhuyLG4rTZkwIgkI5R39TIlxBQcAnCkUEmUurlL ScDJerLUU0EUpkXLLoIgOMB+1X7+ZYSTlVSZ1liA= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4101A9253 for ; Mon, 6 Jul 2015 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JKCBcbSSVyRW for ; Mon, 6 Jul 2015 02:29:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A41B21A92B8 for ; Mon, 6 Jul 2015 02:29:05 -0700 (PDT) From: To: Subject: I-D Action: draft-faq-anima-cpe-yang-profile-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706092905.9743.41387.idtracker@ietfa.amsl.com> Date: Mon, 6 Jul 2015 02:29:05 -0700 Archived-At: X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 7bit Errors-To: i-d-announce-bounces@ietf.org Sender: I-D-Announce Return-Path: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Models Required for Managing Customer Premises Equipment (CPE) Devices Authors : Ian Farrer Qi Sun Sladjana Zoric Mikael Abrahamsson Filename : draft-faq-anima-cpe-yang-profile-00.txt Pages : 13 Date : 2015-07-06 Abstract: This document collects together the YANG models necessary for managing a NETCONF-enabled Customer Premises Equipment (CPE) device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-faq-anima-cpe-yang-profile/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-faq-anima-cpe-yang-profile-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Nq2Wo0NMKNjxTN9z-- From nobody Mon Jul 6 06:34:13 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 009CC1AD291 for ; Mon, 6 Jul 2015 06:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 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_64=0.6, SPF_HELO_PASS=-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 5NqDbSvu7CuX for ; Mon, 6 Jul 2015 06:34:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 A8C451AD255 for ; Mon, 6 Jul 2015 06:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1436189622; bh=apcpYLy/+g8bvGAFh7M8MjyBaMJbia2RYjOU0N0aBVI=; h=From:Subject:Date:To; b=ReMcOge8UWVSUZXyRxchNQ1mqro64TBBZvXUQltNL5T0NqiAuexnSMqzDVLJatofR a11/BO3b7fW/Sy/GGfWWl5a2yBAGSoJj1wT8/5KpC+Lfc75qUjdgGHOvBYt4KEguzk qj8ICylj42ID4cWLKR9XXF08sFmPas2rkQw6a5vU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <204B5349-D932-4D99-8FFB-4119334EEDBF@lucidvision.com> Date: Mon, 6 Jul 2015 09:34:05 -0400 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=20 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 52, in=478, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Subject: [netmod] Interim Meeting Minutes June 25, 2015 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: Mon, 06 Jul 2015 13:34:10 -0000 These are the preliminary notes from the interim meeting on June = 25, 2015. I am still awaiting notes from Ignas who also took meeting = minutes before I post the official minutes. If there are any = comments/corrections to what I have below, please post here as soon as = possible.=20 =E2=80=94Tom NETMOD Virtual Interim Meeting (June 25, 2015) * Participants - Acee (AC) - Alia Atlas - Andy Bierman - Anees Shaikh - Aseem Choudhary - Balazs Lengyel - Benoit Claise - Clyde Wildes - Dan Romascanu - Einar - Giles - Ignas Bagdonas - Jason Sterne (JS) - Kent Watsen - Mahesh Jethanandani - Marcus ???? - Martin Bjorklund - Phil Shafer - Qin Wu - Robert Wilton - Sam Aldrin - Susan Hares - Tarek Saad - Tom Nadeau - Vishnu Pavan Beeram - Xufeng Liu - Yingzhen Qu =20 =20 Meeting starting (10:06am ET) =20 Agenda: - Agenda Bashing - draft-openconfig-netmod-opstate-00 - draft-openconfig-netmod-model-structure-00 Anees Presenting Going over terminology based on slides exchanged over e-mail. = Applied/actual configuration should not be fetched when a yet to be = defined is defined. In other words, get operational should = fetch only protocol negotiated values and counters. This would require a = flag other than config =3D false to be defined. - KW: is the applied/actual having the value "auto"? - AS: yes - KW: would the term "distributed" be better? - AS: no - JS: how far do we need to go to consider a config node "applied"? = (e.g., distributed systems) - AS: systems will differ, what matters is what they perceive to be = applied - SH: where would ephemeral state be catured? - AS: it's not captured in this model, but makes sense to view as = intended config that is not persisted - MB: where would interfaces configured by system (not = user-configured) be captured in this model? - AS: should be part of intended config - MB: so system should update intended config to capture/add these = additional nodes - M?: should show up in applied config (not intended) - MB: so applied config can contain more than just intended config... - AB: applied state a child of indended state? - MB: right, since parent is config=3Dtrue - RW: given interfaces MAY have config, then an unconfigured interface = (line card plugged in) still takes default config, no? - AS: makes sense that there are some default config values applied to = it, just not from intended config - SH: ephemeral operational state goes into operational state too? - AS: yes - AB: proposal about data organization, but there is a yang statement = too - AS: no, proposal has both. =20 - AB: Disagree duplicating data-model nodes, scales better to use = datastores [KW: Juergen made same point on list] - AS:=20 - MB: agree that should be possible to use w/o NC, but datastores = aren't NC-specific either [witness RC] - TN: isn't this the same thing? - two option: decorate model vs add = an operation - BL: protocol option better, as otherwise it would grow the saize of = the model greatly - AS: putting it into the model (data structure) can be simpler - MB: is 9/10 follow model-structure, but 10th doesn't, even though = valid YANG, the whole thing falls down - AB: overloading names could cause conflict - e.g., an address book's = "State" value - AS: may not be important to standardize models at this stage, = without much much operational experience, not too much value in existing = models - BC: do we have people that want to work on an optional proposal? = [no one steps forward] Moving on to model-structure draft (10:58am ET) - Anees presenting - MB: how is putting a device node under arbitrary parent? =20 - AS: useful anchor point, not stricly necessary but very useful and = don't see anything harmful in it - AB: adds more payload to every message in every protocol - AS: don't understand payload comment - AB: adds string to instance-identifier - BL: ex: alarm, the length of the instance-identifier is an important = point - MB: what's the point of having top-level "/device", why not just = "/"?=20 - PS: more than that... - AS: so bring up everything one level would be better? - MB: yes - AS: yeah, i agree - AA: what is the argument behind having "/device"? - string length? - AB: no value - AS: thought a single anchor would be useful - BC: regardless of single anchor, is there agreement of having any = common anchor points? - AB: likes catalog part - BC: likes it too, who would organize it? - KW: like catalog too, but thinks the catalog should also contain = transformation to/from lower-level models - AS: agrees that there can be a multiplicity of top-level models - TN: this may need to be an informational draft =20 Moving on to Meta-Model Structure slides (Acee presenting) - JS: re: logical network level, should different logical routers have = different NETCONF sessions? - AC: sounds like an SNMP like solution - SH: why policy under each protocol as opposed to at the top? - AC: it's like an object can be applied to each protocol - BC: how far we with YANG1.1 and is there anything useful in it for = routing design team? - MB: ~1 open issue left and then will publish draft, should be ready = for WGLC. =20 - BC: when Y1.1 is published, we'll need to advertise it to other = design teams =20 [Meeting Ends @ 11:50am ET] From nobody Mon Jul 6 06:41:15 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 DCD191A1BCF for ; Mon, 6 Jul 2015 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 MJZ26SwZm9rH for ; Mon, 6 Jul 2015 06:41:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 D90631A1BA4 for ; Mon, 6 Jul 2015 06:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1436190046; bh=wc5CW2INa0VEAceL9vcjlHBE2h3wQDlDa2zb4da6w4o=; h=From:Subject:Date:To; b=FMDRQ6rrI3F64w/vn+diwl7bRnF/GgDVT/wrsVNVDfp+YcitIB4ZXaJQMEQjyPj+R j1fxJoAz47hKP11bM/+Ylw2x5pbK+3ZY/5COWDYkQ20MBW9oYqVe0xHpdo50KfxpZ4 15AoulRVtxDOSiiw+QDZbVW0l//m1riU+qhqNi5Y= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <60B90693-54AC-468C-96AD-0908AEAD6538@lucidvision.com> Date: Mon, 6 Jul 2015 09:41:09 -0400 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=21 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 52, in=479, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Subject: [netmod] Open Config Options 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: Mon, 06 Jul 2015 13:41:14 -0000 One of the actions from the last Interim meeting was to have = both sides of the issues around the open config approach to create at = least slides/textual bullet points for use during our discussion in = Praha so we can come to a conclusion around the final issues. We need = these slides/bullet points to be listed on the list here and continue = the discussion here BEFORE the Praha meeting. I=E2=80=99d like to ask = Anees and Rob to write up their side of the story. As I recall Juergen, = Kent, Martin and Andy were the most vocal around the other side of = things, so I would like to ask them to write up their side of things. = Can you all please confirm your acceptance of this action and a target = for when you will post the issues?=20 =E2=80=94Tom From nobody Mon Jul 6 07:26:29 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 44ED91A88C8 for ; Mon, 6 Jul 2015 07:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 jfjyDtFWBy-B for ; Mon, 6 Jul 2015 07:26:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD34A1A88CF for ; Mon, 6 Jul 2015 07:26:07 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB508.namprd05.prod.outlook.com (10.141.71.153) with Microsoft SMTP Server (TLS) id 15.1.201.16; Mon, 6 Jul 2015 14:26:06 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 14:26:04 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 14:26:04 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: presentations for ietf 93 Thread-Index: AQHQt/ewmEwMbwjLvUWlELzqEBXdnA== Date: Mon, 6 Jul 2015 14:26:04 +0000 Message-ID: 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: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 24:hTtbbf/L9mg2Z4YaKPILkjk1eDDV51EMw5JO6+WZNmXFWz9YbehjSdjW9Pg7L168sM0c+3dY+MepIWNfJxUp/qYyne4gm0kudzfsWLXQmuY=; 20:DEysSfhJkGgEygAg/cQcSEUh0W/iJ20BwAXAf7BxCXfnDVCRfEkAvkyq/noCTPx/E25JTOxTNxOqxnDpb4vmXA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB508; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2351001)(5002640100001)(106116001)(36756003)(229853001)(110136002)(122556002)(86362001)(40100003)(62966003)(77156002)(5001960100002)(2501003)(189998001)(66066001)(16236675004)(46102003)(54356999)(87936001)(102836002)(2900100001)(92566002)(50986999)(4001350100001)(83506001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1C00839B80A0kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 14:26:04.5848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB508; 2:aIfSvqxLKwCXal3rW0vng07gV/aV+T1p3r7h8I0xJWRhUPaaNI7i+wUa4fyXl0qg; 3:q4F+0UluhcoUPWINQ96G3MPRuYjh8Dee4T2WPrmWHq3fg/68ggR9SARGRQQV2gWzz/QlhsvqUjRyhA6Fr5jxWaOQerZeOsZs2QlNUN/YFI5JZeZzAoguyZCcc85z1bqdlYWLCF1zbrmqtL4qTt9PwQ==; 25:a05T1R8EB+SgNS3LXeLeJcU48t+yXec3xOzG1iu7Rk4qEbyhUA/gJpdxYXegvSGV2vIO8iJoUP49SfuqOu2TxR4eTmRbkvFSF2ky2sVad9c7gEEQPHWTx1FYGUyFN9DBLacBPKKgnWO7lM4HM8trA8JfwjMNd4bNPkGsh9ld8inz6PqOjucOyGLQswyjeQy87jhTdjf5lyuIZLiYhO61YLDeaVmDBSH/kmmlAo7v+Q4fruh7ICeO05JDXTH3YSkhc31RGLM9ZSrU3Nvo2oSXDg==; 23:0TGT04ZM8JfMs1DYOmMKPWC4LznXJGIgrpdfUO0K0HqjKwDgJHIXnysnNHoBLVrhy0XLQJKvAOTHxNEh4xcZJYgoUozOT2IUwjUxtu/uzzyTDufFCvkPFftQsflr8vjlT+wGaQjAqNMznaW0QbtCEK74XTe+j8wrDtpAmk7xk/ZkaBJFf/3VOELqG/sq+GKz5bDmaogHRpiIgKb5g0JyUmSDIAgVc4tSQ9hQh0Dn1lvXylhwoXblLuQnYIRmwhW7 X-OriginatorOrg: juniper.net Archived-At: Cc: "netmod-chairs@tools.ietf.org" Subject: [netmod] presentations for ietf 93 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: Mon, 06 Jul 2015 14:26:24 -0000 --_000_D1C00839B80A0kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The NETMOD working group is meeting twice for IETF 93 in Prague: Monday: 18:50-19:50 (1 hour) Tuesday: 15:20-17:20 (2 hours) If you would like to request a time-slot for a presentation at IETF 93, ple= ase reply by Friday, July 10th with the following information: 1) Draft title 2) Presenter name 3) Requested duration Requests for slots with discussion on the mailing list are given priority. = Please start a discussion on your draft now if needed. Thanks, Kent --_000_D1C00839B80A0kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The NETMOD working group is meeting twice for IETF 93 in Prague:

    Monday= :  18:50-19:50  (1 hour)
    Tuesday: 15:20-17:20 &= nbsp;(2 hours)

If you would like to request a time-slot for a presentation at IETF 93, ple= ase reply by Friday, July 10th with the following information:

    1) Draft title<= /div>
    2) Presenter name
    3) Requested duration<= /font>

Requests for slots w= ith discussion on the mailing list are given priority.   Please start = a discussion on your draft now if needed.

Thanks,
Kent

--_000_D1C00839B80A0kwatsenjunipernet_-- From nobody Mon Jul 6 07:45: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 2D2B01ACAD5; Mon, 6 Jul 2015 07:45: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] 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 xRuwcpVcUXwF; Mon, 6 Jul 2015 07:45:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D231A1A5D; Mon, 6 Jul 2015 07:45:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706144537.26465.57258.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:45:37 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:45:38 -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 : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-06.txt Pages : 196 Date : 2015-07-06 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 07:49:29 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 A785F1B2A8B for ; Mon, 6 Jul 2015 07:49: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 ZxHccvpve__t for ; Mon, 6 Jul 2015 07:49:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA91B2A89 for ; Mon, 6 Jul 2015 07:49:27 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 85AAA1AE047F for ; Mon, 6 Jul 2015 16:49:25 +0200 (CEST) Date: Mon, 06 Jul 2015 16:49:24 +0200 (CEST) Message-Id: <20150706.164924.597089872574111503.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20150706144537.26465.57258.idtracker@ietfa.amsl.com> References: <20150706144537.26465.57258.idtracker@ietfa.amsl.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: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-06.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: Mon, 06 Jul 2015 14:49:28 -0000 Hi, This version addresses Y45, except that it may need to be aligned with any data model changes in ietf-yang-library. There is now one remaining issue, Y60, that has to do with coexistence with YANG 1.0. Please see https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-61 /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) > Author : Martin Bjorklund > Filename : draft-ietf-netmod-rfc6020bis-06.txt > Pages : 196 > Date : 2015-07-06 > > Abstract: > YANG is a data modeling language used to model configuration and > state data manipulated by the Network Configuration Protocol > (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. > This document obsoletes RFC 6020. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Jul 6 07:59:40 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 04D261A897A for ; Mon, 6 Jul 2015 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 NwfSEZZQqu7D for ; Mon, 6 Jul 2015 07:59:35 -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 3469C1A8928 for ; Mon, 6 Jul 2015 07:59:31 -0700 (PDT) Received: by labgy5 with SMTP id gy5so6144594lab.2 for ; Mon, 06 Jul 2015 07:59: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:content-type; bh=AZKpYakO4kPeHO7Ed0jHhEPj9voO2HhcqvKF5Lso0HM=; b=E0PDZ0v+UlDJZG/BXKuuQoOZdROYbV80zxJ8Uz4eK4qg2lBnViGBHcIW061x8v/ZZ/ gYoVTRKJvRENMWw5oGGc2U85y63WX1wfIoB+WD051cnZUiidW1lKuQ9wbHhFoOIJRa+k xOScb6sgIBS2bHIZr3wEDVbH63Yepj+xWq2Y9Av/NmBWYzSkOTA7UqAOCBmhPBpcvw6C cbJmlfch5PAorwhMSoXh8BlnskSm9y2b6Whkh7HXSeDpEXSbGY9tx0hAmm62q1K0Kk2p OfJF7t5ab4BYPiyPZVAhgXuwS/kkKKP117RWS/MBaRUdBQfF7bJBYzcBJX76JmB9G5iJ feXg== X-Gm-Message-State: ALoCoQmRofBjY/Y9iVB8JfBmH9f0plUKyfok8siQnsUMykdC/jnd9jJanZq+/b1r0HO9W3eajHPu MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr33882668lbl.123.1436194769688; Mon, 06 Jul 2015 07:59:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 07:59:29 -0700 (PDT) In-Reply-To: <20150706074558.GA6272@elstar.local> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> Date: Mon, 6 Jul 2015 07:59:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11346d9c1370a4051a362754 Archived-At: Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Mon, 06 Jul 2015 14:59:37 -0000 --001a11346d9c1370a4051a362754 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > I propose this text in the conformance leaf: > > > > > > > > For import statements that do not specify a revision > > > > date, the most recent revision in the library SHOULD > > > > be used by the server."; > > > > > > > > It seems like a lot of data will be needed to model the dependency > tree > > > > for every import-stmt in every module. Don't forget every > include-stmt > > > > as well, since submodules can import with or without revision. > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > Perhaps modules should use import-by-revision when they > > > > are published as RFCs (as Lada suggested). > > > > > > This sounds like "lets pretend the world is simple so we have less > > > work to do". > > > > > > > > No -- YANG currently says if there is no revision date > > then the implementation can use any revision, > > Exactly - any revision. > > > This is also good enough. Prove that this is causing interoperability > > problems. I don't think it is -- especially not such that the server > > has to model all its imports so the client can retrieve the data. > > Did I say all imports? No. I think a server should announce which > revision was picked to resolve imports without a revision. > > But it could be any revision. A imports B.1 imports C D imports B.4 imports C E imports F imports G imports C C can be imported many times without revision. Any import in the chain can be with out without a revision date. IMO "SHOULD use latest revision of C advertised" is best because the latest revision is generally the most correct and supports the most product features. If the import of C really depends on specific revisions of some typedefs, groupings, etc. then import by revision MUST be used everywhere in the dependency chain (C and all its imports). If no revision-stmt is present the server can pick whatever revision it wants. If this is a problem, then fix this problem, don't add some complex monitoring requirements for servers to implement and clients to process. Let's make import-by-revision mandatory if import-without-revision is a such a problem. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11346d9c1370a4051a362754 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierm= an wrote:
> On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote:
> >
> > > I propose this text in the conformance leaf:
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For i= mport statements that do not specify a revision
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 date,= the most recent revision in the library SHOULD
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be us= ed by the server.";
> > >
> > > It seems like a lot of data will be needed to model the depe= ndency tree
> > > for every import-stmt in every module.=C2=A0 Don't forge= t every include-stmt
> > > as well, since submodules can import with or without revisio= n.
> > >
> > > IMO "SHOULD use latest" is good enough.
> > > Perhaps modules should use import-by-revision when they
> > > are published as RFCs (as Lada suggested).
> >
> > This sounds like "lets pretend the world is simple so we hav= e less
> > work to do".
> >
> >
> No -- YANG currently says if there is no revision date
> then the implementation can use any revision,

Exactly - any revision.

> This is also good enough.=C2=A0 Prove that this is causing interoperab= ility
> problems.=C2=A0 I don't think it is -- especially not such that th= e server
> has to model all its imports so the client can retrieve the data.

Did I say all imports? No. I think a server should announce which
revision was picked to resolve imports without a revision.


But it could be any revision.

=C2=A0 =C2=A0A= imports B.1 imports C
=C2=A0 =C2=A0D imports B.4 imports C
=
=C2=A0 =C2=A0E imports F imports G imports C

= C can be imported many times without revision.
Any import in the = chain can be with out without a revision date.

IMO= "SHOULD use latest revision of C advertised" is best because
the latest revision is generally the most correct and supports the
most product features.

If the import of C= really depends on specific revisions of
some typedefs, groupings= , etc. then import by revision MUST
be used everywhere in the dep= endency chain (C and all its imports).

If no revis= ion-stmt is present the server can pick whatever revision
it want= s.=C2=A0 If this is a problem, then fix this problem, don't add
some complex monitoring requirements for servers to implement
= and clients to process.=C2=A0 Let's make import-by-revision mandatory
if import-without-revision is a such a problem.




=C2=A0
/js

Andy
=C2=A0=

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

--001a11346d9c1370a4051a362754-- From nobody Mon Jul 6 08:04:47 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 8C5261A893C; Mon, 6 Jul 2015 08:04: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 iM-N3CSR_lKT; Mon, 6 Jul 2015 08:04: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 72FD91A8A29; Mon, 6 Jul 2015 08:04: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 9827B111B; Mon, 6 Jul 2015 17:04: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 ukwvMAUA6W21; Mon, 6 Jul 2015 17:04:36 +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 Jul 2015 17:04:35 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AAC72002B; Mon, 6 Jul 2015 17:04: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 S_8B8IM9Bl-q; Mon, 6 Jul 2015 17:04:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E6ED20013; Mon, 6 Jul 2015 17:04:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EA03734EF19E; Mon, 6 Jul 2015 17:04:30 +0200 (CEST) Date: Mon, 6 Jul 2015 17:04:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150706150430.GA342@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Mon, 06 Jul 2015 15:04:44 -0000 On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: > On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > > > I propose this text in the conformance leaf: > > > > > > > > > > For import statements that do not specify a revision > > > > > date, the most recent revision in the library SHOULD > > > > > be used by the server."; > > > > > > > > > > It seems like a lot of data will be needed to model the dependency > > tree > > > > > for every import-stmt in every module. Don't forget every > > include-stmt > > > > > as well, since submodules can import with or without revision. > > > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > > Perhaps modules should use import-by-revision when they > > > > > are published as RFCs (as Lada suggested). > > > > > > > > This sounds like "lets pretend the world is simple so we have less > > > > work to do". > > > > > > > > > > > No -- YANG currently says if there is no revision date > > > then the implementation can use any revision, > > > > Exactly - any revision. > > > > > This is also good enough. Prove that this is causing interoperability > > > problems. I don't think it is -- especially not such that the server > > > has to model all its imports so the client can retrieve the data. > > > > Did I say all imports? No. I think a server should announce which > > revision was picked to resolve imports without a revision. > > > > > But it could be any revision. > > A imports B.1 imports C > D imports B.4 imports C > E imports F imports G imports C Can we agree on "all imports without a revision fixed in the data model"? > C can be imported many times without revision. Yes. > Any import in the chain can be with out without a revision date. Yes. > IMO "SHOULD use latest revision of C advertised" is best because > the latest revision is generally the most correct and supports the > most product features. But I thought the goal was to know precisely what a device implements, not what it _could_ implement. > If the import of C really depends on specific revisions of > some typedefs, groupings, etc. then import by revision MUST > be used everywhere in the dependency chain (C and all its imports). > > If no revision-stmt is present the server can pick whatever revision > it wants. If this is a problem, then fix this problem, don't add > some complex monitoring requirements for servers to implement > and clients to process. Let's make import-by-revision mandatory > if import-without-revision is a such a problem. If the data model leaves it open, then indeed the implementor can choose. What is wrong with reporting what was chosen? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 6 08:16:40 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 9743D1A8A20 for ; Mon, 6 Jul 2015 08:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_d1I-TbqSxC for ; Mon, 6 Jul 2015 08:16:36 -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 DB02C1AD255 for ; Mon, 6 Jul 2015 08:16:34 -0700 (PDT) Received: by lagx9 with SMTP id x9so159331550lag.1 for ; Mon, 06 Jul 2015 08:16:33 -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=DBs7/mUIZXGDfwC87RaikRCPDnRojmcQZmbUKKGUDzM=; b=b4eIPvlpUebSvWOKWzXR5EC2WJi/vK6mHSWB+ddYG9JJ48QEo8U6SNAvEigEQovgSl kqSnVvH4eT2W6X8iPsaY9jbMyNwyp2LOpmWmIek/kx8Hm1ze9+XyVKSj4Eb04VTFRxVK IK9ynn1huC/HaWwJrQIfD7bdGhis903e0p0MKQIgyzfFWz9UshOrJ9MKrm16nPJhfd1l 9KWhNtckMdKGD9c7sqqzUGKiqmjm+3jqt69hWUWMANtXyv2TVXz8CgPCDN1n6P91omdp +5++8fXBPwnXZVw3JooZBMxLLqYy5I1ZX3TwQJI6yXm6OD8BITLGMpeNJz2clvh2dzfC QP3Q== X-Gm-Message-State: ALoCoQm0b42b/pmRAA31ZRCvVoZjUmn1rcnI90aCHQmpb77ZQfy0EmXKGap/DDY5c3awEYrHPlG2 MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr49453461lbp.88.1436195793243; Mon, 06 Jul 2015 08:16:33 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 08:16:32 -0700 (PDT) In-Reply-To: <20150706150430.GA342@elstar.local> References: <20150630124503.GA5406@elstar.local> <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> <20150706150430.GA342@elstar.local> Date: Mon, 6 Jul 2015 08:16:32 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113403d815a9ce051a366431 Archived-At: Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Mon, 06 Jul 2015 15:16:38 -0000 --001a113403d815a9ce051a366431 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierman wrote: > > On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote: > > > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman wrote: > > > > > > > > > > > I propose this text in the conformance leaf: > > > > > > > > > > > > For import statements that do not specify a > revision > > > > > > date, the most recent revision in the library > SHOULD > > > > > > be used by the server."; > > > > > > > > > > > > It seems like a lot of data will be needed to model the > dependency > > > tree > > > > > > for every import-stmt in every module. Don't forget every > > > include-stmt > > > > > > as well, since submodules can import with or without revision. > > > > > > > > > > > > IMO "SHOULD use latest" is good enough. > > > > > > Perhaps modules should use import-by-revision when they > > > > > > are published as RFCs (as Lada suggested). > > > > > > > > > > This sounds like "lets pretend the world is simple so we have less > > > > > work to do". > > > > > > > > > > > > > > No -- YANG currently says if there is no revision date > > > > then the implementation can use any revision, > > > > > > Exactly - any revision. > > > > > > > This is also good enough. Prove that this is causing > interoperability > > > > problems. I don't think it is -- especially not such that the server > > > > has to model all its imports so the client can retrieve the data. > > > > > > Did I say all imports? No. I think a server should announce which > > > revision was picked to resolve imports without a revision. > > > > > > > > But it could be any revision. > > > > A imports B.1 imports C > > D imports B.4 imports C > > E imports F imports G imports C > > Can we agree on "all imports without a revision fixed in the data > model"? > That's not what the RFC 6020 says (not sure about bis) > > > C can be imported many times without revision. > > Yes. > > > Any import in the chain can be with out without a revision date. > > Yes. > > > IMO "SHOULD use latest revision of C advertised" is best because > > the latest revision is generally the most correct and supports the > > most product features. > > But I thought the goal was to know precisely what a device implements, > not what it _could_ implement. > > > If the import of C really depends on specific revisions of > > some typedefs, groupings, etc. then import by revision MUST > > be used everywhere in the dependency chain (C and all its imports). > > > > If no revision-stmt is present the server can pick whatever revision > > it wants. If this is a problem, then fix this problem, don't add > > some complex monitoring requirements for servers to implement > > and clients to process. Let's make import-by-revision mandatory > > if import-without-revision is a such a problem. > > If the data model leaves it open, then indeed the implementor can > choose. What is wrong with reporting what was chosen? > If there is just a leaf that says 'default-revision=true' like I proposed, then no problem. If I have to reproduce the entire imports/include->imports tree with filled in revision dates, then this is overkill, too much memory/data, and it is a problem. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a113403d815a9ce051a366431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 06, 2015 at 07:59:29AM -0700, Andy Bierma= n wrote:
> On Mon, Jul 6, 2015 at 12:45 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Mon, Jul 06, 2015 at 12:39:21AM -0700, Andy Bierman wrote:
> > > On Sun, Jul 5, 2015 at 11:57 PM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Fri, Jul 03, 2015 at 02:12:30PM -0700, Andy Bierman = wrote:
> > > >
> > > > > I propose this text in the conformance leaf:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 For import statements that do not specify a revision
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 date, the most recent revision in the library SHOULD
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 be used by the server.";
> > > > >
> > > > > It seems like a lot of data will be needed to mode= l the dependency
> > tree
> > > > > for every import-stmt in every module.=C2=A0 Don&#= 39;t forget every
> > include-stmt
> > > > > as well, since submodules can import with or witho= ut revision.
> > > > >
> > > > > IMO "SHOULD use latest" is good enough.<= br> > > > > > Perhaps modules should use import-by-revision when= they
> > > > > are published as RFCs (as Lada suggested).
> > > >
> > > > This sounds like "lets pretend the world is simple= so we have less
> > > > work to do".
> > > >
> > > >
> > > No -- YANG currently says if there is no revision date
> > > then the implementation can use any revision,
> >
> > Exactly - any revision.
> >
> > > This is also good enough.=C2=A0 Prove that this is causing i= nteroperability
> > > problems.=C2=A0 I don't think it is -- especially not su= ch that the server
> > > has to model all its imports so the client can retrieve the = data.
> >
> > Did I say all imports? No. I think a server should announce which=
> > revision was picked to resolve imports without a revision.
> >
> >
> But it could be any revision.
>
>=C2=A0 =C2=A0 A imports B.1 imports C
>=C2=A0 =C2=A0 D imports B.4 imports C
>=C2=A0 =C2=A0 E imports F imports G imports C

Can we agree on "all imports without a revision fixed in the data
model"?
=C2=A0

That'= s not what the RFC 6020 says (not sure about bis)
=C2=A0

> C can be imported many times without revision.

Yes.

> Any import in the chain can be with out without a revision date.

Yes.

> IMO "SHOULD use latest revision of C advertised" is best bec= ause
> the latest revision is generally the most correct and supports the
> most product features.

But I thought the goal was to know precisely what a device implements,
not what it _could_ implement.

> If the import of C really depends on specific revisions of
> some typedefs, groupings, etc. then import by revision MUST
> be used everywhere in the dependency chain (C and all its imports). >
> If no revision-stmt is present the server can pick whatever revision > it wants.=C2=A0 If this is a problem, then fix this problem, don't= add
> some complex monitoring requirements for servers to implement
> and clients to process.=C2=A0 Let's make import-by-revision mandat= ory
> if import-without-revision is a such a problem.

If the data model leaves it open, then indeed the implementor can
choose.=C2=A0 What is wrong with reporting what was chosen?

If there is just a leaf that says 'default-revisio= n=3Dtrue'
like I proposed, then no problem.=C2=A0 If I have t= o reproduce the
entire imports/include->imports tree with fill= ed in revision dates,
then this is overkill, too much memory/data= , and it is a problem.



/js



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

--001a113403d815a9ce051a366431-- From nobody Mon Jul 6 10:14:31 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 5854F1B2FCC; Mon, 6 Jul 2015 10:14: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] 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 80qJSUBi4JdJ; Mon, 6 Jul 2015 10:14:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 380E71A914A; Mon, 6 Jul 2015 10:14:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706171427.3438.31431.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 10:14:27 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:14:28 -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-04.txt Pages : 52 Date : 2015-07-06 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: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 10:31: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 487371A01A9 for ; Mon, 6 Jul 2015 10:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c1VUDoaMGJ9 for ; Mon, 6 Jul 2015 10:31:09 -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 D2A521A6F12 for ; Mon, 6 Jul 2015 10:31:07 -0700 (PDT) Received: by lagx9 with SMTP id x9so164255938lag.1 for ; Mon, 06 Jul 2015 10:31: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:date:message-id:subject:from:to :content-type; bh=qNKOMFmuqiVHYKo55kTOYIkD2za69/M53uznqXDkWHQ=; b=FMv8n0I2dlSgm4gad+Huv20JoN5CgvqJXrIZ0akEaM37jBOC994bmPuNuwjI5Z4c5J tvDClSt7ujs4yAypqi7RUkU49r4utbjeSxIddqoi4PoI6C8RU/OD0jHMiA7gVk9OGFjB /UfeP/fHNfJ8mLwSrM9RQAkCxJTZ2W6sT0jYoglDVQgqSswWGbgMxCGiAxgndMTDbO6U ZNSV5naZnSnQhEmmtXtflLflhc6u0VTaF8TFyu8Qd0g/PSCKJNWON2Z24p8LP/ejqoP8 iXZYDVChOSGtEQT8GB+dxudSgZQnvYKJ7WXcV1mmbCz773d9LvvjDBH77HdLI6BBvFK/ mvjA== X-Gm-Message-State: ALoCoQnYkX57dtoX/Tm0XQpsT5HP9l32EfRnMb8msH6fCkp5pcrQR889Z0VgncncWsEuZPwWkZz0 MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr734lbp.88.1436203866268; Mon, 06 Jul 2015 10:31:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 10:31:06 -0700 (PDT) Date: Mon, 6 Jul 2015 10:31:06 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" , Core Content-Type: multipart/alternative; boundary=001a113403d8463ea6051a3845c3 Archived-At: Subject: [netmod] YANG Packages draft 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: Mon, 06 Jul 2015 17:31:10 -0000 --001a113403d8463ea6051a3845c3 Content-Type: text/plain; charset=UTF-8 Hi, I submitted a new draft for defining YANG packages. http://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt IMO this could be useful for organizing YANG modules. It may also be applicable for CoMI, by allowing a tiny number of packages to be advertised to the client, instead of a relatively large number of modules. Andy --001a113403d8463ea6051a3845c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I submitted a new draft for definin= g YANG packages.


IMO this c= ould be useful for organizing YANG modules.
It may also be applic= able for CoMI, by allowing
a tiny number of packages to be advert= ised to the client,
instead of a relatively large number of modul= es.



Andy
<= br>
--001a113403d8463ea6051a3845c3-- From nobody Mon Jul 6 12:59: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 DA1EA1B319E for ; Mon, 6 Jul 2015 12:59:41 -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 Yf1ROMGypG7S for ; Mon, 6 Jul 2015 12:59: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 147F41B3186 for ; Mon, 6 Jul 2015 12:59:26 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B0A91AE047F; Mon, 6 Jul 2015 21:59:24 +0200 (CEST) Date: Mon, 06 Jul 2015 21:59:23 +0200 (CEST) Message-Id: <20150706.215923.809321918539432386.mbj@tail-f.com> To: tnadeau@lucidvision.com From: Martin Bjorklund In-Reply-To: <60B90693-54AC-468C-96AD-0908AEAD6538@lucidvision.com> References: <60B90693-54AC-468C-96AD-0908AEAD6538@lucidvision.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Open Config Options 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: Mon, 06 Jul 2015 19:59:42 -0000 SGksDQoNCk5hZGVhdSBUaG9tYXMgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPiB3cm90ZToNCj4g DQo+IAlPbmUgb2YgdGhlIGFjdGlvbnMgZnJvbSB0aGUgbGFzdCBJbnRlcmltIG1lZXRpbmcgd2Fz IHRvIGhhdmUgYm90aA0KPiAJc2lkZXMgb2YgdGhlIGlzc3VlcyBhcm91bmQgdGhlIG9wZW4gY29u ZmlnIGFwcHJvYWNoIHRvIGNyZWF0ZSBhdCBsZWFzdA0KPiAJc2xpZGVzL3RleHR1YWwgYnVsbGV0 IHBvaW50cyBmb3IgdXNlIGR1cmluZyBvdXIgZGlzY3Vzc2lvbiBpbiBQcmFoYSBzbw0KPiAJd2Ug Y2FuIGNvbWUgdG8gYSBjb25jbHVzaW9uIGFyb3VuZCB0aGUgZmluYWwgaXNzdWVzLiAgV2UgbmVl ZCB0aGVzZQ0KPiAJc2xpZGVzL2J1bGxldCBwb2ludHMgdG8gYmUgbGlzdGVkIG9uIHRoZSBsaXN0 IGhlcmUgYW5kIGNvbnRpbnVlIHRoZQ0KPiAJZGlzY3Vzc2lvbiBoZXJlIEJFRk9SRSB0aGUgUHJh aGEgbWVldGluZy4gIEnigJlkIGxpa2UgdG8gYXNrIEFuZWVzIGFuZA0KPiAJUm9iIHRvIHdyaXRl IHVwIHRoZWlyIHNpZGUgb2YgdGhlIHN0b3J5LiAgQXMgSSByZWNhbGwgSnVlcmdlbiwgS2VudCwN Cj4gCU1hcnRpbiBhbmQgQW5keSB3ZXJlIHRoZSBtb3N0IHZvY2FsIGFyb3VuZCB0aGUgb3RoZXIg c2lkZSBvZiB0aGluZ3MsDQo+IAlzbyBJIHdvdWxkIGxpa2UgdG8gYXNrIHRoZW0gdG8gd3JpdGUg dXAgdGhlaXIgc2lkZSBvZiB0aGluZ3MuICBDYW4geW91DQo+IAlhbGwgcGxlYXNlIGNvbmZpcm0g eW91ciBhY2NlcHRhbmNlIG9mIHRoaXMgYWN0aW9uIGFuZCBhIHRhcmdldCBmb3INCj4gCXdoZW4g eW91IHdpbGwgcG9zdCB0aGUgaXNzdWVzPw0KDQpXZSBoYXZlIHBvc3RlZCBvdXIgdGhvdWdodHMg aW4gdGhpcyBkcmFmdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iam9ya2x1 bmQtbmV0bW9kLW9wZW5jb25maWctcmVwbHktMDANCg0KDQovbWFydGluDQoNCg== From nobody Mon Jul 6 13:14:57 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 007A31B31C3 for ; Mon, 6 Jul 2015 13:14:56 -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 VoSflFNMZ0Me for ; Mon, 6 Jul 2015 13:14:54 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5991B31A2 for ; Mon, 6 Jul 2015 13:14:54 -0700 (PDT) Received: by oiab3 with SMTP id b3so8103000oia.1 for ; Mon, 06 Jul 2015 13:14:54 -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=I3mg8LAEZtEGoA/0hFACkGAOwKAALons0q2uQRiZwhE=; b=kj0zuOC2RWl8vdG4j+uVqW/suPGyLS1BFWsHLr7mJ9bB6qciqO186XK1AkLznc+Vzh UnOJLiAuGW4777p+dgZo7QjWP1da4ZZFz2H8fcIguStLmlPpK+f/PNdonupd+fQ8avTm WGzPRBetbyVHr1ATTtRWiwEEqz1i87yKc8+LYRN1nZguNSeGbO/6SVR7iRe9x/xx2R6i r93fmsyZJryDeirwPYi5KyP0cCgKuD7Wz73xQl1W1EyxMCqVZ1qoUQb47rWx2eS2R7px YND+Qoc3EWgCWOw9WNKAna0fJjf+P7uTN7rlVuzmUdT5TNsdW7oWOFp7ykB3myQ0+29a nTaw== 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=I3mg8LAEZtEGoA/0hFACkGAOwKAALons0q2uQRiZwhE=; b=ckJ3Mu5xlxg9pw7Odanx+yOfp+NIxlDusj4+iPrH7zc4N0cjO/mfo1b1GFflgHzgJJ rr65/A6JIGhR4K2WusEqJInQ7pQLMpo61UMeztgwtzPGf0Vl8AzaZSx9yJrWY1xDHKKL 2xKR6gIgZvdJ579IYCBAHFEC3ezUk45nqEkXQxt4CHi/SUmbT0PehW/2D7sw9uMxQwTK X+XFJoCgfdLKUwkcTUDhUG0H3gOP8VLOkvypTh9PG0O+obCi86Mf3v5macFWVCwzgSxN W9lGqclhkp9rrhXHOFSQQn4/YcRMedbfCHCcd8L/iBz4h7Z4SmQiPHl9+iV0i76BHauu JaEQ== X-Gm-Message-State: ALoCoQkGbvjXOdQMS+hW/CQOqVlTdQ6CQw4EaURAduLioyImMvSObrJkFDkHcfboSRhuRKkB68lp MIME-Version: 1.0 X-Received: by 10.60.79.193 with SMTP id l1mr574204oex.60.1436213693944; Mon, 06 Jul 2015 13:14:53 -0700 (PDT) Received: by 10.182.52.199 with HTTP; Mon, 6 Jul 2015 13:14:53 -0700 (PDT) In-Reply-To: <20150706.215923.809321918539432386.mbj@tail-f.com> References: <60B90693-54AC-468C-96AD-0908AEAD6538@lucidvision.com> <20150706.215923.809321918539432386.mbj@tail-f.com> Date: Mon, 6 Jul 2015 13:14:53 -0700 Message-ID: From: Anees Shaikh To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e011773730cd3c6051a3a8fb8 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Open Config Options 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: Mon, 06 Jul 2015 20:14:56 -0000 --089e011773730cd3c6051a3a8fb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We've posted a new version of our draft: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 It includes a section on the issues that were raised and our observation/comment. It also adds a detailed section on terminology based on the interim calls, and updates the operational requirements with further details. thanks. -- Anees On Mon, Jul 6, 2015 at 12:59 PM, Martin Bjorklund wrote: > Hi, > > Nadeau Thomas wrote: > > > > One of the actions from the last Interim meeting was to have both > > sides of the issues around the open config approach to create at > least > > slides/textual bullet points for use during our discussion in > Praha so > > we can come to a conclusion around the final issues. We need the= se > > slides/bullet points to be listed on the list here and continue t= he > > discussion here BEFORE the Praha meeting. I=E2=80=99d like to as= k Anees > and > > Rob to write up their side of the story. As I recall Juergen, > Kent, > > Martin and Andy were the most vocal around the other side of > things, > > so I would like to ask them to write up their side of things. Ca= n > you > > all please confirm your acceptance of this action and a target fo= r > > when you will post the issues? > > We have posted our thoughts in this draft: > https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e011773730cd3c6051a3a8fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've posted a new version of our draft:
<= br>
It includes a section on the issues that were raised and our = observation/comment.=C2=A0 It also adds a detailed section on terminology b= ased on the interim calls, and updates the operational requirements with fu= rther details.

thanks.
-- Anees


On Mon, Jul 6, 2015 at 12:59 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Nadeau Thomas <tnadeau@lucidv= ision.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0One of the actions from the last Interim mee= ting was to have both
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sides of the issues around the open config a= pproach to create at least
>=C2=A0 =C2=A0 =C2=A0 =C2=A0slides/textual bullet points for use during = our discussion in Praha so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0we can come to a conclusion around the final= issues.=C2=A0 We need these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0slides/bullet points to be listed on the lis= t here and continue the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0discussion here BEFORE the Praha meeting.=C2= =A0 I=E2=80=99d like to ask Anees and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Rob to write up their side of the story.=C2= =A0 As I recall Juergen, Kent,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Martin and Andy were the most vocal around t= he other side of things,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0so I would like to ask them to write up thei= r side of things.=C2=A0 Can you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all please confirm your acceptance of this a= ction and a target for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when you will post the issues?

We have posted our thoughts in this draft:
https://tools.ietf.org/html/dr= aft-bjorklund-netmod-openconfig-reply-00


/martin

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

--089e011773730cd3c6051a3a8fb8-- From nobody Mon Jul 6 13:17:15 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 399BF1B31DA for ; Mon, 6 Jul 2015 13:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, 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 IDTvjJzRDZ21 for ; Mon, 6 Jul 2015 13:17:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 49FC21B31D0 for ; Mon, 6 Jul 2015 13:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1436213806; bh=6bJoS5U4X85d+Yq0PXPLsouSIcwzbzsA7FysmVD7D7Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=I6r5kYtF9wTL8nM8hdejX8LSIQU+PiPH5ICpV+2dlUjL9Z5EbbbILlJLewdiBWQgM 42FiiTsV2nh9Ef/1rGrl9Yt4Cv1qPyz/9T20FewnKHVP7Ii/ly0yvNL9c6ZUMaEStI 30zEjivwFo4ZDm2jSRYyNe0EYzjGhAt5CzKzmieU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=23.25.240.189; Content-Type: multipart/alternative; boundary=Apple-Mail-F601C358-7156-4268-BF63-9A5929A98A41 Mime-Version: 1.0 (1.0) From: thomas nadeau X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Mon, 6 Jul 2015 16:16:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7F874FC0-A288-4435-A87D-664249CB145B@lucidvision.com> References: <60B90693-54AC-468C-96AD-0908AEAD6538@lucidvision.com> <20150706.215923.809321918539432386.mbj@tail-f.com> To: Anees Shaikh X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=23.25.240.189 X-IP-stats: Notspam Incoming Last 0, First 0, in=1, out=0, spam=0 Known=true ip=23.25.240.189 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Open Config Options 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: Mon, 06 Jul 2015 20:17:14 -0000 --Apple-Mail-F601C358-7156-4268-BF63-9A5929A98A41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable fantastic! > On Jul 6, 2015, at 4:14 PM, Anees Shaikh wrote: >=20 > We've posted a new version of our draft: > https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >=20 > It includes a section on the issues that were raised and our observation/c= omment. It also adds a detailed section on terminology based on the interim= calls, and updates the operational requirements with further details. >=20 > thanks. > -- Anees >=20 >=20 >> On Mon, Jul 6, 2015 at 12:59 PM, Martin Bjorklund wrote:= >> Hi, >>=20 >> Nadeau Thomas wrote: >> > >> > One of the actions from the last Interim meeting was to have both= >> > sides of the issues around the open config approach to create at l= east >> > slides/textual bullet points for use during our discussion in Pra= ha so >> > we can come to a conclusion around the final issues. We need the= se >> > slides/bullet points to be listed on the list here and continue t= he >> > discussion here BEFORE the Praha meeting. I=E2=80=99d like to as= k Anees and >> > Rob to write up their side of the story. As I recall Juergen, Ke= nt, >> > Martin and Andy were the most vocal around the other side of thin= gs, >> > so I would like to ask them to write up their side of things. Ca= n you >> > all please confirm your acceptance of this action and a target fo= r >> > when you will post the issues? >>=20 >> We have posted our thoughts in this draft: >> https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 >>=20 >>=20 >> /martin >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail-F601C358-7156-4268-BF63-9A5929A98A41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
fantastic!



O= n Jul 6, 2015, at 4:14 PM, Anees Shaikh <aashaikh@google.com> wrote:

We've posted a new version of our draft:
=
It includes a section on the issues that were raised and our o= bservation/comment.  It also adds a detailed section on terminology bas= ed on the interim calls, and updates the operational requirements with furth= er details.

thanks.
-- Anees

On M= on, Jul 6, 2015 at 12:59 PM, Martin Bjorklund <mbj@tail-f.com> wrot= e:
Hi,

Nadeau Thomas <tnadeau@lucidvi= sion.com> wrote:
>
>       One of the actions from the last Interim meet= ing was to have both
>       sides of the issues around the open config ap= proach to create at least
>       slides/textual bullet points for use during o= ur discussion in Praha so
>       we can come to a conclusion around the final i= ssues.  We need these
>       slides/bullet points to be listed on the list= here and continue the
>       discussion here BEFORE the Praha meeting.&nbs= p; I=E2=80=99d like to ask Anees and
>       Rob to write up their side of the story. = ; As I recall Juergen, Kent,
>       Martin and Andy were the most vocal around th= e other side of things,
>       so I would like to ask them to write up their= side of things.  Can you
>       all please confirm your acceptance of this ac= tion and a target for
>       when you will post the issues?

We have posted our thoughts in this draft:
https://tools.ietf.org/html/draf= t-bjorklund-netmod-openconfig-reply-00


/martin

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

= --Apple-Mail-F601C358-7156-4268-BF63-9A5929A98A41-- From nobody Mon Jul 6 13:17:32 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 8D5601B31DF for ; Mon, 6 Jul 2015 13:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 pHiYWd_5nP9c for ; Mon, 6 Jul 2015 13:17:30 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 58D0C1B31D0 for ; Mon, 6 Jul 2015 13:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1436213824; bh=TTrC0TLa5Bsmh2X8WWNfq9A4mUIxKUUtv5x8oZCO++4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Ays3kJDxyMii/LvFU+/J3oVpxiO0Su+sQBEo3wtTyrbrURMiX/zFM6Buk4oyz2DJl GnqeYeR08urss0fxwa/GwdMZduuHKm92RmEa63RsynQWtngxq5WU0/vov/Gi+0ffkw wTdp8Yq6ToT1G6RAg5ZK6sckShY9faKu8K9jOEAA= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=23.25.240.189; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: thomas nadeau X-Mailer: iPhone Mail (12H143) In-Reply-To: <20150706.215923.809321918539432386.mbj@tail-f.com> Date: Mon, 6 Jul 2015 16:16:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <60B90693-54AC-468C-96AD-0908AEAD6538@lucidvision.com> <20150706.215923.809321918539432386.mbj@tail-f.com> To: Martin Bjorklund X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown ip=23.25.240.189 X-IP-stats: No info recorded yet ip=23.25.240.189 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Open Config Options 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: Mon, 06 Jul 2015 20:17:31 -0000 thats a good start. lets please discuss the merits and pros/cons vs the open= cconfig proposal. > On Jul 6, 2015, at 3:59 PM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Nadeau Thomas wrote: >>=20 >> One of the actions from the last Interim meeting was to have both >> sides of the issues around the open config approach to create at least= >> slides/textual bullet points for use during our discussion in Praha so= >> we can come to a conclusion around the final issues. We need these >> slides/bullet points to be listed on the list here and continue the >> discussion here BEFORE the Praha meeting. I=E2=80=99d like to ask Ane= es and >> Rob to write up their side of the story. As I recall Juergen, Kent, >> Martin and Andy were the most vocal around the other side of things, >> so I would like to ask them to write up their side of things. Can you= >> all please confirm your acceptance of this action and a target for >> when you will post the issues? >=20 > We have posted our thoughts in this draft: > https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00 >=20 >=20 > /martin >=20 From nobody Mon Jul 6 14:04: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 C27EB1B3269 for ; Mon, 6 Jul 2015 14:03:58 -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 gkTrKoEapRgj for ; Mon, 6 Jul 2015 14:03:56 -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 7F87B1B3250 for ; Mon, 6 Jul 2015 14:03:56 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-d4-559a85f878f6 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F9.8F.07675.8F58A955; Mon, 6 Jul 2015 15:43:20 +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; Mon, 6 Jul 2015 17:03:49 -0400 From: Scott Mansfield To: "netmod@ietf.org" Thread-Topic: UML to YANG mapping Thread-Index: AdC4KvK+SwHIuYyKSqSXUN3d0MIKyA== Date: Mon, 6 Jul 2015 21:03:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E245586439FCBCE7eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyuXSPt+6P1lmhBntm6lnMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE9PDjIWnNWs+HelmbWBcb9yFyMnh4SAicT5DTcYIWwxiQv3 1rN1MXJxCAkcZZS49v06M4SzDMj5+oIJpIoNqGPrrulgHSIC6hIzd4J0cHAIC8hIvJ3sDRFW lDj9oYEJJCwioCfx72ooSJhFQEVi34W1LCA2r4CvxJa5B8AmMgLt/X5qDZjNLCAucevJfCaI ewQkluw5zwxhi0q8fPyPFcJWkpi09BwrRH2+xNt9p5kgZgpKnJz5hGUCo9AsJKNmISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAgM+2MSbI47GBd8sjzE KMDBqMTDm2gxM1SINbGsuDL3EKM0B4uSOK+0X16okEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BkbmrRv5Du5ezfZ5W5LDCWGPcraml4tZXD+9Eb10yCu/2W8p/36prrSQVl9Pk+CZnkdel06R mv7tdHNoxUuPLZ+4q2aaX7qw+fDVHUlRjGYRN7/o6ylvKVke02PrLWNw/bdqiLHZaoWLGdcX 7f57K1u9va3/5M6Teen2NvMM7j6ffYylfXna7iAlluKMREMt5qLiRADdbeRoXAIAAA== Archived-At: Subject: [netmod] UML to YANG mapping 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: Mon, 06 Jul 2015 21:03:58 -0000 --_000_EF35EE4B92789843B1DECBC0E245586439FCBCE7eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Netmod! https://tools.ietf.org/html/draft-mansfield-netmod-uml-to-yang-00 has been = posted. This draft is attempting to open a discussion on how best to trans= late from a UML model to a YANG model. If you are interested in such thing= s, please take a look at the content, but please pay particular attention t= o where the draft is missing content. The authors would like to hear from = experts on how to interpret the various UML artefacts in order to help prov= ide guidelines on how to leverage UML as a part of a model-driven developme= nt lifecycle. A note about the format of the draft. I write using the "XML" template. T= here are .jpeg image files that are included in some artwork tags. I used = the rfc2629xslt tool to translate to HTML and then to PDF (so that the imag= e files are included). I then submitted the TXT, XML, and PDF (there is no= option upload the HTML in the submit tool). So, the only version of the d= raft that shows the image files is the PDF (because the HTML file was gener= ated from the TXT file). I know this isn't the group to discuss how to get= the formats to work out (I'll work on that), but I wanted the readers to k= now where to find the image files for this -00 draft. Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_EF35EE4B92789843B1DECBC0E245586439FCBCE7eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Netmod!

 

https://tools.ietf.org/html/draft-mansfield-netmo= d-uml-to-yang-00 has been posted.  This draft is attempting to ope= n a discussion on how best to translate from a UML model to a YANG model.  If you are interested in such things, p= lease take a look at the content, but please pay particular attention to wh= ere the draft is missing content.  The authors would like to hear from= experts on how to interpret the various UML artefacts in order to help provide guidelines on how to leverage UML as a = part of a model-driven development lifecycle.

 

A note about the format of the draft.  I write = using the “XML” template.  There are .jpeg image files tha= t are included in some artwork tags.  I used the rfc2629xslt tool to t= ranslate to HTML and then to PDF (so that the image files are included).  I then submitted the TXT, XML, and PDF (there is no optio= n upload the HTML in the submit tool).  So, the only version of the dr= aft that shows the image files is the PDF (because the HTML file was genera= ted from the TXT file).  I know this isn’t the group to discuss how to get the formats to work out (I’ll work o= n that), but I wanted the readers to know where to find the image files for= this -00 draft.

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 

--_000_EF35EE4B92789843B1DECBC0E245586439FCBCE7eusaamb105erics_-- From nobody Mon Jul 6 14:52:15 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 88CF41A1A17; Mon, 6 Jul 2015 14:52: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] 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 40zs3ubnKs2N; Mon, 6 Jul 2015 14:52:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF7C1A1A6A; Mon, 6 Jul 2015 14:52:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706215207.15767.51543.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:52:07 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:52:12 -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 : SYSLOG YANG model Author : Clyde Wildes Filename : draft-ietf-netmod-syslog-model-04.txt Pages : 21 Date : 2015-07-06 Abstract: This document describes a data model for Syslog protocol which is used to convey event notification messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 17:30: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 807BD1A8772 for ; Mon, 6 Jul 2015 17:30:50 -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 Y5kd6baIHtyg for ; Mon, 6 Jul 2015 17:30:49 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8291A8770 for ; Mon, 6 Jul 2015 17:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2412; q=dns/txt; s=iport; t=1436229049; x=1437438649; h=to:from:subject:message-id:date:mime-version; bh=vXMnLMDdXONZleyFSzfUGjzPhXaJJguRAquf5AHyg7I=; b=FnD2RCcPIKmBnS2BbGFWt6uFKkbx0dblg5bkRLIzLQDvYWD3uDXqCB6t iOBYGP9ktlGRvys0Ime2vINOAgqZsFyYW49Rw1YSmMJfJ9kfVcxLNYUuH u2JyCxu9ZZLF30Axt6Y6lUL6doD5tgKQlmO7TQZRuvkKCC9n/zD3RNBpl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CyBACdHJtV/xbLJq1ch2XEOgEBAQEBAYELhE11ARwUDQIRAkwNCAEBiCqkZI9flm8BAQgCAR+TQIFDBZQVi2iIPJAaJmODGjyCfAEBAQ X-IronPort-AV: E=Sophos;i="5.15,418,1432598400"; d="scan'208,217";a="550906079" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 07 Jul 2015 00:30:47 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t670Uk46011662 for ; Tue, 7 Jul 2015 00:30:46 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <559B1DB6.50404@cisco.com> Date: Tue, 7 Jul 2015 02:30:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000508040003070008040307" Archived-At: Subject: [netmod] Number of YANG models these days 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: Tue, 07 Jul 2015 00:30:50 -0000 This is a multi-part message in MIME format. --------------000508040003070008040307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Just after the IETF draft submission deadline today, here are the latest numbers: Number of correctly extracted YANG models from IETF drafts: 155 Number of YANG models in IETF drafts that passed compilation without warnings: 58/155 Number of YANG models in IETF drafts that passed compilation with warnings: 35/155 Number of all YANG models in IETF drafts (example, badly formatted, etc. ): 253 Happy to see that more and more YANG models compile without any errors/warnings. Recently (June 25th), the opendaylight shipped in first release: Lithium Number of YANG models in Hydrogen release: 117 Number of YANG models in Helium release: 220 Number of YANG models in Lithium release: 473 The numbers keep increasing. It should not be a surprise for anybody. Regards, Benoit --------------000508040003070008040307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Just after the IETF draft submission deadline today, here are the latest numbers:
Number of correctly extracted YANG models from IETF drafts: 155
Number of YANG models in IETF drafts that passed compilation without warnings: 58/155
Number of YANG models in IETF drafts that passed compilation with warnings: 35/155
Number of all YANG models in IETF drafts (example, badly formatted, etc. ): 253
Happy to see that more and more YANG models compile without any errors/warnings.

Recently (June 25th), the opendaylight shipped in first release: Lithium
Number of YANG models in Hydrogen release: 117
Number of YANG models in Helium release: 220
Number of YANG models in Lithium release: 473
The numbers keep increasing. It should not be a surprise for anybody.

Regards, Benoit
--------------000508040003070008040307-- From nobody Tue Jul 7 00:53:49 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 8CEA41A1A99; Tue, 7 Jul 2015 00:53: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 8FihF3MqwaQS; Tue, 7 Jul 2015 00:53: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 E01481A1A39; Tue, 7 Jul 2015 00:53:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 366AA11D9; Tue, 7 Jul 2015 09:53: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 X72HxByleUe7; Tue, 7 Jul 2015 09:53:38 +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, 7 Jul 2015 09:53:38 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46C7020013; Tue, 7 Jul 2015 09:53:39 +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 UgwxNbTJMLzi; Tue, 7 Jul 2015 09:53: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 669E92002C; Tue, 7 Jul 2015 09:53:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3A25734EFCA8; Tue, 7 Jul 2015 09:53:33 +0200 (CEST) Date: Tue, 7 Jul 2015 09:53:32 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150707075330.GA1656@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20150703.224527.1947263992217736555.mbj@tail-f.com> <20150706065755.GA6056@elstar.local> <20150706074558.GA6272@elstar.local> <20150706150430.GA342@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] Y45-04 and ietf-yang-library 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: Tue, 07 Jul 2015 07:53:48 -0000 On Mon, Jul 06, 2015 at 08:16:32AM -0700, Andy Bierman wrote: > > > If the import of C really depends on specific revisions of > > > some typedefs, groupings, etc. then import by revision MUST > > > be used everywhere in the dependency chain (C and all its imports). > > > > > > If no revision-stmt is present the server can pick whatever revision > > > it wants. If this is a problem, then fix this problem, don't add > > > some complex monitoring requirements for servers to implement > > > and clients to process. Let's make import-by-revision mandatory > > > if import-without-revision is a such a problem. > > > > If the data model leaves it open, then indeed the implementor can > > choose. What is wrong with reporting what was chosen? > > > > If there is just a leaf that says 'default-revision=true' > like I proposed, then no problem. But this assumes that there is a single revision that has been used by all imports. Are we sure this will be true for all implementations? Benoit just posted some numbers - OpenDaylight Lithim shipped with 473 YANG modules, about 155 YANG modules that can be extracted in I-Ds for the upcoming IETF, and other SDOs are on their way as well to produce YANG modules. If I assume that products will in a couple of years implement hundreds of YANG modules, do we believe that imports without revision can all be kept at a specific revision throughout the whole system? > If I have to reproduce the entire imports/include->imports tree with > filled in revision dates, then this is overkill, too much > memory/data, and it is a problem. It seems to be a trade-off. If a vendor manages to manage his software very well, then 'default-revision=true' may do its job. If not, then we have no standard way to find out what was actually implemented. So we have the following scenarios: a) Import by revision de-factor disappears. Problem disappears. b) Import by revision does not disappear. 1) Vendor manages to keeps all modules aligned to a single revision, then 'default-revision=true' works. 2) Vendor does not manage to keep all modules aligned to a single revision (btw, this can also be forced on the vendor by modules from differnet SDOs), then we apparently need additional complexity to report what precisely was implemented. One option out could be to strongly recommend a), to provide the 'default-revision=true' possibility, to provide b.2) as a feature for systems where 'default-revision=true' 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 From nobody Tue Jul 7 02:43:31 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 11B611A87A4 for ; Tue, 7 Jul 2015 02:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 q6Zj3cZEHcQ9 for ; Tue, 7 Jul 2015 02:43:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 49A911A877F for ; Tue, 7 Jul 2015 02:43:28 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 58EFC1CC0286; Tue, 7 Jul 2015 11:43:35 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150704080945.GA2182@elstar.local> References: <20150630143959.GB5803@elstar.local> <20150701072114.GA8001@elstar.local> <7AE5C6C9-D7C8-48E8-9097-A5CE416884A2@nic.cz> <20150701123313.GA8880@elstar.local> <70B4070E-B655-4864-A4F6-FD79FD49577C@nic.cz> <20150704080945.GA2182@elstar.local> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Jul 2015 11:43:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29) 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: Tue, 07 Jul 2015 09:43:31 -0000 Juergen Schoenwaelder writes: > On Sat, Jul 04, 2015 at 08:32:04AM +0200, Ladislav Lhotka wrote: >>=20 >> >=20=20 >> > Consider this definition: >> >=20 >> > rpc foo { >> > input { >> > leaf x { >> > type uint8; >> > must ". =3D ../y"; >> > } >> > leaf y { >> > type string; >> > } >> > } >> > } >> >=20 >> > Then what's the result of conceptual XPath evaluation for this RPC >> > request? >> >=20 >> > Just because you can construct a pathological >> > case comparing strings and numbers doesn't >> > mean anything. >>=20 >> Pathological?? Don=E2=80=99t forget that uint64 numbers are encoded as s= trings in JSON. Moreover, comparisons of two nodesets are *always* performe= d on string values, even if both have numeric types in YANG. >>=20 >> >=20 >> > Use "number(foo) < number(bar)" to ensure that >> > numeric comparisons are done correctly. >> >=20 > > If this +1 !=3D "1" needs fixing, I think it needs fixing in the YANG > specification. For datastores, things are kind of handled since RFC Yes. > 6020 says: > > Note that since all leaf values in the data tree are conceptually > stored in their canonical form (see Sections 7.6 and 7.7), any XPath > comparisons are done on the canonical value. Yes. > > For notifications, this is kind of handled as well: > > When a NETCONF server sends data, it MUST be in the canonical form. > > And of course, we expect the server to only send notifcations that are > valid anyway. > > For RPCs, the obvious things to do would be to require that XPATH > evaluation of RPC arguments also takes place on the canonical > representation of values. Agreed, perhaps the following change in sec. 6.4.1 could be sufficient: OLD: In the accessible tree, all leafs and leaf-lists with default values in use exist (See Section 7.6.1 and Section 7.7.2). NEW: In the accessible tree, all leafs and leaf-lists with default values in use exist (See Section 7.6.1 and Section 7.7.2), and all leaf and leaf-list values are conceptually in the canoonical form. Lada > > /js > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 7 04:53: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 7D7061ABD3C for ; Tue, 7 Jul 2015 04:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WANT=2.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 jE1v2sGq941B for ; Tue, 7 Jul 2015 04:53:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 387281AC39F for ; Tue, 7 Jul 2015 04:53:38 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 505651CC0286; Tue, 7 Jul 2015 13:53:46 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Jul 2015 13:53:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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: Tue, 07 Jul 2015 11:53:41 -0000 Kent Watsen writes: >>>>Maybe I don't understand your response, but if we agree that annotations >>> are a server-level thing (not module-specific), then I do not agree >>>that a >>> module's description should be able to say that an annotation should be >>> ignored in other modules. >>> >> >>It depends on the annotation's semantics, and it may be designed to do >>something only for certain node instances (such as leafs with union >>type), or for nodes in a given namespace etc. Do you think it may be a >>problem? > > Those kinds of uses are fine, as they are not module-specific. I just > want to ensure we don't ever wind up with module-specific > annotations.... A single namespace is essentially the same as a single module, isn't it? But don't get mw wrong, syntactically annotations would be allowed everywhere although in some places they may be a no-op. > > > >>> I see, but then this make the example misleading. I thought it was >>>trying >>> to show how to place an annotation on the list as a whole. I see now >>> it says "list instance", but this seems uninteresting example, as list >> >>I will use "list entry" because the term "instance" in not defined in >>YANG. >> >>> instances are just nodes for which how to apply annotations is already >>> known - there's nothing special about the node being a list element - >>> right? >> >>Do you suggest to remove the second example in that section? But you >>also wanted to add an example on "anydata" that is arguable even more >>alike to a container. > > Yes, an example for each item discussed (including anydata) is desired. > What I'm questioning here is why we need to discuss annotating list > entries at all, since they seem to follow normal rules. If true, I > recommend removing a special section for list entries/instances entirely. > I don't understand. There is no special section for list entries/instances, this is included in the section 4.2.2 (Adding Annotations to Anydata, Container and List Instances). I agree an example should be included for each data node type, i.e. container, list and anydata. As for the list example, I think it is also important to show that some entries may be decorated with annotations while other aren't. > > >>>>An annotation cannot be attached to a list as a whole? - that seems >>> fundamentally broken, though I understand why you say it cannot be >>>easily >>> represented in XML (via attributes). Should we consider alternative >>> representations? >> >>I agree it might be useful, and I was thinking about it but I haven't >>found any good way for encoding it in XML, also because in XML list >>entries can be interspersed with other elements. > > Interspersed with other elements? - I don't understand. For instance, > assuming: > > container foobars { > list foo { > ... > } > list bar { > } > } > > The XML would be: > > > ... > > ... > > ... > > ... > > > ... > > ... > > > > Where is the interspersion? This is also valid, see sec. 7.7.6 in RFC 6020: ... ... ... ... ... ... > > As for how to place annotations on an XML list as a whole, I was thinking > we could use a fake first element. For instance, the following shows an > annotation on the "bar" list: > > > ... > ... > ... > // colors entire list "red" (notice empty > element) > ... > ... > ... > > > > But this is most likely illegal since it's not a valid instance > document. This would mess up all standard XML tools. > So then maybe we could use an XML comment like this: > > > ... > ... > ... > > ... > ... > ... > > A processing instruction would be slightly better but yes, it's ugly. > > Ugh, this isn't great either. Anybody else have an idea? > > > >>>That said, if unavoidable, the draft needs to call that out as a >>> limitation somewhere, because it wan't clear to me. Are there other >>> limitations that are not also not being called out? >> >>Well, one could e.g. think about structured annotations but this is >>again not exactly easy with XML attributes. I don't think though we can >>really call it limitations - after all, the motivation for this document >>was to "officialize" the use of XML attributes, so it would be a bit >>weird to to make it incompatible with them. > > True, I'd rather we can find a solution for annotating XML lists. Until > then, the draft SHOULD explicitly call it out as not supported. Maybe > put in into an OPEN ISSUES section? But that means XML clients would be unable to receive some information. Is it what we want? Lada > > > Thanks, > Kent (as a contributor) > > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 7 07:20:42 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 4BBF01AC3F7 for ; Tue, 7 Jul 2015 07:20:40 -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 7xkr5qx0qvJW for ; Tue, 7 Jul 2015 07:20:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9A1AC3EF for ; Tue, 7 Jul 2015 07:20:37 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id ABC3B1CC0286; Tue, 7 Jul 2015 16:20:45 +0200 (CEST) From: Ladislav Lhotka To: Jernej Tuljak , NETMOD Working Group In-Reply-To: <5596429B.7090608@mg-soft.si> References: <5596429B.7090608@mg-soft.si> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Jul 2015 16:20:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang:xpath1.0 values and JSON encoding 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: Tue, 07 Jul 2015 14:20:40 -0000 Jernej Tuljak writes: > Hi, > > since draft-ietf-netmod-yang-json-04 describes a special mapping for > instance-identifiers, I'm wondering about how to handle values which are > constrained using the standard XML specific yang:xpath1.0 type or a > derivative of it. I assume the same or similar rules should apply to any > XPath expression that appears in a JSON instance, right? Perhaps this > deserves mention in the I-D? >From the definition of the xpath1.0 type it seems clear that values of this type must be "real" XPath expressions as specified in [XPATH]. The necessary context info (including prefix bindings) has to be provided in the description of the data node that uses this type. So this is OK even if xpath1.0 values appear in JSON. Instance-identifiers need a different approach because their context is defined through "XML namespace scope" that is absent in JSON. Lada > > Jernej > > _______________________________________________ > 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 Jul 7 09:48:28 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 417581ACE87 for ; Tue, 7 Jul 2015 09:48:27 -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 75xvZilDs6AQ for ; Tue, 7 Jul 2015 09:48:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CC81ACE7F for ; Tue, 7 Jul 2015 09:48:25 -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.207.19; Tue, 7 Jul 2015 16:48:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.103]) with mapi id 15.01.0207.004; Tue, 7 Jul 2015 16:48:20 +0000 From: Kent Watsen To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) Thread-Index: AQHQs3aEh3sCPrCqSkegq1SWU9kekZ3GR8OAgAA8lgCAAYk0AIAAGDUAgAfKbQCAAA9HgA== Date: Tue, 7 Jul 2015 16:48:20 +0000 Message-ID: References: In-Reply-To: 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: nic.cz; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:0wdKeEPyexcmwPWNPxf9JrmTg86DDe6oKxZMQpe7s/GHtvYJcRCdnPLsCT/SMaFNPqA62h2TmKkkxZEGfrDSfoe24CEakF0hptZxAuEPOWPZi8xo6Z14feP+uNHASm3xF8UDyo3EDEKgPJ2B2obJzQ==; 24:/6nj7FYUFYrh8q968vCfUNfpxkW1mUC9T6AnDPU+otwpVclELqYJC89LN9bJzdYopBS/dN4tPGYDIqTQ3d1qvWOvFMps6S19nlPC5uVR1U4=; 20:HfQYlFayOYlosLOVlRVraYpFECDIZR9f6OE9dVJiUP8vBYNGA0k2oy0pdSYbUUJrAWXS5dx2ESapotOBY1K1uQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5423002)(51704005)(164054003)(36756003)(54356999)(189998001)(76176999)(4001350100001)(2501003)(5001960100002)(5002640100001)(2950100001)(2656002)(50986999)(92566002)(102836002)(86362001)(5001770100001)(83506001)(66066001)(107886002)(2900100001)(62966003)(93886004)(77156002)(40100003)(87936001)(99286002)(122556002)(230783001)(106116001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 16:48:20.0632 (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: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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: Tue, 07 Jul 2015 16:48:27 -0000 >But don't get mw wrong, syntactically annotations would be allowed >everywhere although in some places they may be a no-op. OK >This is also valid, see sec. 7.7.6 in RFC 6020: I see, thanks. >>True, I'd rather we can find a solution for annotating XML lists. Until >> then, the draft SHOULD explicitly call it out as not supported. Maybe >> put in into an OPEN ISSUES section? > >But that means XML clients would be unable to receive some >information. Is it what we want? I agree that is not what we want. Do you have any ideas other than using a processing instruction inside an XML comment? Thanks, Kent (as a contributor) From nobody Wed Jul 8 09:11: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 C79361A01AE for ; Wed, 8 Jul 2015 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 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_210=0.6, J_CHICKENPOX_24=0.6, 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 VSlGzEY7_iN8 for ; Wed, 8 Jul 2015 09:11:16 -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 9CB8F1A01F9 for ; Wed, 8 Jul 2015 09:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1264; q=dns/txt; s=iport; t=1436371875; x=1437581475; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=yEGizv34L0HVD+JeHSqB3LvSBgzodTFt5wvIp+OYHgc=; b=OhGTefre9UCbtZ5BpoBtosu0GNzlvOxqpMpHK6c0OJMwo0RcV2GYt0Xc 8GgUjsQkFCpU2eWrladQzYB20G0DBLIZA7mn2NByNeUcPsCHNcfktPfM2 zPgoD1pTZwe7JW4YmgzlWTRo7LV+gUQDEnk1YDe9fKQwWcdK34coQO4ZB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C3BABrSp1V/xbLJq1cg2aEALwniB0BAQEBAQGBC4RNFS9HAgUhAhECWQgBAYgqDadDj1+WPCgEgSGPTYJSgUMFlCOEZ4cXiECQIiZjgxk9gnwBAQE X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="554603796" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2015 16:11:13 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t68GBD0M003348 for ; Wed, 8 Jul 2015 16:11:13 GMT Message-ID: <559D4BA1.30605@cisco.com> Date: Wed, 08 Jul 2015 17:11:13 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Interface Extensions YANG draft 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, 08 Jul 2015 16:11:18 -0000 Hi, I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices. E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses. I am hoping that this draft could be adopted and standardized by the netmod WG. https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ Any comments or feedback is appreciated. Potential points of interest/discussion may be: - Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented? - We've tried to restrict the leaves to just the interface types (using when if:type = ...) that the configuration applies to rather than adding them to all interfaces. Feedback would be welcome on whether this approach is a good idea/maintainable. - For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not. Is this a reasonable approach? Thanks, Rob From nobody Fri Jul 10 00:32:54 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 D3E111A0203 for ; Thu, 9 Jul 2015 14:00:10 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8FrZe6R4Uhv for ; Thu, 9 Jul 2015 14:00:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7511A0174 for ; Thu, 9 Jul 2015 14:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5310; q=dns/txt; s=iport; t=1436475609; x=1437685209; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ad5I4CjCrRQwmryFQf9vUDOcb+WuCVvt4naTe5yh4/Y=; b=gMKGWgrmeSxYNR5onr97ZDhTeIK09KcNxmCqeJJsLesp9OzAmAaf+QZJ yNiDhti7ZGe6j7rufR65N07Dj8lBdyrABjPddKxL+cP+3FIx8mULCIwXW 4Yt9AMumGD6u2BLzSrC7SmhV3BqDSw8b4Lb2aHvGuL2mmOQGvc3OgyW6/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DRAwD5355V/4QNJK1bgxJUYAaDGrgHCYFzhXUCHIFFOBQBAQEBAQEBgQqEIwEBAQQjEUUMBAIBCBEEAQEDAgYDGgMCAgIwFAEICAEBBA4FCIgmDbkhljYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKKoQtAQ0aMQcGgmIvgRQFjCqIAwGEZocagTxFg1OLBogMJoIMHIFTbwGBAwEfAyCBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,442,1432598400"; d="scan'208";a="8467786" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 09 Jul 2015 20:59:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t69KxrDi020531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Jul 2015 20:59:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.208]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 15:59:53 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: New version for draft-clemm-netconf-yang-push-01.txt Thread-Index: AdC5FyP9Rm6uBgErR8+WZ2t4USQNKABbyl6Q Date: Thu, 9 Jul 2015 20:59:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 10 Jul 2015 00:32:52 -0700 Subject: Re: [netmod] New version for draft-clemm-netconf-yang-push-01.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, 09 Jul 2015 21:00:11 -0000 QWRkaW5nIHRvIHdoYXQgQWxleCBzYWlkLCBoZXJlIGFyZSBhIGZldyBxdWVzdGlvbnMgbGVmdCB1 bmRlZmluZWQgaW4gdGhlIGxhdGVzdCBkcmFmdCB3aGljaCBhcmUgd29ydGggZXhwbG9yaW5nIGVp dGhlciBvbiB0aGUgTkVUQ09ORiBtYWlsZXIgb3IgaW4gUHJhZ3VlLi4uDQoNCigxKSBTaG91bGQg dGhpcyBkcmFmdCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvIHN1c3BlbmQgLyByZXN1bWUgYSBTdWJz Y3JpcHRpb24gYXQgdGhlIHJlcXVlc3Qgb2YgdGhlIFN1YnNjcmliZXI/DQoNCigyKSBTaG91bGQg dGhlIGxvc3Mgb2YgYXV0aGVudGljYXRlZCBhY2Nlc3MgdG8gWUFORyBzdWJ0cmVlIGJlIGNvbW11 bmljYXRlZCB0byB0aGUgU3Vic2NyaWJlcj8NCg0KKDMpIEFyZSB0aGVyZSBmaWx0ZXJzIHdoaWNo IHNob3VsZCBiZSBwcm92aWRlZCBiZXlvbmQgUkZDIDUyNzcgU3VidHJlZSBhbmQgUHJvcGVydHkg RmlsdGVycz8NCg0KVGhvdWdodHMgb24gdGhlc2UsIG9yIG90aGVyIHN1Z2dlc3Rpb25zL3F1ZXN0 aW9ucyBvbiB0aGUgZHJhZnQgYXJlIGFwcHJlY2lhdGVkLg0KDQotIEVyaWMgKGFsc28gb24gYmVo YWxmIG9mIEFsZXggYW5kIEFsYmVydG8pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIA0KU2VudDogVHVlc2RheSwgSnVseSAwNywgMjAx NSA4OjQ2IFBNDQpUbzogbmV0Y29uZkBpZXRmLm9yZw0KQ2M6IEVyaWMgVm9pdCAoZXZvaXQpOyBB bGJlcnRvIEdvbnphbGV6IFByaWV0byAoYWxiZXJ0Z28pDQpTdWJqZWN0OiBOZXcgdmVyc2lvbiBm b3IgZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2gtMDEudHh0DQoNCkhpLA0KDQp3ZSBqdXN0 IHdhbnRlZCB0byBsZXQgeW91IGtub3cgdGhhdCB3ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0 aGUgWUFORyBkYXRhc3RvcmUgcHVzaCBkcmFmdCB5ZXN0ZXJkYXksIHdoaWNoIHdlIGFyZSBwbGFu bmluZyB0byBwcmVzZW50IGluIFByYWd1ZS4gIA0KDQpQbGVhc2Ugc2VlIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaC0wMS50 eHQgDQoNClRoZXJlIGFyZSBhIGEgZmV3IHRlY2huaWNhbCB1cGRhdGVzLCBhcyB3ZWxsIGFzIHF1 aXRlIGEgZmV3IGVkaXRvcmlhbCB1cGRhdGVzLiAgDQoNClRoZSB0ZWNobmljYWwgdXBkYXRlcyBp bmNsdWRlOg0KLSBBIHBhcmFtZXRlciB0aGF0IGFsbG93cyBhIHN1YnNjcmliZXIgdG8gc3BlY2lm eSB3aGljaCBlbmNvZGluZyB0byB1c2UgZm9yIGRhdGFzdG9yZSB1cGRhdGVzDQotIEEgcGFyYW1l dGVyIHRoYXQgYWxsb3dzIGEgc3Vic2NyaWJlciB0byBsaW1pdCBvbi1jaGFuZ2Ugc3Vic2NyaXB0 aW9ucyB0byBjZXJ0YWluIHR5cGVzIG9mIGNoYW5nZXMNCg0KVGhlcmUgYXJlIGEgZmV3IGl0ZW1z IHRoYXQgbWF5IHdhcnJhbnQgZGlzY3Vzc2lvbiwgbW9zdCBvZiB3aGljaCBjYW4gYmUgZm91bmQg aW4gc2VjdGlvbiAzLjEwLCBpbmNsdWRpbmc6DQotIEludHJvZHVjdGlvbiBvZiBhZGRpdGlvbmFs IGJ1aWx0LWluIGRhdGFzdHJlYW1zIGxpbWl0ZWQgdG8gb3BlcmF0aW9uYWwgZGF0YSAoc2VjdGlv biAzLjEwLjUpLCB3aGljaCB3ZSB0aGluayB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBmb3JtYWxs eSBpbmNsdWRlIGluIHRoZSBuZXh0IHJldmlzaW9uDQotIFdoZXRoZXIgdG8gc3VwcG9ydCBzdWJz Y3JpcHRpb24gcGVyc2lzdGVuY3kgKGN1cnJlbnRseSB0aGUgc3Vic2NyaXB0aW9uIGxpZmVjeWNs ZSBpcyB0aWVkIHRvIHRoZSBsaWZlY3ljbGUgb2YgYSBOZXRjb25mIHNlc3Npb24pDQotIFdoZXRo ZXIgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiAiY2h1bmtpbmciIG9mIHVwZGF0ZXMgKGN1cnJlbnRs eSBsZWZ0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRvIHNlbmQgYSBzaW5nbGUgdXBk YXRlIG1lc3NhZ2Ugd2l0aCB0aGUgZW50aXJlIGRhdGEsIG9yIG11bHRpcGxlIHVwZGF0ZSBtZXNz YWdlcyBlYWNoIHdpdGggYSBzdWJzZXQgb2YgdGhlIGRhdGEpDQotIFdoZXRoZXIgdG8gdHJhY2sg dGhlICJvd25lcnMiIG9mIGEgc3Vic2NyaXB0aW9uIGFzIHBhcnQgb2YgdGhlIHN1YnNjcmlwdGlv biBkYXRhIG1vZGVsIChhZ2Fpbiwgd2UgYmVsaWV2ZSB0aGlzIGlzIGEgZ29vZCBpZGVhIHdoaWNo IHdlIHBsYW4gdG8gYWRkIGluIHRoZSBuZXh0IHJldmlzaW9uKSANCg0KUmVnYXJkcw0KLS0tIEFs ZXggKGFsc28gb24gYmVoYWxmIG9mIEVyaWMgYW5kIEFsYmVydG8pDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDA2LCAyMDE1IDM6NTcg UE0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBBbGJlcnRvIEdvbnphbGV6IFByaWV0byAo YWxiZXJ0Z28pOyBBbGJlcnRvIEdvbnphbGV6IFByaWV0byAoYWxiZXJ0Z28pOyBFcmljIFZvaXQg KGV2b2l0KTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgRXJpYyBWb2l0IChldm9pdCkNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5n LXB1c2gtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNsZW1tLW5ldGNv bmYteWFuZy1wdXNoLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBB bGV4YW5kZXIgQ2xlbW0gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2gNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlT dWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMNCkRvY3VtZW50IGRhdGU6 CTIwMTUtMDctMDYNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTMyDQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jbGVtbS1u ZXRjb25mLXlhbmctcHVzaC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaC0wMQ0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHN1YnNjcmlwdGlvbiBhbmQgcHVzaCBtZWNo YW5pc20gZm9yIFlBTkcNCiAgIGRhdGFzdG9yZXMuICBUaGlzIG1lY2hhbmlzbSBhbGxvd3MgY2xp ZW50IGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0DQogICB1cGRhdGVzIGZyb20gYSBZQU5HIGRhdGFz dG9yZSwgd2hpY2ggYXJlIHRoZW4gcHVzaGVkIGJ5IHRoZSBzZXJ2ZXIgdG8NCiAgIHRoZSBjbGll bnQgcGVyIGEgc3Vic2NyaXB0aW9uIHBvbGljeSwgd2l0aG91dCByZXF1aXJpbmcgYWRkaXRpb25h bA0KICAgY2xpZW50IHJlcXVlc3RzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Fri Jul 10 07:54:50 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 BBE951B2CA6 for ; Fri, 10 Jul 2015 07:54:44 -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 lm_TVsmw5WyM for ; Fri, 10 Jul 2015 07:54:41 -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 EB6591B2C93 for ; Fri, 10 Jul 2015 07:54:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYP69779; Fri, 10 Jul 2015 14:54:39 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 15:54:34 +0100 From: Italo Busi To: "netmod@ietf.org" Thread-Topic: Comments on draft-mansfield-uml-to-yang-00 Thread-Index: AdC7IFQIwGLJvQHoTLSoVx6sNWl0IQ== Date: Fri, 10 Jul 2015 14:54:34 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B0111A421@lhreml504-mbs> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.144.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Comments on draft-mansfield-uml-to-yang-00 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: Fri, 10 Jul 2015 14:54:44 -0000 Dear authors of draft-mansfield-uml-to-yang, I think this draft is very useful in assisting translation between UML IMs = and Yang DMs. Since many UML IMs have been already defined, this I-D would = help in simplifying development and/or gap analysis of new Yang DMs. It also complements the work on the suite of translation drafts developed o= r under development in the NETMOD WG (e.g., RFC 6643 and draft-ietf-netmod-= yang-json). I have started to read the draft and have got an initial set of comments I = would like to share (further comments may follow while I continue reviewing= the draft). Appendix A is very helpful to see how the different mapping rules work. It = would be worth enhancing it with some further detailed descriptions also re= ferencing the YANG Module and not only the YANG tree of draft-dharini-netmo= d-g-698-2-yang-04. It seems that section 5 of this I-D is describing the mapping between the U= ML artifacts defined in section 5 of TR-514. It would be worth adding some = text to clarify this point. It seems that section 5.1 of this I-D is describing how the Object Class UM= L artifact described in section 5.1 of TR-514 is mapped into YANG statement= s. In particular, an Object Class UML artifact can be mapped either to a "list= " or to a "container" YANG statement. The I-D does not describe when (i.e.,= under which condition) a "list" or a "container" statement should be used.= Are both approaches equivalent or is there a criteria for using one or oth= er approach depending on some characteristics of the Object Class? Looking YANG module in the appendix A example (draft-dharini-netmod-g-698-2= -yang-04), it seems that the superclass property of an Object Class artifac= t is not explicitly defined but it is inferred from the structure of the "a= ugment" and "container" statements: augment "/if:interfaces/if:interface" { description "Parameters for an optical interface"; container optIfOChRsSs { description "RsSs path configuration for an interface"; <...> } Looking at this example, it is also worth noting that the documentation pro= perty of the optIfOChRsSs Object Class maps to the "description" substateme= nt below the "container optIfOChRsSs" statement (i.e., description "RsSs pa= th configuration for an interface";). The other description statement (i.e.= , description "Parameters for an optical interface";) is mapping the docume= ntation property of the inheritance relationship. It would be worth updating Section 5.4 to describe how the properties of th= e Association UML artifacts maps into substatements of the YANG statements = as well as updating appendix A to describe the example above. Is it possible to map into YANG an UML Object Class that inherits from more= than one superclass? Just a nit: I think that reference [7] is not an OMG document Thanks, Italo From nobody Mon Jul 13 01:43:06 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 34F201AD49F for ; Mon, 13 Jul 2015 01:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.877 X-Spam-Level: ** X-Spam-Status: No, score=2.877 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CN_BODY_35=0.339, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, 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 Wstob4iGnoWa for ; Mon, 13 Jul 2015 01:43:04 -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 B83001AD49D for ; Mon, 13 Jul 2015 01:43:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYR62429; Mon, 13 Jul 2015 08:43:02 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jul 2015 09:43:01 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.165]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0158.001; Mon, 13 Jul 2015 16:42:24 +0800 From: wangzitao To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] Interface Extensions YANG draft Thread-Index: AQHQuZjCtVrBUkcxvEOF9mfvFyjSs53ZHDnQ Date: Mon, 13 Jul 2015 08:42:24 +0000 Message-ID: References: <559D4BA1.30605@cisco.com> In-Reply-To: <559D4BA1.30605@cisco.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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: Mon, 13 Jul 2015 08:43:05 -0000 RGVhciBBdXRob3JzLA0KDQpJJ3ZlIHJlYWQgeW91ciBkcmFmdC13aWx0b24tbmV0bW9kLWludGYt ZXh0LXlhbmctMDAgYW5kIGhhdmUgYSBxdWVzdGlvbjogDQpXaGF0IGlzIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gZW5jYXBzLXR5cGUgaW4geW91ciB5YW5nIG1vZGVsIGFuZCBpbnRlcmZhY2UgdHlw ZXMgaW4gUkZDNzIyND8NCg0KSSBhbHNvIHJlYWQgeW91ciBkcmFmdC13aWx0b24tbmV0bW9kLWlu dGYtdmxhbi15YW5nd2hpY2ggYXVnbWVudCB0aGUgaWYtY21uIGFzOg0KDQogYXVnbWVudCAvaWY6 aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UvaWYtY21uOmVuY2Fwc3VsYXRpb24vDQogaWYtY21uOmVu Y2Fwcy10eXBlOg0KICAgICAgKy0tOih2bGFuKQ0KICAgICAgICAgKy0tcncgdmxhbg0KICAgICAg ICAgICAgKy0tcncgdGFncw0KICAgICAgICAgICAgLi4uLi4uDQogIA0KICBCdXQgdGhlIHZsYW4g dHlwZSBoYXZlIGFscmVhZHkgZGVmaW5lZCBpbiB0aGUgUkZDNzIyNDoNCg0KICAgICBpZGVudGl0 eSBsMnZsYW4gew0KICAgICAgIGJhc2UgaWFuYS1pbnRlcmZhY2UtdHlwZTsNCiAgICAgICBkZXNj cmlwdGlvbg0KICAgICAgICAgIkxheWVyIDIgVmlydHVhbCBMQU4gdXNpbmcgODAyLjFRLiI7DQog ICAgIH0NCiAgICAgaWRlbnRpdHkgbDNpcHZsYW4gew0KICAgICAgIGJhc2UgaWFuYS1pbnRlcmZh Y2UtdHlwZTsNCiAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgIkxheWVyIDMgVmlydHVhbCBM QU4gdXNpbmcgSVAuIjsNCiAgICAgfQ0KICAgICBpZGVudGl0eSBsM2lweHZsYW4gew0KICAgICAg IGJhc2UgaWFuYS1pbnRlcmZhY2UtdHlwZTsNCiAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAg IkxheWVyIDMgVmlydHVhbCBMQU4gdXNpbmcgSVBYLiI7DQogICAgIH0NCiAgDQogIFdoeSBub3Qg cmV1c2UgdGhlIHZsYW4gdHlwZXMgZGVmaW5kaW5nIGluIFJGQzcyMjQ/IEFuZCBpdCBtYXkgc2lt cGxpZnkgdGhlIGF1Z21lbnQgdGFyZ2V0IHBhdGggc3VjaCBhczoNCg0KICAgIGF1Z21lbnQgL2lm OmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0KICAgICAgICAgKy0tcncgZW5jYXBzLXR5cGUgICBp ZGVudGl0eXJlZg0KICAgICAgICAgKy0tcncgdmxhbg0KICAgICAgICAgICAgKy0tcncgdGFncw0K ICAgICAgICAgICAgLi4uLi4uDQoNCkJlc3QgUmVnYXJkcyENCi1NaWNoYWVsDQoNCi0tLS0t08q8 /tStvP4tLS0tLQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBSb2JlcnQgV2lsdG9uDQq3osvNyrG85DogMjAxNcTqN9TCOcjVIDA6MTENCsrVvP7I yzogbmV0bW9kQGlldGYub3JnDQrW98ziOiBbbmV0bW9kXSBJbnRlcmZhY2UgRXh0ZW5zaW9ucyBZ QU5HIGRyYWZ0DQoNCkhpLA0KDQpJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGZvciBwcm92 aWRlcyBzZXZlcmFsIGF1Z21lbnRhdGlvbnMgdG8gdGhlIGlldGYgaWY6aW50ZXJmYWNlcyB0byBk ZWZpbmUgY29uZmlndXJhdGlvbiBZQU5HIGZvciBiYXNpYyBpbnRlcmZhY2UgcGFyYW1ldGVycyB0 aGF0IGFyZSBjb21tb25seSBzdXBwb3J0ZWQgb24gbmV0d29yayBkZXZpY2VzLiAgRS5nLiBpdCBp cyBpbmNsdWRlcyBsZWF2ZXMgc3VjaCBhcyBiYW5kd2lkdGgsIGNhcnJpZXIgZGVsYXksIGRhbXBl bmluZywgbG9vcGJhY2ssIG10dSwgJiBzdWItaW50ZXJmYWNlIHBhcmVudCByZWYsIGFuZCBjb25m aWd1cmFibGUgaW50ZXJmYWNlIE1BQyBhZGRyZXNzZXMuICBJIGFtIGhvcGluZyB0aGF0IHRoaXMg ZHJhZnQgY291bGQgYmUgYWRvcHRlZCBhbmQgc3RhbmRhcmRpemVkIGJ5IHRoZSBuZXRtb2QgV0cu DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbHRvbi1uZXRtb2Qt aW50Zi1leHQteWFuZy8NCg0KQW55IGNvbW1lbnRzIG9yIGZlZWRiYWNrIGlzIGFwcHJlY2lhdGVk Lg0KDQpQb3RlbnRpYWwgcG9pbnRzIG9mIGludGVyZXN0L2Rpc2N1c3Npb24gbWF5IGJlOg0KICAt IElzIGl0IGFjY2VwdGFibGUgdG8gZGVmaW5lIHN0YW5kYXJkIFlBTkcgZm9yIGZlYXR1cmVzIHRo YXQgYXJlIG5vdCBiYWNrZWQgYnkgYW55IGZvcm1hbCBzdGFuZGFyZCBpZiB0aGV5IGFyZSBjb21t b25seSBpbXBsZW1lbnRlZD8NCiAgLSBXZSd2ZSB0cmllZCB0byByZXN0cmljdCB0aGUgbGVhdmVz IHRvIGp1c3QgdGhlIGludGVyZmFjZSB0eXBlcyAodXNpbmcgd2hlbiBpZjp0eXBlID0gLi4uKSB0 aGF0IHRoZSBjb25maWd1cmF0aW9uIGFwcGxpZXMgdG8gcmF0aGVyIHRoYW4gYWRkaW5nIHRoZW0g dG8gYWxsIGludGVyZmFjZXMuICBGZWVkYmFjayB3b3VsZCBiZSB3ZWxjb21lIG9uIHdoZXRoZXIg dGhpcyBhcHByb2FjaCBpcyBhIGdvb2QgaWRlYS9tYWludGFpbmFibGUuDQogIC0gRm9yIE1UVSwg SSd2ZSBkZWZpbmVkIHR3byBkaWZmZXJlbnQgTVRVIGxlYXZlcyBiZWNhdXNlIGRldmljZXMgcHJv Z3JhbSBpbnRlcmZhY2UgTVRVIGluIGRpZmZlcmVudCB3YXlzIGJhc2VkIG9uIHdoZXRoZXIgdGhl IGNvbmZpZ3VyZWQgTVRVIHZhbHVlIGluY2x1ZGVzIHRoZSBMMiBoZWFkZXIgb3ZlcmhlYWQgb3Ig bm90LiAgSXMgdGhpcyBhIHJlYXNvbmFibGUgYXBwcm9hY2g/DQoNClRoYW5rcywNClJvYg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1h aWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0K From nobody Mon Jul 13 01:52:11 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 EAB9A1B29B4 for ; Mon, 13 Jul 2015 01:52:09 -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_64=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 H-KOHMqqURIP for ; Mon, 13 Jul 2015 01:52:07 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C26981B29B3 for ; Mon, 13 Jul 2015 01:52:06 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0E7461CC024F for ; Mon, 13 Jul 2015 10:52:06 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 13 Jul 2015 10:52:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] LL review of 6020bis-06 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: Mon, 13 Jul 2015 08:52:10 -0000 Hi, this time I reviewed the complete text so my comments aren't limited to YANG 1.1 stuff. Lada **** General comments 1. Would it make sense to at least mention that YANG is being used not only for NETCONF and with other encodings? =20=20=20=20=20=20=20=20 2. I think it would be useful to include text (perhaps in sec. 4.2.2) describing the schema tree and data tree, and introducing appropriate terms so that, e.g., nodes in either tree can be clearly distinguished in the subsequent text. In my experience, this causes a lot of confusion. For example, sec. 4.2.2.1 says: ' A leaf node contains simple data like an integer or a string.' And then sec. 7.6: ' The "leaf" statement is used to define a leaf node in the schema tree.' If the leaf node is in the schema tree, then it cannot contain any value. 3. It's necessary to clearly separate properties of the data tree from properties of XML encoding. For instance, it is an inherent property of a container instance in the data tree that its children are unordered, or ordered in RPC input/output. Yet this is only specified in sec. 7.5.7 (XML Mapping Rules). Similarly, the namespace of a module and XML namespace that's used in XML encoding are IMO two different things (cf. sec 5.3). =09 4. Terms "instance"/"instantiate"/"instatiation" are used in a loose way without being properly defined, probably as SNMP legacy. The XML term "instance document" adds yet another meaning. 5. A term is needed for describing a data model of a particular server, i.e. a collection of modules + supported features (+ deviations). I've used "data model", see https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model 6. As J=C3=BCrgen suggested, sections "XML Mapping Rules" should be more appropriately called "XML Encoding Rules". 7. I'd remove all mentions of submodules including other submodules, circular includes etc. because it is now confusing. If "include" is ignored in submodules, there is no need to bother with any rules. This sentence in sec. 7.1.6 should be enough: 'For backward compatibility with YANG version 1, the "include" statement is permitted in a submodule but has no effect there.' **** Sec. 3 - Shouldn't the term "data tree" also cover the contents of RPC input/output, actions and notifications? **** Sec. 4.2.2.3 OLD A container may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists). NEW A container may contain any number of child nodes of any type (leafs, lists, containers, leaf-lists, and actions). **** Sec. 4.2.9 - Include an example of action? **** Sec. 5.2 - The last paragraph about separate compilation of submodules looks like an implementation detail and could perhaps be removed. **** Sec. 5.5 s/closest matching/matching/ (because definitions of groupings/typedefs cannot shadow an equally named grouping/typedef in an outer scope) **** Sec. 5.6.4 - OLD A server implements a module if it implements the module's data nodes, rpcs, notifications, and deviations. NEW A server implements a module if it implements the module's data nodes, rpcs, actions, notifications, and deviations. - s/augement/augment/ - spurious string '#}}' at the end. **** Sec. 6.1.3 I think the rules for whitespace trimming are confusing and have very little practical uses, so I'd recommend to remove them entirely. However, if the decision is to keep them, the following ambiguities need to be addressed: - It is unclear whether '\n' is equivalent to the literal LF character in the trimming process, i.e. whether the substitution of escape sequences is done before or after the trimming. - Is tab character treated as 8 spaces also before the opening double quote? Example: description "This is a long text." Does it matter whether the character between "description" and the opening double quote is a space or tab character? (Both cases may have identical visual rendering depending on the column where the statement starts.) **** Sec. 6.2 OLD Implementations MUST support identifiers up to 64 characters in length. NEW Implementations are not required to support identifier longer than 64 character. (The current formulation can IMO be understood so that identifiers longer than 64 chars cannot be supported.) **** Sec. 6.3.1 What does the last paragraph mean? In particular: if an extension is imported and used in a module that the server advertises, could the server ignore that extension? **** Sec. 6.4 - 'The data model used in the XPath expressions is the same as that used in XPath 1.0 [XPATH], =E2=80=A6' I think some explanation is needed describing how a data tree is mapped onto the (restricted) XPath data model. Specifically: * The data tree has no concept of document order, except for RPC input/output. The spec should say implementations need to choose some document order but how it is done is undefined, so XPath expressions in YANG modules shouldn't rely on the document order. * It might be useful to define how namespace nodes representing YANG namespaces appear in the XPath tree so that the namespace:: axis works in a deterministic fashion. For example, one could say that all these namespaces are in scope for all elements corresponding to YANG data nodes. One could use it, e.g. to determine whether a particular YANG module is a part of the data model. - Another possible source of surprises are equality tests (but maybe it belongs to 6087bis). With container top { must "x =3D y"; leaf x { type decimal64 { fraction-digits 1; } } leaf y { type uint8; } } the following instance violates the must constraint: 1.0 1 **** Sec. 6.4.1 - The accessible tree should also be defined for action input/output. - Canonical values should be used also for RPCs, actions and notifications. - s/all all/all/ **** Sec. 7.1.5.1 - 'The "revision-date" statement MUST match the most recent "revision" statement in the imported module.' This should be removed because otherwise the importing module couldn't stick to an old revision of the imported module. **** Sec. 7.1.6 - 'If no "revision-date" substatement is present, it is undefined which revision of the submodule is included.' I think in this case the submodule revisions need to be specified in yang-library. **** Sec. 7.5.1 - 'In the first style, the container has no meaning of its own, existing only to contain child nodes.' I don't think this is really true, e.g. "must" statement on a NP containers adds meaning to it, see Y41. - 'In the second style, the presence of the container itself is configuration data, representing a single bit of configuration data.' What about containers with presence outside config=3Dtrue data? **** Sec. 7.5.7 - Is the order of subelements also fixed in action input/output? **** Sec. 7.5.8 - ' If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container.' Without further explanation this contradicts the resolution of Y41. It should say at least where such containers may be deleted (e.g. in the reply to or ). **** Sec. 7.6.1 - The text is suitable for config, defaults in RPC input/output and notifications are covered elsewhere, but what about defaults (and mandatory) in state data? **** Sec. 7.7.1 - The term "array" suggests some higher-level data structure (as in JSON encoding). I'd use "sequence of leaf nodes" instead. - s/firewall filters/packet filter/ **** Sec. 7.7.4 - ' The "default" statement MUST NOT be present on nodes where "min-elements" has a value greater than or equal to one.' Why? This should be OK: leaf-list foo { type uint8; min-elements 1; default 54; } **** Sec. 7.7.9 - Is the interaction of operations, leaf-list default values, and with-defaults modes sufficiently clear? See also the thread starting with https://mailarchive.ietf.org/arch/msg/netmod/PvMzWfzpYa0bg-S2jErX975= Y3Jk **** Sec. 7.8.6 - It would be helpful to include an example of yang:key attribute value with multiple (two) keys. I remember somebody asked me about that. **** Sec. 7.9.2 - The paragraph about shorthand case statement should more explicitly explain that a case node is present in the schema tree even for short-case-stmt, and thus schema node identifiers always need to include case node identifiers. **** Sec. 7.10 - The section should also state that the data model for "anydata" content may or may not be known at run time. **** Sec. 7.12 - 'For extensions, this means that extensions are applied to the grouping node, not the uses node.' I dont understand what this means. What is the "grouping node"? **** Sec. 7.13.2 - Can a leaf-list also get (new) default values through "refine"? If so, how are they combined with the default values defined in the grouping? **** Sec. 7.15 - 'An action MUST NOT be defined within an rpc, another action or a notification, =E2=80=A6' Also it MUST NOT be defined within leaf and leaf-list, right? - Can an action defined on a list be applied to the whole list? **** Sec. 7.21.3 - Maybe this section should also explain that descriptions are an integral part of the data model and may specify, e.g., semantic constraints that cannot be expressed formally. **** Sec. 9.10.2 - s/supported by the server/implemented by the server/ **** Sec. 9.10.3 The last paragraph should probably be replaced with an advice that identityref values or nodesets should never appear as bare strings in XPath expressions, and functions derived-from() or derived-from-or-self() should be used instead. Example in sec. 9.10.5 should be changed to use derived-from-or-self(). **** Sec. 10.3.1 - The document order is undefined in a data tree (also in sec. 10.4.1 and 10.4.2). - I think deref() could return non-empty nodeset only for instance-identifiers because for leafref it's not needed. The "must" constraint in sec. 10.3.1.1 is better expressed like so: '/interface[name=3Dcurrent()]/enabled =3D "true"' **** Sec. 13 - The ABNF can be made stricter by replacing "[default-stmt]" among the substatements of "choice-stmt" with "[default-case-stmt]", and then adding default-case-stmt =3D default-keyword sep node-identifier stmtend --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 13 04:24: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 E2D011A87B0 for ; Mon, 13 Jul 2015 04:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.111 X-Spam-Level: X-Spam-Status: No, score=-12.111 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_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, 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 4CO40s4JzO7o for ; Mon, 13 Jul 2015 04:24:29 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2B61A87A7 for ; Mon, 13 Jul 2015 04:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5138; q=dns/txt; s=iport; t=1436786668; x=1437996268; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=uzkoEu3IcqxfKumMWSriugrhcr7ogMMlxIbWQpI80RI=; b=hyQMiSZs8MBJ2X6qUapxcEECMb7rrQYfrpDVOwAcaOG3NA1JEOZcAeLD sm5y5mdDfz7lVOSAuOg1MQvBhgmTOfsRDc9ZjVSMrd1d8XchphPmaTWwo CJW22cHDMYzGbyVdandkqO5WnJCr2UDVRzHG0rLF1ZxBQhGZfLOBVfbbO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQAen6NV/xbLJq1SCYNoaYMiugwKgkOCakoCggABAQEBAQGBC4QkAQEEAQEBIA8BBS8HChEJAhgCAgUWCAMCAgkDAgECARUfEQYBDAYCAQGIKg2WFZ0ZlXEBAQEBAQEBAQIBAQEBAQEBFwSBIokogQKEKmOCaIFDAQSUMYRphxuBP4cFIowmg18mY4MZPTGCSwEBAQ X-IronPort-AV: E=Sophos;i="5.15,462,1432598400"; d="scan'208";a="558033493" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 13 Jul 2015 11:24:26 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6DBOQ0a025469; Mon, 13 Jul 2015 11:24:26 GMT Message-ID: <55A39FEC.4090406@cisco.com> Date: Mon, 13 Jul 2015 12:24:28 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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: Mon, 13 Jul 2015 11:24:35 -0000 Hi Michael, Thank you for your comments and review. I think that the definition of interface type is a bit vague in that there is a long list of interface types that seem to apply at quite a few different OSI layers! But in brief, the way that I perceive interface type is as a static property of an interface, fixed when an interface is created, that defines the flavour of an interface. Where appropriate I would normally relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM, etc), but there are other software interfaces where the interface type is defining a higher level construct (e.g. a tunnel, or sub-interface, or LAG group interface). My definition of encapsulation is that it provided a generic container for holding layer-2 related header information, where that is configurable. In the model that I have defined so far I have only defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the intention is that it would be augmented for cHDLC, PPP, FR and ATM. The example is potentially better illustrated for POS interfaces where the choice of encapsulation can be configured. So, if you take a POS interface as an example, then I would expect that the ifType would be fixed as ifType:pos, but the encapsulation of that interface could be cHDLC, PPP or Frame Relay. The layer 2 encapsulation information (such as timers, keepalive settings, crc settings, FR circuit ids) would live under the datalink protocol specific encapsulation node. The encapsulation node itself can be used to determine what layer 2 encapsulation is being used. Of course you could put ppp/chdlc/fr under separate containers, but it makes it slightly harder to ensure that an interface only has a single encapsulation configured. Although you could add a must statement to restrict the allowed encapsulations to those known today, it doesn't extend to other encaps types added in future. Having a choice statement effectively enforces the restriction that there can be only one encapsulation on an interface for you. Does that alleviate your concern? Thanks, Rob On 13/07/2015 09:42, wangzitao wrote: > Dear Authors, > > I've read your draft-wilton-netmod-intf-ext-yang-00 and have a question: > What is the difference between encaps-type in your yang model and interface types in RFC7224? > > I also read your draft-wilton-netmod-intf-vlan-yangwhich augment the if-cmn as: > > augment /if:interfaces/if:interface/if-cmn:encapsulation/ > if-cmn:encaps-type: > +--:(vlan) > +--rw vlan > +--rw tags > ...... > > But the vlan type have already defined in the RFC7224: > > identity l2vlan { > base iana-interface-type; > description > "Layer 2 Virtual LAN using 802.1Q."; > } > identity l3ipvlan { > base iana-interface-type; > description > "Layer 3 Virtual LAN using IP."; > } > identity l3ipxvlan { > base iana-interface-type; > description > "Layer 3 Virtual LAN using IPX."; > } > > Why not reuse the vlan types definding in RFC7224? And it may simplify the augment target path such as: > > augment /if:interfaces/if:interface: > +--rw encaps-type identityref > +--rw vlan > +--rw tags > ...... > > Best Regards! > -Michael > > -----邮件原件----- > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Robert Wilton > 发送时间: 2015年7月9日 0:11 > 收件人: netmod@ietf.org > 主题: [netmod] Interface Extensions YANG draft > > Hi, > > I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices. E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses. I am hoping that this draft could be adopted and standardized by the netmod WG. > > https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ > > Any comments or feedback is appreciated. > > Potential points of interest/discussion may be: > - Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented? > - We've tried to restrict the leaves to just the interface types (using when if:type = ...) that the configuration applies to rather than adding them to all interfaces. Feedback would be welcome on whether this approach is a good idea/maintainable. > - For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not. Is this a reasonable approach? > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jul 13 04:30:19 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 C86FB1A87AF for ; Mon, 13 Jul 2015 04:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.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 engUrIQHhUI1 for ; Mon, 13 Jul 2015 04:30:13 -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 AE70A1A87EB for ; Mon, 13 Jul 2015 04:30: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 ABBAEFA4; Mon, 13 Jul 2015 13:30: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 zLxjs9VXH56p; Mon, 13 Jul 2015 13:30: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; Mon, 13 Jul 2015 13:30:09 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7E8B20035; Mon, 13 Jul 2015 13:30: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 hBs3NrFZjA4l; Mon, 13 Jul 2015 13:30:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7CB720031; Mon, 13 Jul 2015 13:30:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DC75B353F4A1; Mon, 13 Jul 2015 13:30:06 +0200 (CEST) Date: Mon, 13 Jul 2015 13:30:06 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20150713113006.GA6797@elstar.local> Mail-Followup-To: Robert Wilton , wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <55A39FEC.4090406@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Interface Extensions YANG draft 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: Mon, 13 Jul 2015 11:30:19 -0000 Hi, did we not solve this problem with interface layering (or stacking) in the MIB world? If so, why would we depart from that model? /js On Mon, Jul 13, 2015 at 12:24:28PM +0100, Robert Wilton wrote: > Hi Michael, > > Thank you for your comments and review. > > I think that the definition of interface type is a bit vague in that > there is a long list of interface types that seem to apply at quite a > few different OSI layers! > > But in brief, the way that I perceive interface type is as a static > property of an interface, fixed when an interface is created, that > defines the flavour of an interface. Where appropriate I would normally > relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM, > etc), but there are other software interfaces where the interface type > is defining a higher level construct (e.g. a tunnel, or sub-interface, > or LAG group interface). > > My definition of encapsulation is that it provided a generic container > for holding layer-2 related header information, where that is > configurable. In the model that I have defined so far I have only > defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the > intention is that it would be augmented for cHDLC, PPP, FR and ATM. The > example is potentially better illustrated for POS interfaces where the > choice of encapsulation can be configured. > > So, if you take a POS interface as an example, then I would expect that > the ifType would be fixed as ifType:pos, but the encapsulation of that > interface could be cHDLC, PPP or Frame Relay. The layer 2 encapsulation > information (such as timers, keepalive settings, crc settings, FR > circuit ids) would live under the datalink protocol specific > encapsulation node. The encapsulation node itself can be used to > determine what layer 2 encapsulation is being used. > > Of course you could put ppp/chdlc/fr under separate containers, but it > makes it slightly harder to ensure that an interface only has a single > encapsulation configured. Although you could add a must statement to > restrict the allowed encapsulations to those known today, it doesn't > extend to other encaps types added in future. Having a choice statement > effectively enforces the restriction that there can be only one > encapsulation on an interface for you. > > Does that alleviate your concern? > > Thanks, > Rob > > > On 13/07/2015 09:42, wangzitao wrote: > >Dear Authors, > > > >I've read your draft-wilton-netmod-intf-ext-yang-00 and have a question: > >What is the difference between encaps-type in your yang model and > >interface types in RFC7224? > > > >I also read your draft-wilton-netmod-intf-vlan-yangwhich augment the > >if-cmn as: > > > > augment /if:interfaces/if:interface/if-cmn:encapsulation/ > > if-cmn:encaps-type: > > +--:(vlan) > > +--rw vlan > > +--rw tags > > ...... > > > > But the vlan type have already defined in the RFC7224: > > > > identity l2vlan { > > base iana-interface-type; > > description > > "Layer 2 Virtual LAN using 802.1Q."; > > } > > identity l3ipvlan { > > base iana-interface-type; > > description > > "Layer 3 Virtual LAN using IP."; > > } > > identity l3ipxvlan { > > base iana-interface-type; > > description > > "Layer 3 Virtual LAN using IPX."; > > } > > > > Why not reuse the vlan types definding in RFC7224? And it may simplify > > the augment target path such as: > > > > augment /if:interfaces/if:interface: > > +--rw encaps-type identityref > > +--rw vlan > > +--rw tags > > ...... > > > >Best Regards! > >-Michael > > > >-----邮件原件----- > >发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Robert Wilton > >发送时间: 2015年7月9日 0:11 > >收件人: netmod@ietf.org > >主题: [netmod] Interface Extensions YANG draft > > > >Hi, > > > >I have submitted a new draft for provides several augmentations to the > >ietf if:interfaces to define configuration YANG for basic interface > >parameters that are commonly supported on network devices. E.g. it is > >includes leaves such as bandwidth, carrier delay, dampening, loopback, > >mtu, & sub-interface parent ref, and configurable interface MAC addresses. > >I am hoping that this draft could be adopted and standardized by the > >netmod WG. > > > >https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ > > > >Any comments or feedback is appreciated. > > > >Potential points of interest/discussion may be: > > - Is it acceptable to define standard YANG for features that are not > > backed by any formal standard if they are commonly implemented? > > - We've tried to restrict the leaves to just the interface types (using > > when if:type = ...) that the configuration applies to rather than > > adding them to all interfaces. Feedback would be welcome on whether > > this approach is a good idea/maintainable. > > - For MTU, I've defined two different MTU leaves because devices > > program interface MTU in different ways based on whether the configured > > MTU value includes the L2 header overhead or not. Is this a reasonable > > approach? > > > >Thanks, > >Rob > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 13 07:44:06 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 E91A51B2B4A for ; Mon, 13 Jul 2015 07:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.111 X-Spam-Level: X-Spam-Status: No, score=-12.111 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_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, 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 EeZqXKcmBCPp for ; Mon, 13 Jul 2015 07:44:02 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592031B2B33 for ; Mon, 13 Jul 2015 07:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6540; q=dns/txt; s=iport; t=1436798642; x=1438008242; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NKZuYtmfxGDaUgekOcX92AwWNh601JiYXxs5DE3pkks=; b=gwXe20tZJUQ/ySbe5uUjsqnx4HgGU7S+3Cl/hcY78HFXxe4Cueaudblc HLR19/230/FPri/0ku51dbJCiutMFMgcsZV+JyBTnTMI8ZOLzlbWibOQk lbjr/F4I33bKnTFQdyNbQStx08TsHFpCNVZrx8da24OQ6FbTuHlKZIMld s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQBFzqNV/xbLJq1SCYNoaYMiuhEKgkOCakoCgX8BAQEBAQGBC4QkAQEEAQEBIAQLAQUvBwQGEQkCGAICBRYIAwICCQMCAQIBFR8RBgEMBgIBAYgqDZcwnRmVZAEBAQEBAQEBAgEBAQEBAQEXBIEiiSiBAoQqY4JogUMBBJQxhGmHG4E/hwUijCaDXyZjgSkcgVQ9MYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="558186768" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 13 Jul 2015 14:44:00 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6DEi0AS015410; Mon, 13 Jul 2015 14:44:00 GMT Message-ID: <55A3CEAF.7090800@cisco.com> Date: Mon, 13 Jul 2015 15:43:59 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> In-Reply-To: <20150713113006.GA6797@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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: Mon, 13 Jul 2015 14:44:05 -0000 Hi Juergen, If I understand your comment correctly, this would imply that you have a separate interface representing the basecaps independently from the interface itself. As far as I know this isn't widely done even if it supported by ifStack. More naturally it feels that the interface layering is more useful to represent LAG interfaces or VLAN sub-interfaces, which can be done, but section 3.3 Interface Layering from YANG Interface Management indicates that the layering attributes are read only, so you still need separate configuration leaves to set up the parent<->child relationship. Thanks, Rob On 13/07/2015 12:30, Juergen Schoenwaelder wrote: > Hi, > > did we not solve this problem with interface layering (or stacking) in > the MIB world? If so, why would we depart from that model? > > /js > > On Mon, Jul 13, 2015 at 12:24:28PM +0100, Robert Wilton wrote: >> Hi Michael, >> >> Thank you for your comments and review. >> >> I think that the definition of interface type is a bit vague in that >> there is a long list of interface types that seem to apply at quite a >> few different OSI layers! >> >> But in brief, the way that I perceive interface type is as a static >> property of an interface, fixed when an interface is created, that >> defines the flavour of an interface. Where appropriate I would normally >> relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM, >> etc), but there are other software interfaces where the interface type >> is defining a higher level construct (e.g. a tunnel, or sub-interface, >> or LAG group interface). >> >> My definition of encapsulation is that it provided a generic container >> for holding layer-2 related header information, where that is >> configurable. In the model that I have defined so far I have only >> defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the >> intention is that it would be augmented for cHDLC, PPP, FR and ATM. The >> example is potentially better illustrated for POS interfaces where the >> choice of encapsulation can be configured. >> >> So, if you take a POS interface as an example, then I would expect that >> the ifType would be fixed as ifType:pos, but the encapsulation of that >> interface could be cHDLC, PPP or Frame Relay. The layer 2 encapsulation >> information (such as timers, keepalive settings, crc settings, FR >> circuit ids) would live under the datalink protocol specific >> encapsulation node. The encapsulation node itself can be used to >> determine what layer 2 encapsulation is being used. >> >> Of course you could put ppp/chdlc/fr under separate containers, but it >> makes it slightly harder to ensure that an interface only has a single >> encapsulation configured. Although you could add a must statement to >> restrict the allowed encapsulations to those known today, it doesn't >> extend to other encaps types added in future. Having a choice statement >> effectively enforces the restriction that there can be only one >> encapsulation on an interface for you. >> >> Does that alleviate your concern? >> >> Thanks, >> Rob >> >> >> On 13/07/2015 09:42, wangzitao wrote: >>> Dear Authors, >>> >>> I've read your draft-wilton-netmod-intf-ext-yang-00 and have a question: >>> What is the difference between encaps-type in your yang model and >>> interface types in RFC7224? >>> >>> I also read your draft-wilton-netmod-intf-vlan-yangwhich augment the >>> if-cmn as: >>> >>> augment /if:interfaces/if:interface/if-cmn:encapsulation/ >>> if-cmn:encaps-type: >>> +--:(vlan) >>> +--rw vlan >>> +--rw tags >>> ...... >>> >>> But the vlan type have already defined in the RFC7224: >>> >>> identity l2vlan { >>> base iana-interface-type; >>> description >>> "Layer 2 Virtual LAN using 802.1Q."; >>> } >>> identity l3ipvlan { >>> base iana-interface-type; >>> description >>> "Layer 3 Virtual LAN using IP."; >>> } >>> identity l3ipxvlan { >>> base iana-interface-type; >>> description >>> "Layer 3 Virtual LAN using IPX."; >>> } >>> >>> Why not reuse the vlan types definding in RFC7224? And it may simplify >>> the augment target path such as: >>> >>> augment /if:interfaces/if:interface: >>> +--rw encaps-type identityref >>> +--rw vlan >>> +--rw tags >>> ...... >>> >>> Best Regards! >>> -Michael >>> >>> -----邮件原件----- >>> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Robert Wilton >>> 发送时间: 2015年7月9日 0:11 >>> 收件人: netmod@ietf.org >>> 主题: [netmod] Interface Extensions YANG draft >>> >>> Hi, >>> >>> I have submitted a new draft for provides several augmentations to the >>> ietf if:interfaces to define configuration YANG for basic interface >>> parameters that are commonly supported on network devices. E.g. it is >>> includes leaves such as bandwidth, carrier delay, dampening, loopback, >>> mtu, & sub-interface parent ref, and configurable interface MAC addresses. >>> I am hoping that this draft could be adopted and standardized by the >>> netmod WG. >>> >>> https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ >>> >>> Any comments or feedback is appreciated. >>> >>> Potential points of interest/discussion may be: >>> - Is it acceptable to define standard YANG for features that are not >>> backed by any formal standard if they are commonly implemented? >>> - We've tried to restrict the leaves to just the interface types (using >>> when if:type = ...) that the configuration applies to rather than >>> adding them to all interfaces. Feedback would be welcome on whether >>> this approach is a good idea/maintainable. >>> - For MTU, I've defined two different MTU leaves because devices >>> program interface MTU in different ways based on whether the configured >>> MTU value includes the L2 header overhead or not. Is this a reasonable >>> approach? >>> >>> Thanks, >>> Rob >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jul 13 07:52:37 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 9C9DE1B2B65 for ; Mon, 13 Jul 2015 07:52: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 fj6t-oHblZEL for ; Mon, 13 Jul 2015 07:52: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 234CC1B2B64 for ; Mon, 13 Jul 2015 07:52: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 4D15E152A; Mon, 13 Jul 2015 16:52:31 +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 GZpzHMExzZ0a; Mon, 13 Jul 2015 16:52:31 +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, 13 Jul 2015 16:52:30 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1282020033; Mon, 13 Jul 2015 16:52: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 g1ffnEHGyVVf; Mon, 13 Jul 2015 16:52: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 3686D20031; Mon, 13 Jul 2015 16:52:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 17CA6353FD79; Mon, 13 Jul 2015 16:52:29 +0200 (CEST) Date: Mon, 13 Jul 2015 16:52:29 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20150713145229.GA237@elstar.local> Mail-Followup-To: Robert Wilton , wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A3CEAF.7090800@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Interface Extensions YANG draft 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: Mon, 13 Jul 2015 14:52:35 -0000 On Mon, Jul 13, 2015 at 03:43:59PM +0100, Robert Wilton wrote: > Hi Juergen, > > If I understand your comment correctly, this would imply that you have a > separate interface representing the basecaps independently from the > interface itself. As far as I know this isn't widely done even if it > supported by ifStack. Whatever basecaps are... > More naturally it feels that the interface layering is more useful to > represent LAG interfaces or VLAN sub-interfaces, which can be done, but > section 3.3 Interface Layering from YANG Interface Management indicates > that the layering attributes are read only, so you still need separate > configuration leaves to set up the parent<->child relationship. See Appendix C in RFC 7223 how this was envisioned to be done. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 13 10:02:25 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 64EC31A6F7B for ; Mon, 13 Jul 2015 10:02:24 -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 YSOlPQEjwdnn for ; Mon, 13 Jul 2015 10:02:22 -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 33D591A6FE9 for ; Mon, 13 Jul 2015 10:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1732; q=dns/txt; s=iport; t=1436806943; x=1438016543; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ct0pVHH/9rwvEh98fiPG9PkjwKghWEHn3W0S3uJa0JQ=; b=foat7Bks6xgd70VfUn+qT299WMhN2T7NGDpeTR34LDiHuEn5iGgWfQJ4 AIuTjr15l8T5RrHiPKeTAGCZYFt30dtmmnXoJpdEFB38cl2BGrUchET6R augVYoS9G759w2YNWRryq/s9d3TjQT9ga4HqM5/JVOLQqqKXXUy7vtBf2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvBQDw7aNV/xbLJq1bwBMJhReCVAKBcxQBAQEBAQEBgQpBBYNeAQEEJxE6BhELGAkWDwkDAgECAUUGAQwIAQGIKssUAQEBAQEBAQEBAQEBAQEBARyLTIUNhCsBBJQxjASBP4cFIowmg18mY4MZPYJ8AQEB X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="564760032" 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; 13 Jul 2015 17:02:21 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6DH2JfB028888; Mon, 13 Jul 2015 17:02:20 GMT Message-ID: <55A3EF1B.4050907@cisco.com> Date: Mon, 13 Jul 2015 18:02:19 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> <20150713145229.GA237@elstar.local> In-Reply-To: <20150713145229.GA237@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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: Mon, 13 Jul 2015 17:02:24 -0000 Hi Juergen, On 13/07/2015 15:52, Juergen Schoenwaelder wrote: > On Mon, Jul 13, 2015 at 03:43:59PM +0100, Robert Wilton wrote: >> Hi Juergen, >> >> If I understand your comment correctly, this would imply that you have a >> separate interface representing the basecaps independently from the >> interface itself. As far as I know this isn't widely done even if it >> supported by ifStack. > Whatever basecaps are... Apologies, I was lax with my terminology - I meant the datalink layer encapsulation (e.g. PPP, cHDLC, etc for a Packet-over-Sonet interface). > >> More naturally it feels that the interface layering is more useful to >> represent LAG interfaces or VLAN sub-interfaces, which can be done, but >> section 3.3 Interface Layering from YANG Interface Management indicates >> that the layering attributes are read only, so you still need separate >> configuration leaves to set up the parent<->child relationship. > See Appendix C in RFC 7223 how this was envisioned to be done. Yes, I believe that the approach that we have proposed is broadly consistent with that, but defined in a slightly more generic way and without the need for the vlan-tagging leaf on the parent. However, in the model that we have proposed, it is likely that the "parent-interface" interface-ref that we define on a sub-interface has to be an optional leaf because you are not allowed to augment with a mandatory node. So, this would come down to implementations being expected to reject sub-interface configurations if the parent-interface hasn't been correctly populated. In some ways this is not ideal - but I can appreciate why the YANG rules are how they are. Thanks, Rob > > /js > From nobody Mon Jul 13 11:25: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 B40941B2D1E for ; Mon, 13 Jul 2015 11:25: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 v0efZreHBUZs for ; Mon, 13 Jul 2015 11:24:58 -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 A6B841B2D14 for ; Mon, 13 Jul 2015 11:24:55 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id E152570B7E998; Mon, 13 Jul 2015 18:24:51 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t6DIOql2001573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jul 2015 18:24:52 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.242]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 13 Jul 2015 14:24:51 -0400 From: "Varma, Eve L (Eve)" To: Italo Busi , "netmod@ietf.org" Thread-Topic: Comments on draft-mansfield-uml-to-yang-00 Thread-Index: AdC7IFQIwGLJvQHoTLSoVx6sNWl0IQCeJajw Date: Mon, 13 Jul 2015 18:24:51 +0000 Message-ID: <6D32668528F93D449A073F45707153D8BEB84B46@US70UWXCHMBA03.zam.alcatel-lucent.com> References: <91E3A1BD737FDF4FA14118387FF6766B0111A421@lhreml504-mbs> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B0111A421@lhreml504-mbs> 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: Subject: Re: [netmod] Comments on draft-mansfield-uml-to-yang-00 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: Mon, 13 Jul 2015 18:25:00 -0000 Hi Italo, Thank you for your very helpful comments! Just a quick note - the subsection numbers you commented on seems off by on= e. For example, object class mapping is in Section 5.2, not 5.1; associatio= n mapping is in section 5.5, not 5.4. Best regards, Eve -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Italo Busi Sent: Friday, July 10, 2015 10:55 AM To: netmod@ietf.org Subject: [netmod] Comments on draft-mansfield-uml-to-yang-00 Dear authors of draft-mansfield-uml-to-yang, I think this draft is very useful in assisting translation between UML IMs = and Yang DMs. Since many UML IMs have been already defined, this I-D would = help in simplifying development and/or gap analysis of new Yang DMs. It also complements the work on the suite of translation drafts developed o= r under development in the NETMOD WG (e.g., RFC 6643 and draft-ietf-netmod-= yang-json). I have started to read the draft and have got an initial set of comments I = would like to share (further comments may follow while I continue reviewing= the draft). Appendix A is very helpful to see how the different mapping rules work. It = would be worth enhancing it with some further detailed descriptions also re= ferencing the YANG Module and not only the YANG tree of draft-dharini-netmo= d-g-698-2-yang-04. It seems that section 5 of this I-D is describing the mapping between the U= ML artifacts defined in section 5 of TR-514. It would be worth adding some = text to clarify this point. It seems that section 5.1 of this I-D is describing how the Object Class UM= L artifact described in section 5.1 of TR-514 is mapped into YANG statement= s. In particular, an Object Class UML artifact can be mapped either to a "list= " or to a "container" YANG statement. The I-D does not describe when (i.e.,= under which condition) a "list" or a "container" statement should be used.= Are both approaches equivalent or is there a criteria for using one or oth= er approach depending on some characteristics of the Object Class? Looking YANG module in the appendix A example (draft-dharini-netmod-g-698-2= -yang-04), it seems that the superclass property of an Object Class artifac= t is not explicitly defined but it is inferred from the structure of the "a= ugment" and "container" statements: augment "/if:interfaces/if:interface" { description "Parameters for an optical interface"; container optIfOChRsSs { description "RsSs path configuration for an interface"; <...> } Looking at this example, it is also worth noting that the documentation pro= perty of the optIfOChRsSs Object Class maps to the "description" substateme= nt below the "container optIfOChRsSs" statement (i.e., description "RsSs pa= th configuration for an interface";). The other description statement (i.e.= , description "Parameters for an optical interface";) is mapping the docume= ntation property of the inheritance relationship. It would be worth updating Section 5.4 to describe how the properties of th= e Association UML artifacts maps into substatements of the YANG statements = as well as updating appendix A to describe the example above. Is it possible to map into YANG an UML Object Class that inherits from more= than one superclass? Just a nit: I think that reference [7] is not an OMG document Thanks, Italo _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jul 14 01:00:44 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 AAA211A903E for ; Tue, 14 Jul 2015 01:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, 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 bFjZJVRFBvL7 for ; Tue, 14 Jul 2015 01:00:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995EF1A9039 for ; Tue, 14 Jul 2015 01:00:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVD47321; Tue, 14 Jul 2015 08:00:34 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jul 2015 09:00:33 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.165]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0158.001; Tue, 14 Jul 2015 15:59:17 +0800 From: wangzitao To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] Interface Extensions YANG draft Thread-Index: AQHQuZjCtVrBUkcxvEOF9mfvFyjSs53ZHDnQ//+nbgCAAd7SAA== Date: Tue, 14 Jul 2015 07:59:17 +0000 Message-ID: References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> In-Reply-To: <55A39FEC.4090406@cisco.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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: Tue, 14 Jul 2015 08:00:42 -0000 Um9iLA0KDQpXaGF0IG1ha2VzIG1lIGNvbmZ1c2UgYmVmb3JlIGlzIHRoYXQgd2h5IG5vdCBkaXJl Y3RseSB1c2UgdGhlIGVuY2Fwc3VsYXRpb24gdHlwZSBpbiBpYW5hLWlmLXR5cGU/IFRoZSBpYW5h LWlmLXR5cGUgYWxzbyBwcm92aWRlIGEgbG90IG9mIGVuY2Fwc3VsYXRpb24gdHlwZSBzdWNoIGFz IFBQUCwgRnJhbWUgUmVsYXksIGV0Yy4gDQpOb3cgSSB1bmRlcnN0b29kIGEgYml0LiBZb3Ugd2Fu dCB0byBwcm92aWRlIGFuIGV4cGxpY2l0IGVuY2Fwc3VsYXRpb24gaW5mb3JtYXRpb24uIEZvciBl eGFtcGxlLCBmb3IgcG9zIGludGVyZmFjZSwgeW91IG1heSBkZWZpbmUgdGhlIHlhbmcgbW9kZWwg YXM6DQoNCiAgYXVnbWVudCAiL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2lmLWNtbjplbmNh cHN1bGF0aW9uLyIgKw0KICAgICAgICAgICAgICJpZi1jbW46ZW5jYXBzLXR5cGUiIHsNCiAgICAg ICB3aGVuICIuLi8uLi9pZjp0eXBlID0gJ2lhbmFpZnQ6cG9zJyIgew0KICAgICAgIGNhc2UgUFBQ ew0KICAgICAgICAgIGZvbzt9DQogICAgICAgICAuLi4uLg0KDQpXaGljaCBpbmRpY2F0ZSB0aGlz IGlzIGEgcG9zIGludGVyZmFjZSBhbmQgaXQgZW5jYXBzdWxhdGlvbiBpcyBQUFAuLi4gDQpJcyBt eSB1bmRlcnN0b29kIHJpZ2h0Pw0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0KDQoNCi0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0 b25AY2lzY28uY29tXSANCuWPkemAgeaXtumXtDogMjAxNeW5tDfmnIgxM+aXpSAxOToyNA0K5pS2 5Lu25Lq6OiB3YW5neml0YW87IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0g SW50ZXJmYWNlIEV4dGVuc2lvbnMgWUFORyBkcmFmdA0KDQpIaSBNaWNoYWVsLA0KDQpUaGFuayB5 b3UgZm9yIHlvdXIgY29tbWVudHMgYW5kIHJldmlldy4NCg0KSSB0aGluayB0aGF0IHRoZSBkZWZp bml0aW9uIG9mIGludGVyZmFjZSB0eXBlIGlzIGEgYml0IHZhZ3VlIGluIHRoYXQgdGhlcmUgaXMg YSBsb25nIGxpc3Qgb2YgaW50ZXJmYWNlIHR5cGVzIHRoYXQgc2VlbSB0byBhcHBseSBhdCBxdWl0 ZSBhIGZldyBkaWZmZXJlbnQgT1NJIGxheWVycyENCg0KQnV0IGluIGJyaWVmLCB0aGUgd2F5IHRo YXQgSSBwZXJjZWl2ZSBpbnRlcmZhY2UgdHlwZSBpcyBhcyBhIHN0YXRpYyBwcm9wZXJ0eSBvZiBh biBpbnRlcmZhY2UsIGZpeGVkIHdoZW4gYW4gaW50ZXJmYWNlIGlzIGNyZWF0ZWQsIHRoYXQgZGVm aW5lcyB0aGUgZmxhdm91ciBvZiBhbiBpbnRlcmZhY2UuICBXaGVyZSBhcHByb3ByaWF0ZSBJIHdv dWxkIG5vcm1hbGx5IHJlbGF0ZSB0aGUgaWZUeXBlIHRvIHRoZSB1bmRlcmx5aW5nIGhhcmR3YXJl IChlLmcuIFBPUywgRXRoZXJuZXQsIEFUTSwgZXRjKSwgYnV0IHRoZXJlIGFyZSBvdGhlciBzb2Z0 d2FyZSBpbnRlcmZhY2VzIHdoZXJlIHRoZSBpbnRlcmZhY2UgdHlwZSBpcyBkZWZpbmluZyBhIGhp Z2hlciBsZXZlbCBjb25zdHJ1Y3QgKGUuZy4gYSB0dW5uZWwsIG9yIHN1Yi1pbnRlcmZhY2UsIG9y IExBRyBncm91cCBpbnRlcmZhY2UpLg0KDQpNeSBkZWZpbml0aW9uIG9mIGVuY2Fwc3VsYXRpb24g aXMgdGhhdCBpdCBwcm92aWRlZCBhIGdlbmVyaWMgY29udGFpbmVyIGZvciBob2xkaW5nIGxheWVy LTIgcmVsYXRlZCBoZWFkZXIgaW5mb3JtYXRpb24sIHdoZXJlIHRoYXQgaXMgY29uZmlndXJhYmxl LiAgSW4gdGhlIG1vZGVsIHRoYXQgSSBoYXZlIGRlZmluZWQgc28gZmFyIEkgaGF2ZSBvbmx5IGRl ZmluZWQgdGhlIGVuY2Fwc3VsYXRpb24gbm9kZSBmb3IgRXRoZXJuZXQvVkxBTiBzdWItaW50ZXJm YWNlcywgYnV0IHRoZSBpbnRlbnRpb24gaXMgdGhhdCBpdCB3b3VsZCBiZSBhdWdtZW50ZWQgZm9y IGNIRExDLCBQUFAsIEZSIGFuZCBBVE0uICBUaGUgZXhhbXBsZSBpcyBwb3RlbnRpYWxseSBiZXR0 ZXIgaWxsdXN0cmF0ZWQgZm9yIFBPUyBpbnRlcmZhY2VzIHdoZXJlIHRoZSBjaG9pY2Ugb2YgZW5j YXBzdWxhdGlvbiBjYW4gYmUgY29uZmlndXJlZC4NCg0KU28sIGlmIHlvdSB0YWtlIGEgUE9TIGlu dGVyZmFjZSBhcyBhbiBleGFtcGxlLCB0aGVuIEkgd291bGQgZXhwZWN0IHRoYXQgdGhlIGlmVHlw ZSB3b3VsZCBiZSBmaXhlZCBhcyBpZlR5cGU6cG9zLCBidXQgdGhlIGVuY2Fwc3VsYXRpb24gb2Yg dGhhdCBpbnRlcmZhY2UgY291bGQgYmUgY0hETEMsIFBQUCBvciBGcmFtZSBSZWxheS4gIFRoZSBs YXllciAyIGVuY2Fwc3VsYXRpb24gaW5mb3JtYXRpb24gKHN1Y2ggYXMgdGltZXJzLCBrZWVwYWxp dmUgc2V0dGluZ3MsIGNyYyBzZXR0aW5ncywgRlIgY2lyY3VpdCBpZHMpIHdvdWxkIGxpdmUgdW5k ZXIgdGhlIGRhdGFsaW5rIHByb3RvY29sIHNwZWNpZmljIGVuY2Fwc3VsYXRpb24gbm9kZS4gIFRo ZSBlbmNhcHN1bGF0aW9uIG5vZGUgaXRzZWxmIGNhbiBiZSB1c2VkIHRvIGRldGVybWluZSB3aGF0 IGxheWVyIDIgZW5jYXBzdWxhdGlvbiBpcyBiZWluZyB1c2VkLg0KDQpPZiBjb3Vyc2UgeW91IGNv dWxkIHB1dCBwcHAvY2hkbGMvZnIgdW5kZXIgc2VwYXJhdGUgY29udGFpbmVycywgYnV0IGl0IG1h a2VzIGl0IHNsaWdodGx5IGhhcmRlciB0byBlbnN1cmUgdGhhdCBhbiBpbnRlcmZhY2Ugb25seSBo YXMgYSBzaW5nbGUgZW5jYXBzdWxhdGlvbiBjb25maWd1cmVkLiAgQWx0aG91Z2ggeW91IGNvdWxk IGFkZCBhIG11c3Qgc3RhdGVtZW50IHRvIHJlc3RyaWN0IHRoZSBhbGxvd2VkIGVuY2Fwc3VsYXRp b25zIHRvIHRob3NlIGtub3duIHRvZGF5LCBpdCBkb2Vzbid0IGV4dGVuZCB0byBvdGhlciBlbmNh cHMgdHlwZXMgYWRkZWQgaW4gZnV0dXJlLiBIYXZpbmcgYSBjaG9pY2Ugc3RhdGVtZW50IGVmZmVj dGl2ZWx5IGVuZm9yY2VzIHRoZSByZXN0cmljdGlvbiB0aGF0IHRoZXJlIGNhbiBiZSBvbmx5IG9u ZSBlbmNhcHN1bGF0aW9uIG9uIGFuIGludGVyZmFjZSBmb3IgeW91Lg0KDQpEb2VzIHRoYXQgYWxs ZXZpYXRlIHlvdXIgY29uY2Vybj8NCg0KVGhhbmtzLA0KUm9iDQoNCg0KT24gMTMvMDcvMjAxNSAw OTo0Miwgd2FuZ3ppdGFvIHdyb3RlOg0KPiBEZWFyIEF1dGhvcnMsDQo+DQo+IEkndmUgcmVhZCB5 b3VyIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMCBhbmQgaGF2ZSBhIHF1ZXN0 aW9uOg0KPiBXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gZW5jYXBzLXR5cGUgaW4geW91 ciB5YW5nIG1vZGVsIGFuZCBpbnRlcmZhY2UgdHlwZXMgaW4gUkZDNzIyND8NCj4NCj4gSSBhbHNv IHJlYWQgeW91ciBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtdmxhbi15YW5nd2hpY2ggYXVnbWVu dCB0aGUgaWYtY21uIGFzOg0KPg0KPiAgIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJm YWNlL2lmLWNtbjplbmNhcHN1bGF0aW9uLw0KPiAgIGlmLWNtbjplbmNhcHMtdHlwZToNCj4gICAg ICAgICstLToodmxhbikNCj4gICAgICAgICAgICstLXJ3IHZsYW4NCj4gICAgICAgICAgICAgICst LXJ3IHRhZ3MNCj4gICAgICAgICAgICAgIC4uLi4uLg0KPiAgICANCj4gICAgQnV0IHRoZSB2bGFu IHR5cGUgaGF2ZSBhbHJlYWR5IGRlZmluZWQgaW4gdGhlIFJGQzcyMjQ6DQo+DQo+ICAgICAgIGlk ZW50aXR5IGwydmxhbiB7DQo+ICAgICAgICAgYmFzZSBpYW5hLWludGVyZmFjZS10eXBlOw0KPiAg ICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAiTGF5ZXIgMiBWaXJ0dWFsIExBTiB1c2lu ZyA4MDIuMVEuIjsNCj4gICAgICAgfQ0KPiAgICAgICBpZGVudGl0eSBsM2lwdmxhbiB7DQo+ICAg ICAgICAgYmFzZSBpYW5hLWludGVyZmFjZS10eXBlOw0KPiAgICAgICAgIGRlc2NyaXB0aW9uDQo+ ICAgICAgICAgICAiTGF5ZXIgMyBWaXJ0dWFsIExBTiB1c2luZyBJUC4iOw0KPiAgICAgICB9DQo+ ICAgICAgIGlkZW50aXR5IGwzaXB4dmxhbiB7DQo+ICAgICAgICAgYmFzZSBpYW5hLWludGVyZmFj ZS10eXBlOw0KPiAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAiTGF5ZXIgMyBWaXJ0 dWFsIExBTiB1c2luZyBJUFguIjsNCj4gICAgICAgfQ0KPiAgICANCj4gICAgV2h5IG5vdCByZXVz ZSB0aGUgdmxhbiB0eXBlcyBkZWZpbmRpbmcgaW4gUkZDNzIyND8gQW5kIGl0IG1heSBzaW1wbGlm eSB0aGUgYXVnbWVudCB0YXJnZXQgcGF0aCBzdWNoIGFzOg0KPg0KPiAgICAgIGF1Z21lbnQgL2lm OmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0KPiAgICAgICAgICAgKy0tcncgZW5jYXBzLXR5cGUg ICBpZGVudGl0eXJlZg0KPiAgICAgICAgICAgKy0tcncgdmxhbg0KPiAgICAgICAgICAgICAgKy0t cncgdGFncw0KPiAgICAgICAgICAgICAgLi4uLi4uDQo+DQo+IEJlc3QgUmVnYXJkcyENCj4gLU1p Y2hhZWwNCj4NCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IG5ldG1vZCBb bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9iZXJ0IFdpbHRvbg0KPiDl j5HpgIHml7bpl7Q6IDIwMTXlubQ35pyIOeaXpSAwOjExDQo+IOaUtuS7tuS6ujogbmV0bW9kQGll dGYub3JnDQo+IOS4u+mimDogW25ldG1vZF0gSW50ZXJmYWNlIEV4dGVuc2lvbnMgWUFORyBkcmFm dA0KPg0KPiBIaSwNCj4NCj4gSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBmb3IgcHJvdmlk ZXMgc2V2ZXJhbCBhdWdtZW50YXRpb25zIHRvIHRoZSBpZXRmIGlmOmludGVyZmFjZXMgdG8gZGVm aW5lIGNvbmZpZ3VyYXRpb24gWUFORyBmb3IgYmFzaWMgaW50ZXJmYWNlIHBhcmFtZXRlcnMgdGhh dCBhcmUgY29tbW9ubHkgc3VwcG9ydGVkIG9uIG5ldHdvcmsgZGV2aWNlcy4gIEUuZy4gaXQgaXMg aW5jbHVkZXMgbGVhdmVzIHN1Y2ggYXMgYmFuZHdpZHRoLCBjYXJyaWVyIGRlbGF5LCBkYW1wZW5p bmcsIGxvb3BiYWNrLCBtdHUsICYgc3ViLWludGVyZmFjZSBwYXJlbnQgcmVmLCBhbmQgY29uZmln dXJhYmxlIGludGVyZmFjZSBNQUMgYWRkcmVzc2VzLiAgSSBhbSBob3BpbmcgdGhhdCB0aGlzIGRy YWZ0IGNvdWxkIGJlIGFkb3B0ZWQgYW5kIHN0YW5kYXJkaXplZCBieSB0aGUgbmV0bW9kIFdHLg0K Pg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aWx0b24tbmV0bW9k LWludGYtZXh0LXlhbmcvDQo+DQo+IEFueSBjb21tZW50cyBvciBmZWVkYmFjayBpcyBhcHByZWNp YXRlZC4NCj4NCj4gUG90ZW50aWFsIHBvaW50cyBvZiBpbnRlcmVzdC9kaXNjdXNzaW9uIG1heSBi ZToNCj4gICAgLSBJcyBpdCBhY2NlcHRhYmxlIHRvIGRlZmluZSBzdGFuZGFyZCBZQU5HIGZvciBm ZWF0dXJlcyB0aGF0IGFyZSBub3QgYmFja2VkIGJ5IGFueSBmb3JtYWwgc3RhbmRhcmQgaWYgdGhl eSBhcmUgY29tbW9ubHkgaW1wbGVtZW50ZWQ/DQo+ICAgIC0gV2UndmUgdHJpZWQgdG8gcmVzdHJp Y3QgdGhlIGxlYXZlcyB0byBqdXN0IHRoZSBpbnRlcmZhY2UgdHlwZXMgKHVzaW5nIHdoZW4gaWY6 dHlwZSA9IC4uLikgdGhhdCB0aGUgY29uZmlndXJhdGlvbiBhcHBsaWVzIHRvIHJhdGhlciB0aGFu IGFkZGluZyB0aGVtIHRvIGFsbCBpbnRlcmZhY2VzLiAgRmVlZGJhY2sgd291bGQgYmUgd2VsY29t ZSBvbiB3aGV0aGVyIHRoaXMgYXBwcm9hY2ggaXMgYSBnb29kIGlkZWEvbWFpbnRhaW5hYmxlLg0K PiAgICAtIEZvciBNVFUsIEkndmUgZGVmaW5lZCB0d28gZGlmZmVyZW50IE1UVSBsZWF2ZXMgYmVj YXVzZSBkZXZpY2VzIHByb2dyYW0gaW50ZXJmYWNlIE1UVSBpbiBkaWZmZXJlbnQgd2F5cyBiYXNl ZCBvbiB3aGV0aGVyIHRoZSBjb25maWd1cmVkIE1UVSB2YWx1ZSBpbmNsdWRlcyB0aGUgTDIgaGVh ZGVyIG92ZXJoZWFkIG9yIG5vdC4gIElzIHRoaXMgYSByZWFzb25hYmxlIGFwcHJvYWNoPw0KPg0K PiBUaGFua3MsDQo+IFJvYg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Tue Jul 14 03:52:26 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 E4E781A92E4 for ; Tue, 14 Jul 2015 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.111 X-Spam-Level: X-Spam-Status: No, score=-12.111 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_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, 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 AtymWvtvqLla for ; Tue, 14 Jul 2015 03:52:23 -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 22B361A92E0 for ; Tue, 14 Jul 2015 03:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7656; q=dns/txt; s=iport; t=1436871143; x=1438080743; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4gwHD/qO31feTJlM1h+I/8J4jWptAs0oWgPd7h4Lelg=; b=WNbbdjHq6jCo6CY0GVItQy5RGoQprg4joVqR4cZtWLSmH7Yo6uwjGOV4 KwbnMSQtySLmO6F1ggooGfxVOCOZci+e0RfxK1IbENMC9Yz4fx2Nqalkp 5n1FQarOWvMKmn/J6CxaLVR/3GKCmMDUDo2NJABR+2hxs6jK0Ur5eFrlf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CUAwB16KRV/xbLJq1RCYNnaYMkuC8JgWoKgkOCakoCgX8UAQEBAQEBAYEKhCQBAQQBAQEgDwEFLwcKEQkCGAICBRYIAwICCQMCAQIBFR8RBgEMBgIBAYgqDZkMnRmWSAEBAQEBAQEBAgEBAQEBAQEXBIEiiSiBAoQqY4JogUMBBJQyhGuHG4FAhwUijCiDXyZjgxk9MYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,471,1432598400"; d="scan'208";a="565617412" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Jul 2015 10:52:21 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6EAqKdG029308; Tue, 14 Jul 2015 10:52:21 GMT Message-ID: <55A4E9E5.3050402@cisco.com> Date: Tue, 14 Jul 2015 11:52:21 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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: Tue, 14 Jul 2015 10:52:26 -0000 Hi Michael, Yes, your understanding is right. I've extended your example to hopefully give a bit more clarity. In the PPP module: augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + "if-cmn:encaps-type" { when "../../if:type = 'ianaift:pos'" { // + any other interface types that PPP is supported on. case PPP { container PPP { // All PPP specific configuration goes here. } In the cHDLC module: augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + "if-cmn:encaps-type" { when "../../if:type = 'ianaift:pos'" { // + any other interface types that cHDLC is supported on. case CHDLC { container CHDLC { // All CHDLC specific configuration goes here. } In the Frame Relay module: ... similar to above ... Our aim is: (1) to have a well defined node that indicates what the layer 2 encapsulation is for any interfaces where it may changed/configured. (2) to ensures that an interface only has a single primary layer 2 encapsulation (i.e. an interface cannot be both encaps PPP and CHDLC at the same time). (3) to provide a container to store the layer 2 encapsulation information that reflects the encapsulation that is in effect. (I.e. the model prevents you having PPP configuration on an interface with a CHDLC encapsulation.) Thanks, Rob On 14/07/2015 08:59, wangzitao wrote: > Rob, > > What makes me confuse before is that why not directly use the encapsulation type in iana-if-type? The iana-if-type also provide a lot of encapsulation type such as PPP, Frame Relay, etc. > Now I understood a bit. You want to provide an explicit encapsulation information. For example, for pos interface, you may define the yang model as: > > augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + > "if-cmn:encaps-type" { > when "../../if:type = 'ianaift:pos'" { > case PPP{ > foo;} > ..... > > Which indicate this is a pos interface and it encapsulation is PPP... > Is my understood right? > > Best Regards! > -Michael > > > -----邮件原件----- > 发件人: Robert Wilton [mailto:rwilton@cisco.com] > 发送时间: 2015年7月13日 19:24 > 收件人: wangzitao; netmod@ietf.org > 主题: Re: [netmod] Interface Extensions YANG draft > > Hi Michael, > > Thank you for your comments and review. > > I think that the definition of interface type is a bit vague in that there is a long list of interface types that seem to apply at quite a few different OSI layers! > > But in brief, the way that I perceive interface type is as a static property of an interface, fixed when an interface is created, that defines the flavour of an interface. Where appropriate I would normally relate the ifType to the underlying hardware (e.g. POS, Ethernet, ATM, etc), but there are other software interfaces where the interface type is defining a higher level construct (e.g. a tunnel, or sub-interface, or LAG group interface). > > My definition of encapsulation is that it provided a generic container for holding layer-2 related header information, where that is configurable. In the model that I have defined so far I have only defined the encapsulation node for Ethernet/VLAN sub-interfaces, but the intention is that it would be augmented for cHDLC, PPP, FR and ATM. The example is potentially better illustrated for POS interfaces where the choice of encapsulation can be configured. > > So, if you take a POS interface as an example, then I would expect that the ifType would be fixed as ifType:pos, but the encapsulation of that interface could be cHDLC, PPP or Frame Relay. The layer 2 encapsulation information (such as timers, keepalive settings, crc settings, FR circuit ids) would live under the datalink protocol specific encapsulation node. The encapsulation node itself can be used to determine what layer 2 encapsulation is being used. > > Of course you could put ppp/chdlc/fr under separate containers, but it makes it slightly harder to ensure that an interface only has a single encapsulation configured. Although you could add a must statement to restrict the allowed encapsulations to those known today, it doesn't extend to other encaps types added in future. Having a choice statement effectively enforces the restriction that there can be only one encapsulation on an interface for you. > > Does that alleviate your concern? > > Thanks, > Rob > > > On 13/07/2015 09:42, wangzitao wrote: >> Dear Authors, >> >> I've read your draft-wilton-netmod-intf-ext-yang-00 and have a question: >> What is the difference between encaps-type in your yang model and interface types in RFC7224? >> >> I also read your draft-wilton-netmod-intf-vlan-yangwhich augment the if-cmn as: >> >> augment /if:interfaces/if:interface/if-cmn:encapsulation/ >> if-cmn:encaps-type: >> +--:(vlan) >> +--rw vlan >> +--rw tags >> ...... >> >> But the vlan type have already defined in the RFC7224: >> >> identity l2vlan { >> base iana-interface-type; >> description >> "Layer 2 Virtual LAN using 802.1Q."; >> } >> identity l3ipvlan { >> base iana-interface-type; >> description >> "Layer 3 Virtual LAN using IP."; >> } >> identity l3ipxvlan { >> base iana-interface-type; >> description >> "Layer 3 Virtual LAN using IPX."; >> } >> >> Why not reuse the vlan types definding in RFC7224? And it may simplify the augment target path such as: >> >> augment /if:interfaces/if:interface: >> +--rw encaps-type identityref >> +--rw vlan >> +--rw tags >> ...... >> >> Best Regards! >> -Michael >> >> -----邮件原件----- >> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Robert Wilton >> 发送时间: 2015年7月9日 0:11 >> 收件人: netmod@ietf.org >> 主题: [netmod] Interface Extensions YANG draft >> >> Hi, >> >> I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices. E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses. I am hoping that this draft could be adopted and standardized by the netmod WG. >> >> https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ >> >> Any comments or feedback is appreciated. >> >> Potential points of interest/discussion may be: >> - Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented? >> - We've tried to restrict the leaves to just the interface types (using when if:type = ...) that the configuration applies to rather than adding them to all interfaces. Feedback would be welcome on whether this approach is a good idea/maintainable. >> - For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not. Is this a reasonable approach? >> >> Thanks, >> Rob >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jul 14 06:22: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 92BB81ACD08 for ; Tue, 14 Jul 2015 06:21:59 -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 wjLwi6KT24yY for ; Tue, 14 Jul 2015 06:21:57 -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 157541ACD0A for ; Tue, 14 Jul 2015 06:21:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYT09017; Tue, 14 Jul 2015 13:21:39 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Tue, 14 Jul 2015 14:21:36 +0100 From: Italo Busi To: "Varma, Eve L (Eve)" , "netmod@ietf.org" Thread-Topic: Comments on draft-mansfield-uml-to-yang-00 Thread-Index: AdC7IFQIwGLJvQHoTLSoVx6sNWl0IQCeJajwACfAs+A= Date: Tue, 14 Jul 2015 13:21:36 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B01121EB5@lhreml504-mbs> References: <91E3A1BD737FDF4FA14118387FF6766B0111A421@lhreml504-mbs> <6D32668528F93D449A073F45707153D8BEB84B46@US70UWXCHMBA03.zam.alcatel-lucent.com> In-Reply-To: <6D32668528F93D449A073F45707153D8BEB84B46@US70UWXCHMBA03.zam.alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.144.110] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Comments on draft-mansfield-uml-to-yang-00 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: Tue, 14 Jul 2015 13:21:59 -0000 Ops, you are right Thanks for catching it Italo > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com] > Sent: luned=EC 13 luglio 2015 20:25 > To: Italo Busi; netmod@ietf.org > Subject: RE: Comments on draft-mansfield-uml-to-yang-00 >=20 > Hi Italo, >=20 > Thank you for your very helpful comments! >=20 > Just a quick note - the subsection numbers you commented on seems off by = one. > For example, object class mapping is in Section 5.2, not 5.1; association > mapping is in section 5.5, not 5.4. >=20 > Best regards, > Eve >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Italo Busi > Sent: Friday, July 10, 2015 10:55 AM > To: netmod@ietf.org > Subject: [netmod] Comments on draft-mansfield-uml-to-yang-00 >=20 > Dear authors of draft-mansfield-uml-to-yang, >=20 > I think this draft is very useful in assisting translation between UML IM= s > and Yang DMs. Since many UML IMs have been already defined, this I-D woul= d > help in simplifying development and/or gap analysis of new Yang DMs. >=20 > It also complements the work on the suite of translation drafts developed= or > under development in the NETMOD WG (e.g., RFC 6643 and draft-ietf-netmod- > yang-json). >=20 > I have started to read the draft and have got an initial set of comments = I > would like to share (further comments may follow while I continue reviewi= ng > the draft). >=20 > Appendix A is very helpful to see how the different mapping rules work. I= t > would be worth enhancing it with some further detailed descriptions also > referencing the YANG Module and not only the YANG tree of draft-dharini- > netmod-g-698-2-yang-04. >=20 > It seems that section 5 of this I-D is describing the mapping between the > UML artifacts defined in section 5 of TR-514. It would be worth adding so= me > text to clarify this point. >=20 > It seems that section 5.1 of this I-D is describing how the Object Class = UML > artifact described in section 5.1 of TR-514 is mapped into YANG statement= s. >=20 > In particular, an Object Class UML artifact can be mapped either to a "li= st" > or to a "container" YANG statement. The I-D does not describe when (i.e., > under which condition) a "list" or a "container" statement should be used= . > Are both approaches equivalent or is there a criteria for using one or ot= her > approach depending on some characteristics of the Object Class? >=20 > Looking YANG module in the appendix A example (draft-dharini-netmod-g-698= -2- > yang-04), it seems that the superclass property of an Object Class artifa= ct > is not explicitly defined but it is inferred from the structure of the > "augment" and "container" statements: >=20 > augment "/if:interfaces/if:interface" { > description "Parameters for an optical interface"; > container optIfOChRsSs { > description "RsSs path configuration for an interface"; > <...> > } >=20 > Looking at this example, it is also worth noting that the documentation > property of the optIfOChRsSs Object Class maps to the "description" > substatement below the "container optIfOChRsSs" statement (i.e., descript= ion > "RsSs path configuration for an interface";). The other description > statement (i.e., description "Parameters for an optical interface";) is > mapping the documentation property of the inheritance relationship. >=20 > It would be worth updating Section 5.4 to describe how the properties of = the > Association UML artifacts maps into substatements of the YANG statements = as > well as updating appendix A to describe the example above. >=20 > Is it possible to map into YANG an UML Object Class that inherits from mo= re > than one superclass? >=20 > Just a nit: I think that reference [7] is not an OMG document >=20 > Thanks, Italo >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jul 14 06:26:17 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 722A21ACD11 for ; Tue, 14 Jul 2015 06:26:16 -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 z-CPf3Uc4Vjv for ; Tue, 14 Jul 2015 06:26:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 707531ACCE7 for ; Tue, 14 Jul 2015 06:26:14 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 23B781CC024F for ; Tue, 14 Jul 2015 15:26:14 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 14 Jul 2015 15:26:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] ACL model problem 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: Tue, 14 Jul 2015 13:26:16 -0000 Hi, the module ietf-packet-fields.yang in draft-ietf-netmod-acl-model-03 still has the problem that I discovered in the previous revision: - Containers "source-port-range" and "destination-port-range" are both mandatory because the child leaf "lower-port" in each is mandatory. I think this wasn't intended. One solution would be to make both of them containers with presence. (see https://mailarchive.ietf.org/arch/msg/netmod/ShROtXH7aMNDs5HoIiTUa99X0JY) Even though the tree in sec. 3.1 displays "lower-port" as optional, in reality ietf-packet-fields.yang still has this leaf as "mandatory true;" in both "source-port-range" and "destination-port-range". Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 14 06:57:19 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 77A6F1ACD4E for ; Tue, 14 Jul 2015 06:57: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] 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 CkQSNFN6QmvS for ; Tue, 14 Jul 2015 06:57:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0528A1ACD4A for ; Tue, 14 Jul 2015 06:57:15 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id CA35F1CC024F for ; Tue, 14 Jul 2015 15:57:16 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 14 Jul 2015 15:57:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] example in draft-ietf-netmod-syslog-model-04 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: Tue, 14 Jul 2015 13:57:17 -0000 Hi, the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is invalid: the value of "severity" should be "critical" rather than "syslogtypes:critical". Enums are simple strings, not QNames. Also, I wonder why the type of "severity" is defined (in multiple places) like so: type union { type syslogtypes:severity; type enumeration { enum all { value -1; description "This enum describes the case where all severities are requested."; } } I think the "all" enum can be simply added to the "syslogtypes:severity" enumeration. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 14 08:25:34 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 E04311ACD55 for ; Tue, 14 Jul 2015 08:25:32 -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 W6zBBSnqITb5 for ; Tue, 14 Jul 2015 08:25:31 -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 1D5351ACE31 for ; Tue, 14 Jul 2015 08:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1770; q=dns/txt; s=iport; t=1436887531; x=1438097131; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iNNa6rSKWd8IE4O651qGGwsUu8KfMwHI9a2DeiwCMHc=; b=bZae99GcUQrSlD8KxCBilrlN3Pezcz9iHWYC8On3LxY6W4b8M7J7BnKR zFqrFWxnR185STflLgGNNBlb9CX85oDh62u50rlVXdHkDhhtwZN7P43mb RSvgScebcSeJGCitI4i1ugOAMmNxgoH30gK63ZtacqwxXAlzdf2T3iAml c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkAwDzKKVV/4gNJK1bgxNUaQaDHrgyCYFqCoUtSgIcgS84FAEBAQEBAQGBCoQkAQEEAQEBIBE6GwIBCBoCJgICAiULFRACBAESiC4NuEKWRQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKKoUNgmgvgRQFkUiCagGMBYFAhBiPN4NfJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,472,1432598400"; d="scan'208";a="11577776" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jul 2015 15:25:30 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6EFPUgg018110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jul 2015 15:25:30 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.211]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Tue, 14 Jul 2015 10:25:30 -0500 From: "Clyde Wildes (cwildes)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] example in draft-ietf-netmod-syslog-model-04 Thread-Index: AQHQvj0Ew1ZZVRJB20KhZAh26IJmTZ3a9JwA Date: Tue, 14 Jul 2015 15:25:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.181] Content-Type: text/plain; charset="utf-8" Content-ID: <575CDD4EDC016B4A920E99E37058D0A6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] example in draft-ietf-netmod-syslog-model-04 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: Tue, 14 Jul 2015 15:25:33 -0000 TGFkYSwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KQWxsIHdhcyBub3QgYWRkZWQgdG8g dGhlIHN5c2xvZ3R5cGVzOnNldmVyaXR5IGJlY2F1c2UgdGhhdCB3b3VsZCBhbHRlciB0aGUgZGVm aW5pdGlvbiBvZiBzZXZlcml0eSBhcyBzcGVjaWZpZWQgYnkgUkZDIDU0MjQgaW4gVGFibGUgMiBv biBwYWdlIDEwLiBJIGFncmVlIHRoYXQgaXQgd2lsbCBzaW1wbGlmeSB0aGUgbW9kZWwgdG8gZG8g c28uDQoNClBsZWFzZSBhZHZpc2UuDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0KDQoNCk9uIDcvMTQv MTUsIDY6NTcgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSIgPG5ldG1v ZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCg0K PkhpLA0KPg0KPnRoZSBleGFtcGxlIGluIHNlYy4gNC4zIG9mIGRyYWZ0LWlldGYtbmV0bW9kLXN5 c2xvZy1tb2RlbC0wNCBpcw0KPmludmFsaWQ6IHRoZSB2YWx1ZSBvZiAic2V2ZXJpdHkiIHNob3Vs ZCBiZSAiY3JpdGljYWwiIHJhdGhlciB0aGFuDQo+InN5c2xvZ3R5cGVzOmNyaXRpY2FsIi4gRW51 bXMgYXJlIHNpbXBsZSBzdHJpbmdzLCBub3QgUU5hbWVzLg0KPg0KPkFsc28sIEkgd29uZGVyIHdo eSB0aGUgdHlwZSBvZiAic2V2ZXJpdHkiIGlzIGRlZmluZWQgKGluIG11bHRpcGxlDQo+cGxhY2Vz KSBsaWtlIHNvOg0KPg0KPiAgICAgIHR5cGUgdW5pb24gew0KPiAgICAgICAgdHlwZSBzeXNsb2d0 eXBlczpzZXZlcml0eTsNCj4gICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiAgICAgICAgICBl bnVtIGFsbCB7DQo+ICAgICAgICAgICAgdmFsdWUgLTE7DQo+ICAgICAgICAgICAgZGVzY3JpcHRp b24NCj4gICAgICAgICAgICAgICJUaGlzIGVudW0gZGVzY3JpYmVzIHRoZSBjYXNlIHdoZXJlIGFs bCBzZXZlcml0aWVzIA0KPiAgICAgICAgICAgICAgIGFyZSByZXF1ZXN0ZWQuIjsNCj4gICAgICAg ICAgfQ0KPiAgICAgICAgfQ0KPg0KPkkgdGhpbmsgdGhlICJhbGwiIGVudW0gY2FuIGJlIHNpbXBs eSBhZGRlZCB0byB0aGUgInN5c2xvZ3R5cGVzOnNldmVyaXR5Ig0KPmVudW1lcmF0aW9uLg0KPg0K PkxhZGENCj4NCj4tLSANCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJ RDogRTc0RThDMEMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Tue Jul 14 09:03:49 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 51C781A1B30 for ; Tue, 14 Jul 2015 09:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 MDEVa2cFcpyv for ; Tue, 14 Jul 2015 09:03:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9CB1A1B81 for ; Tue, 14 Jul 2015 09:03:46 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:c9a9:2878:8fd:b0c8] (unknown [IPv6:2a01:5e0:29:ffff:c9a9:2878:8fd:b0c8]) by mail.nic.cz (Postfix) with ESMTPSA id BEA7518114E; Tue, 14 Jul 2015 18:03:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1436889824; bh=xMDENXibd6c+PCL15p+rEetcyXEE5brOyIJ0zgFcPZI=; h=From:Date:To; b=o6So+Kn/+bMwF7Ntjx5Vo1tzMxnLnBw8VO4vNNLSqO/Po+byA21CVsmwAeVCkWzFv bh97HtMCWW7CAp7ZVi+cRN6BoJoN+VKwlx3UbNDMEd0PqWCT20/HAHthjj/AbpRBOd sEdm3b+haSEczirA2uUISd4tHSRMXcE2BqJv6aQU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 14 Jul 2015 18:03:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B71B659-529A-45D3-8AE5-E9F8D6D45FBF@nic.cz> References: To: "Clyde Wildes (cwildes)" X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] example in draft-ietf-netmod-syslog-model-04 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: Tue, 14 Jul 2015 16:03:48 -0000 > On 14 Jul 2015, at 17:25, Clyde Wildes (cwildes) = wrote: >=20 > Lada, >=20 > Thanks for your review. >=20 > All was not added to the syslogtypes:severity because that would alter = the definition of severity as specified by RFC 5424 in Table 2 on page = 10. I agree that it will simplify the model to do so. The description of the =E2=80=9Cseverity=E2=80=9D leaf says: When severity is specified the default severity comparison is all = messages of the specified severity and greater are logged unless all is = specified which means all severities are requested. Isn=E2=80=99t then =E2=80=9Cdebug=E2=80=9D equivalent to =E2=80=9Call=E2=80= =9D, i.e. is the =E2=80=9Call=E2=80=9D option really needed? >=20 > Please advise. I would do a similar thing that you did for facilities: choice between = =E2=80=9Cseverity=E2=80=9D (with the type =E2=80=9Csyslogtypes:severity=E2= =80=9D) and an empty leaf "all-severities=E2=80=9D. Lada >=20 > Thanks, >=20 > Clyde >=20 >=20 >=20 > On 7/14/15, 6:57 AM, "netmod on behalf of Ladislav Lhotka" = wrote: >=20 >> Hi, >>=20 >> the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is >> invalid: the value of "severity" should be "critical" rather than >> "syslogtypes:critical". Enums are simple strings, not QNames. >>=20 >> Also, I wonder why the type of "severity" is defined (in multiple >> places) like so: >>=20 >> type union { >> type syslogtypes:severity; >> type enumeration { >> enum all { >> value -1; >> description >> "This enum describes the case where all severities=20 >> are requested."; >> } >> } >>=20 >> I think the "all" enum can be simply added to the = "syslogtypes:severity" >> enumeration. >>=20 >> Lada >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 14 09:21: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 5B8C01A3B9D for ; Tue, 14 Jul 2015 09:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, 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 BYsXv5ymod9w for ; Tue, 14 Jul 2015 09:21:32 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90531A1EF9 for ; Tue, 14 Jul 2015 09:21:32 -0700 (PDT) Received: by pdbqm3 with SMTP id qm3so8373265pdb.0 for ; Tue, 14 Jul 2015 09:21:32 -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=GEMoBkqlTFbhuE1QioboyP/+RhYRN63SgJNTiCU99t8=; b=cxhWAuslw2eQ+HnPmryNvcQWqLf+mOMTbhushWAxpu/uf/ypA+frGaSv4ERWn0Kulf tinKDq92g4LKte9KeizijiLAzo8TleBIRbo8aA+yyVuM3e0O8IN0uuTi1eBqG/kjY75C 5TYgR7soSjaCcURhlIywaMgCG58fORExyg/Twaqe2LSw0ZH4BzwK5yxzA76QceHmnE2u cc4Q755oAGLcj09wPjXzrjsS6L4wTDBP0zt1f8c3K3OmcuzghNl8iktgp20zyUQsUr6N C9WhnumGgpltmuQfYyJe3zhfPwT6LExEm3IS+8ZYuUYRzX8jlCH7hXZUzzasj0bkEb8/ XS1A== X-Received: by 10.66.119.239 with SMTP id kx15mr82673813pab.156.1436890892253; Tue, 14 Jul 2015 09:21:32 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:4058:3fec:7595:5f5c]) by smtp.gmail.com with ESMTPSA id fr2sm1859070pdb.22.2015.07.14.09.21.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Jul 2015 09:21:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6FBEB50-8B10-494F-BD44-178BCF37AC74" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <559D4BA1.30605@cisco.com> Date: Tue, 14 Jul 2015 09:21:30 -0700 Message-Id: <57E9F3A1-6F47-4977-9904-E0B16B3BD6F4@gmail.com> References: <559D4BA1.30605@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Interface Extensions YANG draft 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: Tue, 14 Jul 2015 16:21:34 -0000 --Apple-Mail=_F6FBEB50-8B10-494F-BD44-178BCF37AC74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robert, I have read your draft and consider it useful for folks who are trying = to use/configure/monitor particular characteristics of a physical = interface. While it is an extension of the interfaces module, a lot of = modules are extensions of the interface module. A more appropriate name = would probably help convey the contents of the module. How about = physical-interface-extensions or phys-intr-ext for short? More comments on the draft. 3.2. Is there a counter kept for the actual short transition changes that = were suppressed? 3.6 The general suggestion in YANG is to provide for one way to do things, = and leave other ways of specifying or configuring to = extensions/deviations etc. With that in mind, I would think keeping one = leaf for MTU that is the max. size of the layer 2 frame including header = and payload would make sense. 4. I am not a particular fan of creating yet another module for = ethernet-like interfaces, when I assume there is going to be a = ethernet-interface module. Is there something in this module that cannot = be minimally represented by a more general IEEE ethernet-interface = module? Thanks. > On Jul 8, 2015, at 9:11 AM, Robert Wilton wrote: >=20 > Hi, >=20 > I have submitted a new draft for provides several augmentations to the = ietf if:interfaces to define configuration YANG for basic interface = parameters that are commonly supported on network devices. E.g. it is = includes leaves such as bandwidth, carrier delay, dampening, loopback, = mtu, & sub-interface parent ref, and configurable interface MAC = addresses. I am hoping that this draft could be adopted and = standardized by the netmod WG. >=20 > https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ >=20 > Any comments or feedback is appreciated. >=20 > Potential points of interest/discussion may be: > - Is it acceptable to define standard YANG for features that are not = backed by any formal standard if they are commonly implemented? > - We've tried to restrict the leaves to just the interface types = (using when if:type =3D ...) that the configuration applies to rather = than adding them to all interfaces. Feedback would be welcome on = whether this approach is a good idea/maintainable. > - For MTU, I've defined two different MTU leaves because devices = program interface MTU in different ways based on whether the configured = MTU value includes the L2 header overhead or not. Is this a reasonable = approach? >=20 > Thanks, > Rob >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F6FBEB50-8B10-494F-BD44-178BCF37AC74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Robert,

I = have read your draft and consider it useful for folks who are trying to = use/configure/monitor particular characteristics of a physical = interface. While it is an extension of the interfaces module, a lot of = modules are extensions of the interface module. A more appropriate name = would probably help convey the contents of the module. How about = physical-interface-extensions or phys-intr-ext for short?

More comments on the = draft.

3.2.

Is there a counter kept for the actual short transition = changes that were suppressed?


3.6

The general suggestion in YANG is to provide for one way to = do things, and leave other ways of specifying or configuring to = extensions/deviations etc. With that in mind, I would think keeping one = leaf for MTU that is the max. size of the layer 2 frame including header = and payload would make sense.

4.

I am not a particular fan of creating = yet another module for ethernet-like interfaces, when I assume there is = going to be a ethernet-interface module. Is there something in this = module that cannot be minimally represented by a more general IEEE = ethernet-interface module?

Thanks.

On Jul 8, 2015, at 9:11 AM, = Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I have submitted a new draft for provides several = augmentations to the ietf if:interfaces to define configuration YANG for = basic interface parameters that are commonly supported on network = devices.  E.g. it is includes leaves such as bandwidth, carrier = delay, dampening, loopback, mtu, & sub-interface parent ref, and = configurable interface MAC addresses.  I am hoping that this draft = could be adopted and standardized by the netmod WG.

https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-y= ang/

Any comments or feedback is = appreciated.

Potential points of = interest/discussion may be:
- Is it acceptable to define = standard YANG for features that are not backed by any formal standard if = they are commonly implemented?
- We've tried to restrict = the leaves to just the interface types (using when if:type =3D ...) that = the configuration applies to rather than adding them to all interfaces. =  Feedback would be welcome on whether this approach is a good = idea/maintainable.
- For MTU, I've defined two different = MTU leaves because devices program interface MTU in different ways based = on whether the configured MTU value includes the L2 header overhead or = not.  Is this a reasonable approach?

Thanks,
Rob

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_F6FBEB50-8B10-494F-BD44-178BCF37AC74-- From nobody Tue Jul 14 10:21:36 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 88E841ACE38 for ; Tue, 14 Jul 2015 10:21:34 -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 G1JGMW6fwaA2 for ; Tue, 14 Jul 2015 10:21:32 -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 D05721ACEE8 for ; Tue, 14 Jul 2015 10:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3700; q=dns/txt; s=iport; t=1436894467; x=1438104067; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GxvHbjo8Y3QMJzKPPWxJMRNzbREql9swxEMf799uQgs=; b=HchvXR7W6arF3X+r7Tr1j9FJjcVbe/zPQCXEFJlW4WO3Mc0UkorC7zWA tUNhHIUvtc8GEkawCqwG4K4XrBR/5cNZe6qpfiY+R3GTVFunW80VFYakB iqquCcWXuYSIkFvq1NRrE+2HMqeEnHcmr5HnuUoSPnPMCy/2UBGk2KE3s U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkAwBPRKVV/5FdJa1bgxNUaQaDHrgwCYFqCoUtSgIcgTA4FAEBAQEBAQGBCoQjAQEBAwEBAQEgEToLEAIBCBgCAiYCAgIlCxUQAgQOBYgmCA24apZDAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EiiiqFBgeCaC+BFAWUMgGMBYFAhBiPN4NfJoIMHIFTbwGBRoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,473,1432598400"; d="scan'208";a="15350204" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2015 17:21:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6EHL4c2021943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jul 2015 17:21:04 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.211]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 14 Jul 2015 12:21:04 -0500 From: "Clyde Wildes (cwildes)" To: Ladislav Lhotka Thread-Topic: [netmod] example in draft-ietf-netmod-syslog-model-04 Thread-Index: AQHQvj0Ew1ZZVRJB20KhZAh26IJmTZ3a9JwAgACADwD//6A+AA== Date: Tue, 14 Jul 2015 17:21:03 +0000 Message-ID: <5925FE32-6462-4226-A49C-E27E707B0D27@cisco.com> References: <1B71B659-529A-45D3-8AE5-E9F8D6D45FBF@nic.cz> In-Reply-To: <1B71B659-529A-45D3-8AE5-E9F8D6D45FBF@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.181] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] example in draft-ietf-netmod-syslog-model-04 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: Tue, 14 Jul 2015 17:21:34 -0000 TGFkYSwNCg0KSSB3b3VsZCBwcmVmZXIgYSBzcGVjaWZpY2F0aW9uIHRoYXQgZGVjbGFyZXMgdGhl ICJhbGwiIGludGVudCBpbnN0ZWFkIG9mIHJlbHlpbmcgb24gImRlYnVnIiBtZWFuaW5nIGFsbCBt ZXNzYWdlcy4gQSBudW1iZXIgc3lzbG9nIGltcGxlbWVudGF0aW9ucyBzcGVjaWZ5IGEgc2V2ZXJp dHkgb2YgImFsbCIuIEV4YW1wbGU6IHJzeXNsb2cgLSBodHRwOi8vd3d3LnJzeXNsb2cuY29tL2Rv Yy92OC1zdGFibGUvY29uZmlndXJhdGlvbi9maWx0ZXJzLmh0bWwuDQoNCkkgdXNlZCB0aGUgdW5p b24gYXBwcm9hY2ggYmVjYXVzZSwgaW4gYW4gZWFybGllciByZXZpZXcsIEphbiBMaW5kYmxhZCBz dWdnZXN0ZWQgaXQgYXMgYSBzaW1wbGUgbWV0aG9kIHRvIGFkZCBhbGwgd2l0aG91dCBjb21wcm9t aXNpbmcgdGhlIFJGQyBkZWZpbml0aW9uIG9mIFNldmVyaXR5LiBIaXMgcG9pbnQgd2FzIHRoYXQg YWRkaW5nIGEgY2hvaWNlIGlzIGEgY29tcGxpY2F0aW9uLg0KDQpUaGFua3MsDQoNCkNseWRlDQoN Cg0KDQoNCk9uIDcvMTQvMTUsIDk6MDMgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmlj LmN6PiB3cm90ZToNCg0KPg0KPj4gT24gMTQgSnVsIDIwMTUsIGF0IDE3OjI1LCBDbHlkZSBXaWxk ZXMgKGN3aWxkZXMpIDxjd2lsZGVzQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+IExhZGEsDQo+ PiANCj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcuDQo+PiANCj4+IEFsbCB3YXMgbm90IGFkZGVk IHRvIHRoZSBzeXNsb2d0eXBlczpzZXZlcml0eSBiZWNhdXNlIHRoYXQgd291bGQgYWx0ZXIgdGhl IGRlZmluaXRpb24gb2Ygc2V2ZXJpdHkgYXMgc3BlY2lmaWVkIGJ5IFJGQyA1NDI0IGluIFRhYmxl IDIgb24gcGFnZSAxMC4gSSBhZ3JlZSB0aGF0IGl0IHdpbGwgc2ltcGxpZnkgdGhlIG1vZGVsIHRv IGRvIHNvLg0KPg0KPlRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg4oCcc2V2ZXJpdHnigJ0gbGVhZiBz YXlzOg0KPg0KPldoZW4gc2V2ZXJpdHkgaXMgc3BlY2lmaWVkIHRoZSBkZWZhdWx0IHNldmVyaXR5 IGNvbXBhcmlzb24gaXMgYWxsIG1lc3NhZ2VzIG9mIHRoZSBzcGVjaWZpZWQgc2V2ZXJpdHkgYW5k IGdyZWF0ZXIgYXJlIGxvZ2dlZCB1bmxlc3MgYWxsIGlzIHNwZWNpZmllZCB3aGljaCBtZWFucyBh bGwgc2V2ZXJpdGllcyBhcmUgcmVxdWVzdGVkLg0KPg0KPklzbuKAmXQgdGhlbiDigJxkZWJ1Z+KA nSBlcXVpdmFsZW50IHRvIOKAnGFsbOKAnSwgaS5lLiBpcyB0aGUg4oCcYWxs4oCdIG9wdGlvbiBy ZWFsbHkgbmVlZGVkPw0KPg0KPj4gDQo+PiBQbGVhc2UgYWR2aXNlLg0KPg0KPkkgd291bGQgZG8g YSBzaW1pbGFyIHRoaW5nIHRoYXQgeW91IGRpZCBmb3IgZmFjaWxpdGllczogY2hvaWNlIGJldHdl ZW4g4oCcc2V2ZXJpdHnigJ0gKHdpdGggdGhlIHR5cGUg4oCcc3lzbG9ndHlwZXM6c2V2ZXJpdHni gJ0pIGFuZCBhbiBlbXB0eSBsZWFmICJhbGwtc2V2ZXJpdGllc+KAnS4NCj4NCj5MYWRhDQo+DQo+ PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gQ2x5ZGUNCj4+IA0KPj4gDQo+PiANCj4+IE9uIDcvMTQv MTUsIDY6NTcgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSIgPG5ldG1v ZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+ IA0KPj4+IEhpLA0KPj4+IA0KPj4+IHRoZSBleGFtcGxlIGluIHNlYy4gNC4zIG9mIGRyYWZ0LWll dGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0wNCBpcw0KPj4+IGludmFsaWQ6IHRoZSB2YWx1ZSBvZiAi c2V2ZXJpdHkiIHNob3VsZCBiZSAiY3JpdGljYWwiIHJhdGhlciB0aGFuDQo+Pj4gInN5c2xvZ3R5 cGVzOmNyaXRpY2FsIi4gRW51bXMgYXJlIHNpbXBsZSBzdHJpbmdzLCBub3QgUU5hbWVzLg0KPj4+ IA0KPj4+IEFsc28sIEkgd29uZGVyIHdoeSB0aGUgdHlwZSBvZiAic2V2ZXJpdHkiIGlzIGRlZmlu ZWQgKGluIG11bHRpcGxlDQo+Pj4gcGxhY2VzKSBsaWtlIHNvOg0KPj4+IA0KPj4+ICAgICB0eXBl IHVuaW9uIHsNCj4+PiAgICAgICB0eXBlIHN5c2xvZ3R5cGVzOnNldmVyaXR5Ow0KPj4+ICAgICAg IHR5cGUgZW51bWVyYXRpb24gew0KPj4+ICAgICAgICAgZW51bSBhbGwgew0KPj4+ICAgICAgICAg ICB2YWx1ZSAtMTsNCj4+PiAgICAgICAgICAgZGVzY3JpcHRpb24NCj4+PiAgICAgICAgICAgICAi VGhpcyBlbnVtIGRlc2NyaWJlcyB0aGUgY2FzZSB3aGVyZSBhbGwgc2V2ZXJpdGllcyANCj4+PiAg ICAgICAgICAgICAgYXJlIHJlcXVlc3RlZC4iOw0KPj4+ICAgICAgICAgfQ0KPj4+ICAgICAgIH0N Cj4+PiANCj4+PiBJIHRoaW5rIHRoZSAiYWxsIiBlbnVtIGNhbiBiZSBzaW1wbHkgYWRkZWQgdG8g dGhlICJzeXNsb2d0eXBlczpzZXZlcml0eSINCj4+PiBlbnVtZXJhdGlvbi4NCj4+PiANCj4+PiBM YWRhDQo+Pj4gDQo+Pj4gLS0gDQo+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+ IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0 bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCj4NCj4tLQ0KPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElE OiBFNzRFOEMwQw0KPg0KPg0KPg0KPg0K From nobody Tue Jul 14 10:29:15 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 6975A1ACEE3 for ; Tue, 14 Jul 2015 10:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 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, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, 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 tvsrjnVuD1iq for ; Tue, 14 Jul 2015 10:29:12 -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 61EF41ACEE1 for ; Tue, 14 Jul 2015 10:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14059; q=dns/txt; s=iport; t=1436894951; x=1438104551; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=uNA+uem6f6tQiKDeP1EfZctCXz/fN+HQahl4SadZ4K4=; b=eh8gT5DLyls+qMdaXBgmwi4elqADWM2H48TVCkzuDu7Dwpj0it6lR5s0 9Qt0+Zoq2CfYg9FTkrCPgYCQ7BoOJy3GUNDaMcOGG8fQiA9N2znXtbNgO +P7Dj3PmikGgmkSAUbgU4ygaXM/+xdwvxSXxnnrqfbHAhYFDqhfEJmYgO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DiAgBURaVV/xbLJq1bg2dpu1QJgWoBCYUtSgKCBBQBAQEBAQEBgQqEIwEBAQMBAQEBZAcKARALDgoJFggHCQMCAQIBDwYfEQYNAQUCAQGIFQMKCA3JYw2FRAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yCTYI5B4QrBYwshRyCaoRrhTWBZoFAhBiCbSKIZINEg18mY4MZPTGCSwEBAQ X-IronPort-AV: E=Sophos;i="5.15,473,1432598400"; d="scan'208,217";a="565935227" 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 Jul 2015 17:29:09 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6EHT82L016052; Tue, 14 Jul 2015 17:29:09 GMT Message-ID: <55A546E4.8010708@cisco.com> Date: Tue, 14 Jul 2015 18:29:08 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mahesh Jethanandani References: <559D4BA1.30605@cisco.com> <57E9F3A1-6F47-4977-9904-E0B16B3BD6F4@gmail.com> In-Reply-To: <57E9F3A1-6F47-4977-9904-E0B16B3BD6F4@gmail.com> Content-Type: multipart/alternative; boundary="------------060404070705070302040408" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Interface Extensions YANG draft 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: Tue, 14 Jul 2015 17:29:14 -0000 This is a multi-part message in MIME format. --------------060404070705070302040408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Mahesh, Thanks for the comments. Please see inline ... On 14/07/2015 17:21, Mahesh Jethanandani wrote: > Robert, > > I have read your draft and consider it useful for folks who are trying > to use/configure/monitor particular characteristics of a physical > interface. While it is an extension of the interfaces module, a lot of > modules are extensions of the interface module. A more appropriate > name would probably help convey the contents of the module. How about > physical-interface-extensions or phys-intr-ext for short? Yes, I agree that a better name would be helpful, and definitely welcome suggestions. The problem is that the module doesn't just apply to physical interfaces. Quite a lot of the properties apply to any interface on a router/switch, and some of the properties I would think could apply to any network interface (e.g. MTU). Perhaps something related to lower-layer-interface-extensions? > > More comments on the draft. > > 3.2. > > Is there a counter kept for the actual short transition changes that > were suppressed? Yes, there should be. I had initially concentrated on the config side, but probably operation data needs to be considered as well. > > > 3.6 > > The general suggestion in YANG is to provide for one way to do things, > and leave other ways of specifying or configuring to > extensions/deviations etc. With that in mind, I would think keeping > one leaf for MTU that is the max. size of the layer 2 frame including > header and payload would make sense. OK. Yes, I think that I'm coming to the same conclusion: Although having a single MTU value will make it harder to implement for some vendors, it makes it easier for users of the YANG module. > > 4. > > I am not a particular fan of creating yet another module for > ethernet-like interfaces, when I assume there is going to be a > ethernet-interface module. Is there something in this module that > cannot be minimally represented by a more general IEEE > ethernet-interface module? I don't envisage there needing to be any additional configuration in the Ethernet-like module beyond what is already there - possibly some Ethernet framing related statistics. There are a few reasons that I put this in a separate module to ethernet: 1) It doesn't just apply to 802.3 Ethernet interfaces, but any interfaces that use Ethernet framing. 2) I wasn't sure whether the IEEE 802.3 WG would want to standardize a module that covers other interface types beyond native Ethernet. 3) There is already an etherlike.mib (although that only covers stats that applies to any Ethernet framed interfaces). Is your primary concern over the fact that this module is too small to justify its independent existence? Thanks, Rob > > Thanks. > >> On Jul 8, 2015, at 9:11 AM, Robert Wilton > > wrote: >> >> Hi, >> >> I have submitted a new draft for provides several augmentations to >> the ietf if:interfaces to define configuration YANG for basic >> interface parameters that are commonly supported on network devices. >> E.g. it is includes leaves such as bandwidth, carrier delay, >> dampening, loopback, mtu, & sub-interface parent ref, and >> configurable interface MAC addresses. I am hoping that this draft >> could be adopted and standardized by the netmod WG. >> >> https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ >> >> Any comments or feedback is appreciated. >> >> Potential points of interest/discussion may be: >> - Is it acceptable to define standard YANG for features that are not >> backed by any formal standard if they are commonly implemented? >> - We've tried to restrict the leaves to just the interface types >> (using when if:type = ...) that the configuration applies to rather >> than adding them to all interfaces. Feedback would be welcome on >> whether this approach is a good idea/maintainable. >> - For MTU, I've defined two different MTU leaves because devices >> program interface MTU in different ways based on whether the >> configured MTU value includes the L2 header overhead or not. Is this >> a reasonable approach? >> >> Thanks, >> Rob >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > --------------060404070705070302040408 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Mahesh,

Thanks for the comments. Please see inline ...

On 14/07/2015 17:21, Mahesh Jethanandani wrote:
Robert,

I have read your draft and consider it useful for folks who are trying to use/configure/monitor particular characteristics of a physical interface. While it is an extension of the interfaces module, a lot of modules are extensions of the interface module. A more appropriate name would probably help convey the contents of the module. How about physical-interface-extensions or phys-intr-ext for short?

Yes, I agree that a better name would be helpful, and definitely welcome suggestions. The problem is that the module doesn't just apply to physical interfaces. Quite a lot of the properties apply to any interface on a router/switch, and some of the properties I would think could apply to any network interface (e.g. MTU). Perhaps something related to lower-layer-interface-extensions?


More comments on the draft.

3.2.

Is there a counter kept for the actual short transition changes that were suppressed?

Yes, there should be. I had initially concentrated on the config side, but probably operation data needs to be considered as well.



3.6

The general suggestion in YANG is to provide for one way to do things, and leave other ways of specifying or configuring to extensions/deviations etc. With that in mind, I would think keeping one leaf for MTU that is the max. size of the layer 2 frame including header and payload would make sense.
OK. Yes, I think that I'm coming to the same conclusion: Although having a single MTU value will make it harder to implement for some vendors, it makes it easier for users of the YANG module.


4.

I am not a particular fan of creating yet another module for ethernet-like interfaces, when I assume there is going to be a ethernet-interface module. Is there something in this module that cannot be minimally represented by a more general IEEE ethernet-interface module?

I don't envisage there needing to be any additional configuration in the Ethernet-like module beyond what is already there - possibly some Ethernet framing related statistics.

There are a few reasons that I put this in a separate module to ethernet:
1) It doesn't just apply to 802.3 Ethernet interfaces, but any interfaces that use Ethernet framing.
2) I wasn't sure whether the IEEE 802.3 WG would want to standardize a module that covers other interface types beyond native Ethernet.
3) There is already an etherlike.mib (although that only covers stats that applies to any Ethernet framed interfaces).

Is your primary concern over the fact that this module is too small to justify its independent existence?

Thanks,
Rob



Thanks.

On Jul 8, 2015, at 9:11 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices. E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses. I am hoping that this draft could be adopted and standardized by the netmod WG.

https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/

Any comments or feedback is appreciated.

Potential points of interest/discussion may be:
- Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented?
- We've tried to restrict the leaves to just the interface types (using when if:type = ...) that the configuration applies to rather than adding them to all interfaces. Feedback would be welcome on whether this approach is a good idea/maintainable.
- For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not. Is this a reasonable approach?

Thanks,
Rob

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

Mahesh Jethanandani






--------------060404070705070302040408-- From nobody Tue Jul 14 11:12: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 7C2E71AD372 for ; Tue, 14 Jul 2015 11:12: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 baF08-hkczHK for ; Tue, 14 Jul 2015 11:12:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714511AD369 for ; Tue, 14 Jul 2015 11:12:38 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 69319180F28; Tue, 14 Jul 2015 20:12:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1436897557; bh=iUPG0CaUffnrYD29f5FTIaiN5IF4YSQ7J8lBh4X1bc0=; h=From:Date:To; b=TiPjaAR1SIPHT5NRXw6fn6XzXrxd+mGOoy6Pnr2ZGZn6GYwOIJY/huEB2mBp7t1nS 4Lr67dZNOmUgwvzU5KfSbbnjy9FF7Zym3/6axGyjH1VPSXFZBHgL/4cr/BZVfLs2DV m1y4d9bNdChDE+bwKA9GBxz9+93iFhBNmuCtvhbE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <5925FE32-6462-4226-A49C-E27E707B0D27@cisco.com> Date: Tue, 14 Jul 2015 20:12:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5481B9D9-40A5-462D-A2BC-CE82E5E0AFE4@nic.cz> References: <1B71B659-529A-45D3-8AE5-E9F8D6D45FBF@nic.cz> <5925FE32-6462-4226-A49C-E27E707B0D27@cisco.com> To: "Clyde Wildes (cwildes)" X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] example in draft-ietf-netmod-syslog-model-04 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: Tue, 14 Jul 2015 18:12:41 -0000 > On 14 Jul 2015, at 19:21, Clyde Wildes (cwildes) = wrote: >=20 > Lada, >=20 > I would prefer a specification that declares the "all" intent instead = of relying on "debug" meaning all messages. A number syslog = implementations specify a severity of "all". Example: rsyslog - = http://www.rsyslog.com/doc/v8-stable/configuration/filters.html. >=20 > I used the union approach because, in an earlier review, Jan Lindblad = suggested it as a simple method to add all without compromising the RFC = definition of Severity. His point was that adding a choice is a = complication. OK, I just expressed my opinion. I also note that RFC 5424 says: = "Facility and Severity values are not normative but often used. They = are described in the following tables for purely informational = purposes.=E2=80=9D So I wonder whether you really compromise anything by = adding the =E2=80=9Call=E2=80=9D option. Lada >=20 > Thanks, >=20 > Clyde >=20 >=20 >=20 >=20 > On 7/14/15, 9:03 AM, "Ladislav Lhotka" wrote: >=20 >>=20 >>> On 14 Jul 2015, at 17:25, Clyde Wildes (cwildes) = wrote: >>>=20 >>> Lada, >>>=20 >>> Thanks for your review. >>>=20 >>> All was not added to the syslogtypes:severity because that would = alter the definition of severity as specified by RFC 5424 in Table 2 on = page 10. I agree that it will simplify the model to do so. >>=20 >> The description of the =E2=80=9Cseverity=E2=80=9D leaf says: >>=20 >> When severity is specified the default severity comparison is all = messages of the specified severity and greater are logged unless all is = specified which means all severities are requested. >>=20 >> Isn=E2=80=99t then =E2=80=9Cdebug=E2=80=9D equivalent to =E2=80=9Call=E2= =80=9D, i.e. is the =E2=80=9Call=E2=80=9D option really needed? >>=20 >>>=20 >>> Please advise. >>=20 >> I would do a similar thing that you did for facilities: choice = between =E2=80=9Cseverity=E2=80=9D (with the type = =E2=80=9Csyslogtypes:severity=E2=80=9D) and an empty leaf = "all-severities=E2=80=9D. >>=20 >> Lada >>=20 >>>=20 >>> Thanks, >>>=20 >>> Clyde >>>=20 >>>=20 >>>=20 >>> On 7/14/15, 6:57 AM, "netmod on behalf of Ladislav Lhotka" = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> the example in sec. 4.3 of draft-ietf-netmod-syslog-model-04 is >>>> invalid: the value of "severity" should be "critical" rather than >>>> "syslogtypes:critical". Enums are simple strings, not QNames. >>>>=20 >>>> Also, I wonder why the type of "severity" is defined (in multiple >>>> places) like so: >>>>=20 >>>> type union { >>>> type syslogtypes:severity; >>>> type enumeration { >>>> enum all { >>>> value -1; >>>> description >>>> "This enum describes the case where all severities=20 >>>> are requested."; >>>> } >>>> } >>>>=20 >>>> I think the "all" enum can be simply added to the = "syslogtypes:severity" >>>> enumeration. >>>>=20 >>>> Lada >>>>=20 >>>> --=20 >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>=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 Tue Jul 14 18:58:03 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 EB9851B309B for ; Tue, 14 Jul 2015 18:58:01 -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 wPPoPGWBUwbZ for ; Tue, 14 Jul 2015 18:58:00 -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 3F01E1B3052 for ; Tue, 14 Jul 2015 18:58: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 BVE27384; Wed, 15 Jul 2015 01:57:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jul 2015 02:57:56 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 15 Jul 2015 09:57:44 +0800 From: Qin Wu To: Robert Wilton , wangzitao , "netmod@ietf.org" Thread-Topic: [netmod] Interface Extensions YANG draft Thread-Index: AQHQuZjA2JPLlJ1PpUGHzt5SYGcGf53YlmAAgAAtRwCAAAGTAIAANiyAgAACYICAACRGgIACqT8A Date: Wed, 15 Jul 2015 01:57:43 +0000 Message-ID: References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> <20150713145229.GA237@elstar.local> <55A3EF1B.4050907@cisco.com> In-Reply-To: <55A3EF1B.4050907@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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, 15 Jul 2015 01:58:02 -0000 >> More naturally it feels that the interface layering is more useful to=20 >> represent LAG interfaces or VLAN sub-interfaces, which can be done,=20 [Qin]: Is your proposal about interface extension for L2 sub-interface? >> but section 3.3 Interface Layering from YANG Interface Management=20 >> indicates that the layering attributes are read only, so you still=20 >> need separate configuration leaves to set up the parent<->child relation= ship. [Qin]: Based on RFC7223, only state leaves are required to represent interf= ace layering hierarchy, if my understanding is correct. > See Appendix C in RFC 7223 how this was envisioned to be done. Yes, I believe that the approach that we have proposed is broadly consisten= t with that, but defined in a slightly more generic way and without the nee= d for the vlan-tagging leaf on the parent. However, in the model that we have proposed, it is likely that the "parent-= interface" interface-ref that we define on a sub-interface has to be an opt= ional leaf because you are not allowed to augment with a mandatory node. S= o, this would come down to implementations being expected to reject sub-int= erface configurations if the parent-interface hasn't been correctly populat= ed. In some ways this is not ideal - but I can appreciate why the YANG rul= es are how they are. [Qin]: How is "parent-interface" define in the interface extensions differe= nt from base-interface defined in the example of Appendix C in RFC7223? It = looks you both using "interface-ref" types to reference lower layers. Thanks, Rob > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jul 14 20:27:06 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 8188C1B3131 for ; Tue, 14 Jul 2015 20:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_29=0.6, MIME_CHARSET_FARAWAY=2.45, 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 7FVu3MaWBpzP for ; Tue, 14 Jul 2015 20:27:04 -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 B744E1B3130 for ; Tue, 14 Jul 2015 20:27:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVF04959; Wed, 15 Jul 2015 03:27:01 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jul 2015 04:26:59 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 15 Jul 2015 11:26:52 +0800 From: Qin Wu To: Aijun Wang , "netmod@ietf.org" Thread-Topic: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt Thread-Index: AQHQvq4XZV95oTjfskWTpLL6pUXaNA== Date: Wed, 15 Jul 2015 03:26:51 +0000 Message-ID: References: <00de01d0b7a1$323339e0$9699ada0$@org.cn> In-Reply-To: <00de01d0b7a1$323339e0$9699ada0$@org.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.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: Wed, 15 Jul 2015 03:27:05 -0000 QXV0aG9yczoNCkkgdGhpbmsgdGhpcyBkcmFmdCB3aWxsIGJlIHVzZWZ1bCB3aGVuIHdlIGNvbnNp ZGVyIHRvIGNob29zZSBhbmQgY29uZmlndXJlIGxhcmdlIG51bWJlciBvZiBkaWZmZXJlbnQgdGVj aG5vbG9neSBzcGVjaWZpYyB0dW5uZWxzIHRoYXQgc2hhcmUgYSBsb3Qgb2YgY29tbW9uIHByb3Bl cnRpZXMuDQpPbmUgcXVlc3Rpb24gSSBoYXZlIGhlcmUgaXMgaG93IHRoaXMgZHJhZnQgaXMgcmVs YXRlZCB0byBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmctMDA/DQpJZiBteSB1bmRl cnN0YW5kaW5nIGlzIGNvcnJlY3QsIHlvdXIgZHJhZnQgaXMgYWJvdXQgaW50ZXJmYWNlIGV4dGVu c2lvbiBmb3IgdHVubmVsaW5nIG1hbmFnZW1lbnQuIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1l eHQteWFuZy0wMCBmb2N1c2VzIG9uIGludGVyZmFjZSBleHRlbnNpb24gZm9yIEwyIHN1Yi1pbnRl cmZhY2UuDQpCdXQgdHdvIGRyYWZ0IGZvbGxvd3MgdHdvIGRpZmZlcmVudCBtb2RlbCBkZXNpZ24s IHlvdSBzcGVjaWZ5IGNvbW1vbiBwcm9wZXJ0aWVzIHdpdGhpbiB0dW5uZWwgY29udGFpbmVyIHdo aWxlIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMCBzcGVjaWZpZXMgY29tbW9u IHByb3BlcnRpZXMgZGlyZWN0bHkgd2l0aGluIGlmOmludGVyZmFjZS4NCg0KLVFpbg0KLS0tLS3T yrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIEFpanVuIFdhbmcNCreiy83KsbzkOiAyMDE1xOo31MI2yNUgMTI6MDcNCsrVvP7I yzogbmV0bW9kQGlldGYub3JnDQrW98ziOiBbbmV0bW9kXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwLnR4dA0KDQpIaSwgYWxs Og0KDQpXZSBzdWJtaXR0ZWQgb25lIG5ldyBkcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwKSB0aGF0IGRlc2NyaWJlZCBv bmUgZ2VuZXJhbCBtb2RlbCBmb3IgdGhlIHR1bm5lbCBzZXJ2aWNlcyB1c2VkIHdpdGhpbiBzZXJ2 aWNlIHByb3ZpZGVyIG5ldHdvcmsuIEl0IHN1bW1hcmllcyB0aGUgY29tbW9uIGNoYXJhY3Rlcmlz dGljIG9mIHRoZSBjdXJyZW50IHZhcmlvdXMgdHVubmVsIHByb3RvY29scyBhbmQgY2FuIGJlIHVz ZWQgYXMgb25lIGZ1bmRhbWVudGFsIG1vZGVsIGZvciB0aGUgc3BlY2lmaWMgdHVubmVsIHRlY2hu b2xvZ3kuIA0KQW55IGZlZWRiYWNrIGlzIHdlbGNvbWUuDQoNCkJlc3QgUmVnYXJkLg0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkg MDMsIDIwMTUgNDoyMSBQTQ0KVG86IFppdGFvIFdhbmc7IFlhbiBaaHVhbmc7IEFpanVuIFdhbmc7 IFpodWFuZ3lhbjsgWml0YW8gV2FuZzsgQWlqdW4gV2FuZw0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1bm5lbC1j ZmctMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFppdGFvIFdhbmcg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtd3d6LW5l dG1vZC15YW5nLXR1bm5lbC1jZmcNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlZQU5HIERhdGEgTW9k ZWwgZm9yIFR1bm5lbCBNYW5hZ2VtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE1LTA3LTAzDQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13d3otbmV0bW9kLXlhbmct dHVubmVsLWNmZy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1 bm5lbC1jZmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlB TkcgZGF0YSBtb2RlbCBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gYW5kDQogICBtYW5hZ2VtZW50IG9m IGdlbmVyaWMgdHVubmVscy4gIFRoZSBkYXRhIG1vZGVsIGluY2x1ZGVzIGNvbmZpZ3VyYXRpb24N CiAgIGRhdGEgYW5kIHN0YXRlIGRhdGEuICBBbmQgaXQgY2FuIHNlcnZlIGFzIGEgYmFzZSBtb2Rl bCB3aGljaCBpcw0KICAgYXVnbWVudGVkIHdpdGggdGVjaG5vbG9neS1zcGVjaWZpYyBkZXRhaWxz IGluIG90aGVyLCBtb3JlIHNwZWNpZmljDQogICB0dW5uZWwgbW9kZWxzLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Jul 14 23:03:32 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 2B51F1A7000 for ; Tue, 14 Jul 2015 23:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_29=0.6, MIME_CHARSET_FARAWAY=2.45, 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 0zFhSGyph6rq for ; Tue, 14 Jul 2015 23:03:28 -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 34F411A6FFD for ; Tue, 14 Jul 2015 23:03:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVF13965; Wed, 15 Jul 2015 06:03:26 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jul 2015 07:03:25 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.165]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Wed, 15 Jul 2015 14:02:39 +0800 From: wangzitao To: Qin Wu , Aijun Wang , "netmod@ietf.org" Thread-Topic: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt Thread-Index: AQHQvq68WvyBvY6EmU6+so8RhmUL6Z3cCghw Date: Wed, 15 Jul 2015 06:02:40 +0000 Message-ID: References: <00de01d0b7a1$323339e0$9699ada0$@org.cn> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.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: Wed, 15 Jul 2015 06:03:31 -0000 WWVzLCB0aGlzIGRyYWZ0IGlzIHRhbGtpbmcgYWJvdXQgaW50ZXJmYWNlIGV4dGVuc2lvbiB3aXRo IHR1bm5lbCBtYW5hZ2VtZW50Lg0KVHVubmVsIGlzIGltcGxlbWVudGVkIGFzIGEgdmlydHVhbCBp bnRlcmZhY2Ugd2hpY2ggcHJvdmlkZXMgYSBzaW1wbGUgaW50ZXJmYWNlIGZvciBjb25maWd1cmF0 aW9uLiBBbmQgdGhlIHR1bm5lbCBpbnRlcmZhY2UgaXMgaW5kZXBlbmRlbnQgb2YgdW5kZXJseWlu ZyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRvIGJlIHVzZWQuIA0KVGhlIGNvbW1vbiBwcm9wZXJ0aWVz IHdlIHByb3Bvc2VkIGlzIGNvbW1vbiB0byBhbGwgdGhlIHRlY2hub2xvZ3kgc3BlY2lmaWMgdHVu bmVscyBtb2RlbCwgYnV0IHdlIGFyZSBub3Qgc2F5aW5nIHRoZXkgYXJlIGNvbW1vbiB0byBhbGwg dGhlIGludGVyZmFjZSBzcGVjaWZpYyBtb2RlbHMuDQoNCkFzIGRlc2NyaWJlZCBpbiBSRkM3MjIz LCBUaGVyZSBpcyBubyBnZW5lcmljIG1lY2hhbmlzbSBmb3IgaG93IGFuIGludGVyZmFjZSBpcyBj b25maWd1cmVkIHRvIGJlIGxheWVyZWQgb24gdG9wIG9mIHNvbWUgb3RoZXIgaW50ZXJmYWNlLiBU aGF0IGlzIHdoeSB3ZSBwdXQgYWxsIHRoZSBjb21tb24gcHJvcGVydGllcyB1bmRlciB0ZWNobm9s b2d5IGluZGVwZW5kZW50IHR1bm5lbCBtb2RlbChpLmUuLGludGVyZmFjZSBzcGVjaWZpYyBtb2Rl bCkuDQoNCkJlc3QgUmVnYXJkcyENCi1NaWNoYWVsDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8 /sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBRaW4gV3UN Creiy83KsbzkOiAyMDE1xOo31MIxNcjVIDExOjI3DQrK1bz+yMs6IEFpanVuIFdhbmc7IG5ldG1v ZEBpZXRmLm9yZw0K1vfM4jogUmU6IFtuZXRtb2RdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1bm5lbC1jZmctMDAudHh0DQoNCkF1dGhvcnM6DQpJ IHRoaW5rIHRoaXMgZHJhZnQgd2lsbCBiZSB1c2VmdWwgd2hlbiB3ZSBjb25zaWRlciB0byBjaG9v c2UgYW5kIGNvbmZpZ3VyZSBsYXJnZSBudW1iZXIgb2YgZGlmZmVyZW50IHRlY2hub2xvZ3kgc3Bl Y2lmaWMgdHVubmVscyB0aGF0IHNoYXJlIGEgbG90IG9mIGNvbW1vbiBwcm9wZXJ0aWVzLg0KT25l IHF1ZXN0aW9uIEkgaGF2ZSBoZXJlIGlzIGhvdyB0aGlzIGRyYWZ0IGlzIHJlbGF0ZWQgdG8gZHJh ZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nLTAwPw0KSWYgbXkgdW5kZXJzdGFuZGluZyBp cyBjb3JyZWN0LCB5b3VyIGRyYWZ0IGlzIGFib3V0IGludGVyZmFjZSBleHRlbnNpb24gZm9yIHR1 bm5lbGluZyBtYW5hZ2VtZW50LiBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmctMDAg Zm9jdXNlcyBvbiBpbnRlcmZhY2UgZXh0ZW5zaW9uIGZvciBMMiBzdWItaW50ZXJmYWNlLg0KQnV0 IHR3byBkcmFmdCBmb2xsb3dzIHR3byBkaWZmZXJlbnQgbW9kZWwgZGVzaWduLCB5b3Ugc3BlY2lm eSBjb21tb24gcHJvcGVydGllcyB3aXRoaW4gdHVubmVsIGNvbnRhaW5lciB3aGlsZSBkcmFmdC13 aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmctMDAgc3BlY2lmaWVzIGNvbW1vbiBwcm9wZXJ0aWVz IGRpcmVjdGx5IHdpdGhpbiBpZjppbnRlcmZhY2UuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0t LQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBB aWp1biBXYW5nDQq3osvNyrG85DogMjAxNcTqN9TCNsjVIDEyOjA3DQrK1bz+yMs6IG5ldG1vZEBp ZXRmLm9yZw0K1vfM4jogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy0wMC50eHQNCg0KSGksIGFsbDoNCg0KV2Ugc3Vi bWl0dGVkIG9uZSBuZXcgZHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy0wMCkgdGhhdCBkZXNjcmliZWQgb25lIGdlbmVyYWwg bW9kZWwgZm9yIHRoZSB0dW5uZWwgc2VydmljZXMgdXNlZCB3aXRoaW4gc2VydmljZSBwcm92aWRl ciBuZXR3b3JrLiBJdCBzdW1tYXJpZXMgdGhlIGNvbW1vbiBjaGFyYWN0ZXJpc3RpYyBvZiB0aGUg Y3VycmVudCB2YXJpb3VzIHR1bm5lbCBwcm90b2NvbHMgYW5kIGNhbiBiZSB1c2VkIGFzIG9uZSBm dW5kYW1lbnRhbCBtb2RlbCBmb3IgdGhlIHNwZWNpZmljIHR1bm5lbCB0ZWNobm9sb2d5LiANCkFu eSBmZWVkYmFjayBpcyB3ZWxjb21lLg0KDQpCZXN0IFJlZ2FyZC4NCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBKdWx5IDAzLCAyMDE1IDQ6 MjEgUE0NClRvOiBaaXRhbyBXYW5nOyBZYW4gWmh1YW5nOyBBaWp1biBXYW5nOyBaaHVhbmd5YW47 IFppdGFvIFdhbmc7IEFpanVuIFdhbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1bm5lbC1jZmctMDAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBaaXRhbyBXYW5nIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXd3ei1uZXRtb2QteWFuZy10 dW5uZWwtY2ZnDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJWUFORyBEYXRhIE1vZGVsIGZvciBUdW5u ZWwgTWFuYWdlbWVudA0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wNy0wMw0KR3JvdXA6CQlJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjENClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1bm5lbC1jZmct MDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1bm5lbC1jZmcvDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAw DQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9k ZWwgZm9yIHRoZSBjb25maWd1cmF0aW9uIGFuZA0KICAgbWFuYWdlbWVudCBvZiBnZW5lcmljIHR1 bm5lbHMuICBUaGUgZGF0YSBtb2RlbCBpbmNsdWRlcyBjb25maWd1cmF0aW9uDQogICBkYXRhIGFu ZCBzdGF0ZSBkYXRhLiAgQW5kIGl0IGNhbiBzZXJ2ZSBhcyBhIGJhc2UgbW9kZWwgd2hpY2ggaXMN CiAgIGF1Z21lbnRlZCB3aXRoIHRlY2hub2xvZ3ktc3BlY2lmaWMgZGV0YWlscyBpbiBvdGhlciwg bW9yZSBzcGVjaWZpYw0KICAgdHVubmVsIG1vZGVscy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Wed Jul 15 00:43:56 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 5CC691A885B for ; Wed, 15 Jul 2015 00:43:54 -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_29=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 e4admvZKjSyR for ; Wed, 15 Jul 2015 00:43:51 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF01A884F for ; Wed, 15 Jul 2015 00:43:36 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06B70ADD7qVV5jQhCw==.39500S2; Wed, 15 Jul 2015 13:25:38 +0800 (CST) From: "Aijun Wang" To: "'Qin Wu'" , References: <00de01d0b7a1$323339e0$9699ada0$@org.cn> In-Reply-To: Date: Wed, 15 Jul 2015 15:43:04 +0800 Message-ID: <004b01d0bed1$eb2558c0$c1700a40$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQvq4XZV95oTjfskWTpLL6pUXaNJ3cGd0w Content-Language: zh-cn X-CM-TRANSID: Z0GX06B70ADD7qVV5jQhCw==.39500S2 X-Coremail-Antispam: 1U3129KBjvJXoWxCw47Zryfur1kXry8Gr15Jwb_yoWrWr15pF WUWrW5KrW0q3WSka4rXF1UXF1rZa95K393uF43Gr18XayUJ340qw40k3WFvFyUAryrJrWq qF4UGr17uwn8XrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUojjgDUUUU Archived-At: Subject: Re: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.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: Wed, 15 Jul 2015 07:43:54 -0000 Hi, Qin: Thanks for your comments first. Below is my answer to your question: 1. As you pointed out, " draft-wilton-netmod-intf-ext-yang-00" focuses = mainly on the common layer 2 characteristic of one interface, it = augments the ietf: if-interface yang model and compensates the = characteristic of one physical interface. 2. Draft "draft-wwz-netmod-yang-tunnel-cfg-00.txt" designs the general = tunnel interface model on top of the physical interface model, It covers = and references the characteristics defined both in basic ietf: = if-interface and its augment layer2 characteristic model, for example = that defined in "draft-wilton-netmod-intf-ext-yang-00".=20 Do the above descriptions clarify the relationship between them? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute=20 Intelligent Network Product Line -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: Wednesday, July 15, 2015 11:27 AM To: Aijun Wang; netmod@ietf.org Subject: RE: [netmod] New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt Authors: I think this draft will be useful when we consider to choose and = configure large number of different technology specific tunnels that = share a lot of common properties. One question I have here is how this draft is related to = draft-wilton-netmod-intf-ext-yang-00? If my understanding is correct, your draft is about interface extension = for tunneling management. draft-wilton-netmod-intf-ext-yang-00 focuses = on interface extension for L2 sub-interface. But two draft follows two different model design, you specify common = properties within tunnel container while = draft-wilton-netmod-intf-ext-yang-00 specifies common properties = directly within if:interface. -Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Aijun Wang =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B47=E6=9C=886=E6=97=A5 = 12:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org =E4=B8=BB=E9=A2=98: [netmod] New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt Hi, all: We submitted one new draft = (https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00) that = described one general model for the tunnel services used within service = provider network. It summaries the common characteristic of the current = various tunnel protocols and can be used as one fundamental model for = the specific tunnel technology.=20 Any feedback is welcome. Best Regard. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, July 03, 2015 4:21 PM To: Zitao Wang; Yan Zhuang; Aijun Wang; Zhuangyan; Zitao Wang; Aijun = Wang Subject: New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt A new version of I-D, draft-wwz-netmod-yang-tunnel-cfg-00.txt has been successfully submitted by Zitao Wang and posted to the IETF = repository. Name: draft-wwz-netmod-yang-tunnel-cfg Revision: 00 Title: YANG Data Model for Tunnel Management Document date: 2015-07-03 Group: Individual Submission Pages: 21 URL: = https://www.ietf.org/internet-drafts/draft-wwz-netmod-yang-tunnel-cfg-00.= txt Status: = https://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/ Htmlized: = https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00 Abstract: This document defines a YANG data model for the configuration and management of generic tunnels. The data model includes configuration data and state data. And it can serve as a base model which is augmented with technology-specific details in other, more specific tunnel models. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jul 15 02:40:28 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 EAC5F1A017D for ; Wed, 15 Jul 2015 02:40:26 -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 fplYqXvfCTAR for ; Wed, 15 Jul 2015 02:40:25 -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 409751A013B for ; Wed, 15 Jul 2015 02:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5037; q=dns/txt; s=iport; t=1436953224; x=1438162824; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ALwThsoBhQyko3Y7fCdEmJ0XEyzpUpqEbgxZxPgvwMc=; b=E00jwIMPVYLc8b2qr9Njm+D/DqzEz6j+jJuWjElss7wi+gNtlVlZVhrH dx/u2xTYYZE4lwARz2hTiJvv6TtWuGbefo0lGsTZraYzaBvqJhDYsmg7C FbzY5Bz3wOXML2Ur4oNLLFU0hqIg3jwFZTeyeLz85GVlUvQDvCVWd/2SE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DfAgCUKaZV/xbLJq1bwBUJhRiCVAKBdhQBAQEBAQEBgQqEIwEBAQMBJxEvCwYRCw4KCRYPCQMCAQIBRQYBDAgBAYgiCM9YAQEBAQEBAQEBAQEBAQEBARyLTIUNhCsBBIwtiAuMC4FAhwUijCuDYSZjgxk9gnwBAQE X-IronPort-AV: E=Sophos;i="5.15,479,1432598400"; d="scan'208";a="584855651" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Jul 2015 09:40:21 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6F9eLUG007641; Wed, 15 Jul 2015 09:40:21 GMT Message-ID: <55A62A85.2050602@cisco.com> Date: Wed, 15 Jul 2015 10:40:21 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Qin Wu , wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> <20150713145229.GA237@elstar.local> <55A3EF1B.4050907@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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, 15 Jul 2015 09:40:27 -0000 Hi Qin, On 15/07/2015 02:57, Qin Wu wrote: >>> More naturally it feels that the interface layering is more useful to >>> represent LAG interfaces or VLAN sub-interfaces, which can be done, > [Qin]: Is your proposal about interface extension for L2 sub-interface? Not just L2 sub-interfaces. draft-wilton-netmod-intf-ext-yang-00 covers general interface properties that are common to many interface types on network devices. I.e. (from the draft) it provides the following augmentations to if:interfaces: o A bandwidth configuration leaf to specify the bandwidth available on an interface to control routing metrics. o A carrier delay feature used to provide control over short lived link state flaps. o An interface link state dampening feature that is used to provide control over longer lived link state flaps. o An encapsulation container and extensible choice statement for use by any interface types that allow for configurable L2 encapsulations. o A loopback configuration leaf that is primarily aimed at loopback at the physical layer. o MTU configuration leaves applicable to all packet/frame based interfaces. o A transport layer leaf to indicate whether the interface handles traffic at L1, L2 or L3. o A parent interface leaf useable for all types of sub-interface that are children of parent interfaces. The parent interface leaf is just one of the augmentations and is effectively the minimal information that you need to have a logical sub-interface. I have also posted a separate draft (draft-wilton-netmod-intf-vlan-yang-00) that augments the encapsulation container described above, and uses the parent interface leaf to define how traffic is matched and classified to layer-2 and layer-3 sub-interfaces. >>> but section 3.3 Interface Layering from YANG Interface Management >>> indicates that the layering attributes are read only, so you still >>> need separate configuration leaves to set up the parent<->child relationship. > [Qin]: Based on RFC7223, only state leaves are required to represent interface > layering hierarchy, if my understanding is correct. My interpretation of RFC7223 is a bit different, it states: " There is no generic mechanism for how an interface is configured to be layered on top of some other interface. It is expected that interface-type-specific models define their own data nodes for interface layering by using "interface-ref" types to reference lower layers. " I.e. you need a model specific way to specify the relationship between the nodes. E.g. parent-interface is a such configuration item. This leaf is needed/useful for several reasons: (1) To cleanly specify the relationship between the two interfaces. If you don't have this leaf then you would have no way of specifying the relationship between a child sub-interface and its parent is unless it is possible to infer that from the name of the child sub-interface. Whilst this is possible on the sub-interface naming scheme for some network devices, I don't think that this is universally true, and probably shouldn't be relied on. (2) If you want to define 'must' statements on the model , e.g. to ensure that a particular VLAN Id is only used on a single child sub-interface of a given parent, then having the parent leaf defined in the config namespace makes this easier. I don't think that a must statement is allowed to check against operational leaves, so it either needs a node in the config namespace, or again would have to extract it from the sub-interface name (if that is even possible). >> See Appendix C in RFC 7223 how this was envisioned to be done. > Yes, I believe that the approach that we have proposed is broadly consistent with that, but defined in a slightly more generic way and without the need for the vlan-tagging leaf on the parent. > > However, in the model that we have proposed, it is likely that the "parent-interface" interface-ref that we define on a sub-interface has to be an optional leaf because you are not allowed to augment with a mandatory node. So, this would come down to implementations being expected to reject sub-interface configurations if the parent-interface hasn't been correctly populated. In some ways this is not ideal - but I can appreciate why the YANG rules are how they are. > > [Qin]: How is "parent-interface" define in the interface extensions different from base-interface defined in the example of Appendix C in RFC7223? It looks you both using "interface-ref" types to reference lower layers. They are pretty much equivalent. The main difference is that the Appendix C requires a "vlan-tagging" leaf to be configured on the parent interface, whereas the "parent-interface" leaf that I have defined does not, but has the restriction that it cannot be marked as being mandatory. Thanks, Rob From nobody Wed Jul 15 04:21:55 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 5D5451A8857 for ; Wed, 15 Jul 2015 04:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_29=0.6, MIME_CHARSET_FARAWAY=2.45, 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 hhRAX-wglZ2g for ; Wed, 15 Jul 2015 04:21:52 -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 A5AC31A8874 for ; Wed, 15 Jul 2015 04:21:51 -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 BVF49956; Wed, 15 Jul 2015 11:21:50 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jul 2015 12:21:47 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 15 Jul 2015 19:21:36 +0800 From: Qin Wu To: Robert Wilton , wangzitao , "netmod@ietf.org" Thread-Topic: [netmod] Interface Extensions YANG draft Thread-Index: AQHQuZjA2JPLlJ1PpUGHzt5SYGcGf53YlmAAgAAtRwCAAAGTAIAANiyAgAACYICAACRGgIACqT8A////74CAAIsMEA== Date: Wed, 15 Jul 2015 11:21:35 +0000 Message-ID: References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> <20150713145229.GA237@elstar.local> <55A3EF1B.4050907@cisco.com> <55A62A85.2050602@cisco.com> In-Reply-To: <55A62A85.2050602@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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, 15 Jul 2015 11:21:54 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9u QGNpc2NvLmNvbV0gDQq3osvNyrG85DogMjAxNcTqN9TCMTXI1SAxNzo0MA0KytW8/sjLOiBRaW4g V3U7IHdhbmd6aXRhbzsgbmV0bW9kQGlldGYub3JnDQrW98ziOiBSZTogW25ldG1vZF0gSW50ZXJm YWNlIEV4dGVuc2lvbnMgWUFORyBkcmFmdA0KDQpIaSBRaW4sDQoNCk9uIDE1LzA3LzIwMTUgMDI6 NTcsIFFpbiBXdSB3cm90ZToNCj4+PiBNb3JlIG5hdHVyYWxseSBpdCBmZWVscyB0aGF0IHRoZSBp bnRlcmZhY2UgbGF5ZXJpbmcgaXMgbW9yZSB1c2VmdWwgDQo+Pj4gdG8gcmVwcmVzZW50IExBRyBp bnRlcmZhY2VzIG9yIFZMQU4gc3ViLWludGVyZmFjZXMsIHdoaWNoIGNhbiBiZSANCj4+PiBkb25l LA0KPiBbUWluXTogSXMgeW91ciBwcm9wb3NhbCBhYm91dCBpbnRlcmZhY2UgZXh0ZW5zaW9uIGZv ciBMMiBzdWItaW50ZXJmYWNlPw0KTm90IGp1c3QgTDIgc3ViLWludGVyZmFjZXMuDQoNCmRyYWZ0 LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMCBjb3ZlcnMgZ2VuZXJhbCBpbnRlcmZhY2Ug cHJvcGVydGllcyB0aGF0IGFyZSBjb21tb24gdG8gbWFueSBpbnRlcmZhY2UgdHlwZXMgb24gbmV0 d29yayBkZXZpY2VzLg0KSS5lLiAoZnJvbSB0aGUgZHJhZnQpIGl0IHByb3ZpZGVzIHRoZSBmb2xs b3dpbmcgYXVnbWVudGF0aW9ucyB0bw0KaWY6aW50ZXJmYWNlczoNCg0KICAgIG8gIEEgYmFuZHdp ZHRoIGNvbmZpZ3VyYXRpb24gbGVhZiB0byBzcGVjaWZ5IHRoZSBiYW5kd2lkdGggYXZhaWxhYmxl DQogICAgICAgb24gYW4gaW50ZXJmYWNlIHRvIGNvbnRyb2wgcm91dGluZyBtZXRyaWNzLg0KDQog ICAgbyAgQSBjYXJyaWVyIGRlbGF5IGZlYXR1cmUgdXNlZCB0byBwcm92aWRlIGNvbnRyb2wgb3Zl ciBzaG9ydCBsaXZlZA0KICAgICAgIGxpbmsgc3RhdGUgZmxhcHMuDQoNCiAgICBvICBBbiBpbnRl cmZhY2UgbGluayBzdGF0ZSBkYW1wZW5pbmcgZmVhdHVyZSB0aGF0IGlzIHVzZWQgdG8gcHJvdmlk ZQ0KICAgICAgIGNvbnRyb2wgb3ZlciBsb25nZXIgbGl2ZWQgbGluayBzdGF0ZSBmbGFwcy4NCg0K ICAgIG8gIEFuIGVuY2Fwc3VsYXRpb24gY29udGFpbmVyIGFuZCBleHRlbnNpYmxlIGNob2ljZSBz dGF0ZW1lbnQgZm9yIHVzZQ0KICAgICAgIGJ5IGFueSBpbnRlcmZhY2UgdHlwZXMgdGhhdCBhbGxv dyBmb3IgY29uZmlndXJhYmxlIEwyDQogICAgICAgZW5jYXBzdWxhdGlvbnMuDQoNCiAgICBvICBB IGxvb3BiYWNrIGNvbmZpZ3VyYXRpb24gbGVhZiB0aGF0IGlzIHByaW1hcmlseSBhaW1lZCBhdCBs b29wYmFjaw0KICAgICAgIGF0IHRoZSBwaHlzaWNhbCBsYXllci4NCg0KICAgIG8gIE1UVSBjb25m aWd1cmF0aW9uIGxlYXZlcyBhcHBsaWNhYmxlIHRvIGFsbCBwYWNrZXQvZnJhbWUgYmFzZWQNCiAg ICAgICBpbnRlcmZhY2VzLg0KDQogICAgbyAgQSB0cmFuc3BvcnQgbGF5ZXIgbGVhZiB0byBpbmRp Y2F0ZSB3aGV0aGVyIHRoZSBpbnRlcmZhY2UgaGFuZGxlcw0KICAgICAgIHRyYWZmaWMgYXQgTDEs IEwyIG9yIEwzLg0KDQogICAgbyAgQSBwYXJlbnQgaW50ZXJmYWNlIGxlYWYgdXNlYWJsZSBmb3Ig YWxsIHR5cGVzIG9mIHN1Yi1pbnRlcmZhY2UNCiAgICAgICB0aGF0IGFyZSBjaGlsZHJlbiBvZiBw YXJlbnQgaW50ZXJmYWNlcy4NCg0KDQpUaGUgcGFyZW50IGludGVyZmFjZSBsZWFmIGlzIGp1c3Qg b25lIG9mIHRoZSBhdWdtZW50YXRpb25zIGFuZCBpcyBlZmZlY3RpdmVseSB0aGUgbWluaW1hbCBp bmZvcm1hdGlvbiB0aGF0IHlvdSBuZWVkIHRvIGhhdmUgYSBsb2dpY2FsIHN1Yi1pbnRlcmZhY2Uu DQoNCltRaW5dOiBJIHNlZSwgc291bmRzIGxpa2UgdHVubmVsIGludGVyZmFjZSBkZWZpbmVkIGlu IHRoZSBkcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy0wMCBhbHNvIGludGVuZHMgdG8g c3VwcG9ydCBzZXZlcmFsIHNpbWlsYXIgcHJvcGVydGllcyB3aGljaCBtYWtlIG1lIGJlbGlldmUg eW91IGd1eXMgaGFzIHNvbWUgc2FtZSBnb2FsLiBCb3RoIGF1Z21lbnQgaWY6aW50ZXJmYWNlIHdp dGggaW50ZXJmYWNlIHNwZWNpZmljLCBJIGFtIHdvbmRlcmluZyB3aGljaCBvbmUgZHJhZnQgaGFz IGJldHRlciBtb2RlbCBkZXNpZ24sIG9uZSBpcyB0byBwbGFjZSBhbGwgY29tbW9uIHByb3BlcnRp ZXMgaW4gb25lIHBsYWNlIHdoaWxlIHRoZSBvdGhlciBpcyBkaXN0cmlidXRlIGNvbW1vbiBwcm9w ZXJ0aWVzIGluIHNldmVyYWwgcGxhY2VzIHdpdGhpbiBpZjppbnRlcmZhY2UuDQoNCkkgaGF2ZSBh bHNvIHBvc3RlZCBhIHNlcGFyYXRlIGRyYWZ0DQooZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLXZs YW4teWFuZy0wMCkgdGhhdCBhdWdtZW50cyB0aGUgZW5jYXBzdWxhdGlvbiBjb250YWluZXIgZGVz Y3JpYmVkIGFib3ZlLCBhbmQgdXNlcyB0aGUgcGFyZW50IGludGVyZmFjZSBsZWFmIHRvIGRlZmlu ZSBob3cgdHJhZmZpYyBpcyBtYXRjaGVkIGFuZCBjbGFzc2lmaWVkIHRvIGxheWVyLTIgYW5kIGxh eWVyLTMgc3ViLWludGVyZmFjZXMuDQoNCltRaW5dOiBJIHdpbGwgdGFrZSBhIGxvb2sgYXQgaXQg YW5kIHRoYW5rcyBmb3IgdGhlIHBvaW50ZXIuDQoNCj4+PiBidXQgc2VjdGlvbiAzLjMgSW50ZXJm YWNlIExheWVyaW5nIGZyb20gWUFORyBJbnRlcmZhY2UgTWFuYWdlbWVudCANCj4+PiBpbmRpY2F0 ZXMgdGhhdCB0aGUgbGF5ZXJpbmcgYXR0cmlidXRlcyBhcmUgcmVhZCBvbmx5LCBzbyB5b3Ugc3Rp bGwgDQo+Pj4gbmVlZCBzZXBhcmF0ZSBjb25maWd1cmF0aW9uIGxlYXZlcyB0byBzZXQgdXAgdGhl IHBhcmVudDwtPmNoaWxkIHJlbGF0aW9uc2hpcC4NCj4gW1Fpbl06IEJhc2VkIG9uIFJGQzcyMjMs IG9ubHkgc3RhdGUgbGVhdmVzIGFyZSByZXF1aXJlZCB0byByZXByZXNlbnQgDQo+IGludGVyZmFj ZSBsYXllcmluZyBoaWVyYXJjaHksIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4NCk15 IGludGVycHJldGF0aW9uIG9mIFJGQzcyMjMgaXMgYSBiaXQgZGlmZmVyZW50LCBpdCBzdGF0ZXM6 DQoiDQoNCiAgICBUaGVyZSBpcyBubyBnZW5lcmljIG1lY2hhbmlzbSBmb3IgaG93IGFuIGludGVy ZmFjZSBpcyBjb25maWd1cmVkIHRvDQogICAgYmUgbGF5ZXJlZCBvbiB0b3Agb2Ygc29tZSBvdGhl ciBpbnRlcmZhY2UuICBJdCBpcyBleHBlY3RlZCB0aGF0DQogICAgaW50ZXJmYWNlLXR5cGUtc3Bl Y2lmaWMgbW9kZWxzIGRlZmluZSB0aGVpciBvd24gZGF0YSBub2RlcyBmb3INCiAgICBpbnRlcmZh Y2UgbGF5ZXJpbmcgYnkgdXNpbmcgImludGVyZmFjZS1yZWYiIHR5cGVzIHRvIHJlZmVyZW5jZQ0K ICAgIGxvd2VyIGxheWVycy4NCiINCg0KDQpJLmUuIHlvdSBuZWVkIGEgbW9kZWwgc3BlY2lmaWMg d2F5IHRvIHNwZWNpZnkgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBub2Rlcy4NCg0KW1Fp bl06IHRoYXQncyBteSBtaXN1bmRlcnN0YW5kaW5nIG9uIFJGQzcyMjMsIHNvcnJ5IGFib3V0IHRo YXQsIGJ5IHJlYWRpbmcgYXBwZW5kaXggQyBvZiBSRkM3MjIzLA0KSSBiZWxpZXZlIHdoYXQgUkZj NzIyMyBwcm9wb3NlIGlzIHRvIGRlZmluZSBwYXJlbnQgaW50ZXJmYWNlIG9yIGJhc2UgaW50ZXJm YWNlIGluIHRoZSBpbnRlcmZhY2UgZXh0ZW5zaW9uIG1vZGVsIHRvIHNwZWNpZnkgcmVsYXRpb25z aGlwIGJldHdlZW4gaW50ZXJmYWNlcyBpbiB0d28gZGlmZmVyZW50IGxheWVycy4NCg0KRS5nLiBw YXJlbnQtaW50ZXJmYWNlIGlzIGEgc3VjaCBjb25maWd1cmF0aW9uIGl0ZW0uICBUaGlzIGxlYWYg aXMgbmVlZGVkL3VzZWZ1bCBmb3Igc2V2ZXJhbCByZWFzb25zOg0KKDEpIFRvIGNsZWFubHkgc3Bl Y2lmeSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHR3byBpbnRlcmZhY2VzLiBJZiB5b3Ug ZG9uJ3QgaGF2ZSB0aGlzIGxlYWYgdGhlbiB5b3Ugd291bGQgaGF2ZSBubyB3YXkgb2Ygc3BlY2lm eWluZyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBjaGlsZCBzdWItaW50ZXJmYWNlIGFuZCBp dHMgcGFyZW50IGlzIHVubGVzcyBpdCBpcyBwb3NzaWJsZSB0byBpbmZlciB0aGF0IGZyb20gdGhl IG5hbWUgb2YgdGhlIGNoaWxkIHN1Yi1pbnRlcmZhY2UuICANCldoaWxzdCB0aGlzIGlzIHBvc3Np YmxlIG9uIHRoZSBzdWItaW50ZXJmYWNlIG5hbWluZyBzY2hlbWUgZm9yIHNvbWUgbmV0d29yayBk ZXZpY2VzLCBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBpcyB1bml2ZXJzYWxseSB0cnVlLCBhbmQg cHJvYmFibHkgc2hvdWxkbid0IGJlIHJlbGllZCBvbi4NCg0KW1Fpbl06WWVzLCBwYXJlbnQtaW50 ZXJmYWNlIGlzIG5lZWRlZCBqdXN0IGxpa2Ugd2h5IGJhc2UgaW50ZXJmYWNlIGlzIG5lZWRlZCBp biB0aGUgaW50ZXJmYWNlIGV4dGVuc2lvbiBleGFtcGxlIGRlc2NyaWJlZCBpbiBBcHBlbmRpeCBD IG9mIFJGQzcyMjMuDQoNCigyKSBJZiB5b3Ugd2FudCB0byBkZWZpbmUgJ211c3QnIHN0YXRlbWVu dHMgb24gdGhlIG1vZGVsICwgZS5nLiB0byBlbnN1cmUgdGhhdCBhIHBhcnRpY3VsYXIgVkxBTiBJ ZCBpcyBvbmx5IHVzZWQgb24gYSBzaW5nbGUgY2hpbGQgc3ViLWludGVyZmFjZSBvZiBhIGdpdmVu IHBhcmVudCwgdGhlbiBoYXZpbmcgdGhlIHBhcmVudCBsZWFmIGRlZmluZWQgaW4gdGhlIGNvbmZp ZyBuYW1lc3BhY2UgbWFrZXMgdGhpcyBlYXNpZXIuICBJIGRvbid0IHRoaW5rIHRoYXQgYSBtdXN0 IHN0YXRlbWVudCBpcyBhbGxvd2VkIHRvIGNoZWNrIGFnYWluc3Qgb3BlcmF0aW9uYWwgbGVhdmVz LCBzbyBpdCBlaXRoZXIgbmVlZHMgYSBub2RlIGluIHRoZSBjb25maWcgbmFtZXNwYWNlLCBvciBh Z2FpbiB3b3VsZCBoYXZlIHRvIGV4dHJhY3QgaXQgZnJvbSB0aGUgc3ViLWludGVyZmFjZSBuYW1l IChpZiB0aGF0IGlzIGV2ZW4gcG9zc2libGUpLg0KDQo+PiBTZWUgQXBwZW5kaXggQyBpbiBSRkMg NzIyMyBob3cgdGhpcyB3YXMgZW52aXNpb25lZCB0byBiZSBkb25lLg0KPiBZZXMsIEkgYmVsaWV2 ZSB0aGF0IHRoZSBhcHByb2FjaCB0aGF0IHdlIGhhdmUgcHJvcG9zZWQgaXMgYnJvYWRseSBjb25z aXN0ZW50IHdpdGggdGhhdCwgYnV0IGRlZmluZWQgaW4gYSBzbGlnaHRseSBtb3JlIGdlbmVyaWMg d2F5IGFuZCB3aXRob3V0IHRoZSBuZWVkIGZvciB0aGUgdmxhbi10YWdnaW5nIGxlYWYgb24gdGhl IHBhcmVudC4NCj4NCj4gSG93ZXZlciwgaW4gdGhlIG1vZGVsIHRoYXQgd2UgaGF2ZSBwcm9wb3Nl ZCwgaXQgaXMgbGlrZWx5IHRoYXQgdGhlICJwYXJlbnQtaW50ZXJmYWNlIiBpbnRlcmZhY2UtcmVm IHRoYXQgd2UgZGVmaW5lIG9uIGEgc3ViLWludGVyZmFjZSBoYXMgdG8gYmUgYW4gb3B0aW9uYWwg bGVhZiBiZWNhdXNlIHlvdSBhcmUgbm90IGFsbG93ZWQgdG8gYXVnbWVudCB3aXRoIGEgbWFuZGF0 b3J5IG5vZGUuICBTbywgdGhpcyB3b3VsZCBjb21lIGRvd24gdG8gaW1wbGVtZW50YXRpb25zIGJl aW5nIGV4cGVjdGVkIHRvIHJlamVjdCBzdWItaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb25zIGlmIHRo ZSBwYXJlbnQtaW50ZXJmYWNlIGhhc24ndCBiZWVuIGNvcnJlY3RseSBwb3B1bGF0ZWQuICBJbiBz b21lIHdheXMgdGhpcyBpcyBub3QgaWRlYWwgLSBidXQgSSBjYW4gYXBwcmVjaWF0ZSB3aHkgdGhl IFlBTkcgcnVsZXMgYXJlIGhvdyB0aGV5IGFyZS4NCj4NCj4gW1Fpbl06IEhvdyBpcyAicGFyZW50 LWludGVyZmFjZSIgZGVmaW5lIGluIHRoZSBpbnRlcmZhY2UgZXh0ZW5zaW9ucyBkaWZmZXJlbnQg ZnJvbSBiYXNlLWludGVyZmFjZSBkZWZpbmVkIGluIHRoZSBleGFtcGxlIG9mIEFwcGVuZGl4IEMg aW4gUkZDNzIyMz8gSXQgbG9va3MgeW91IGJvdGggdXNpbmcgImludGVyZmFjZS1yZWYiIHR5cGVz IHRvIHJlZmVyZW5jZSBsb3dlciBsYXllcnMuDQpUaGV5IGFyZSBwcmV0dHkgbXVjaCBlcXVpdmFs ZW50LiAgVGhlIG1haW4gZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSBBcHBlbmRpeCBDIHJlcXVpcmVz IGEgInZsYW4tdGFnZ2luZyIgbGVhZiB0byBiZSBjb25maWd1cmVkIG9uIHRoZSBwYXJlbnQgaW50 ZXJmYWNlLCB3aGVyZWFzIHRoZSAicGFyZW50LWludGVyZmFjZSIgbGVhZiB0aGF0IEkgaGF2ZSBk ZWZpbmVkIGRvZXMgbm90LCBidXQgaGFzIHRoZSByZXN0cmljdGlvbiB0aGF0IGl0IGNhbm5vdCBi ZSBtYXJrZWQgYXMgYmVpbmcgbWFuZGF0b3J5Lg0KDQpbUWluXTogSSBjYW4gc2VlIHRoaXMgc3Vi dGxlIGRpZmZlcmVuY2UgYmV0d2VlbiB0d28gYnV0IGNhbid0IHdlaWdoIG9uZSBpcyBiZXR0ZXIg dGhhbiB0aGUgb3RoZXIuDQoNClRoYW5rcywNClJvYg0KDQo= From nobody Wed Jul 15 04:38:10 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 5FFAD1A8960 for ; Wed, 15 Jul 2015 04:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, 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 7iCRWnnO4ph6 for ; Wed, 15 Jul 2015 04:38:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19791A895C for ; Wed, 15 Jul 2015 04:38:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYU53501; Wed, 15 Jul 2015 11:38:04 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jul 2015 12:38:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 15 Jul 2015 19:37:53 +0800 From: Qin Wu To: Aijun Wang , "netmod@ietf.org" Thread-Topic: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.txt Thread-Index: AQHQvq4XZV95oTjfskWTpLL6pUXaNJ3cGd0wgABLsHA= Date: Wed, 15 Jul 2015 11:37:53 +0000 Message-ID: References: <00de01d0b7a1$323339e0$9699ada0$@org.cn> <004b01d0bed1$eb2558c0$c1700a40$@org.cn> In-Reply-To: <004b01d0bed1$eb2558c0$c1700a40$@org.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.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: Wed, 15 Jul 2015 11:38:08 -0000 QWlqdW46DQpQbGVhc2Ugc2VlIG15IHJlcGx5IHRvIFJvYmVydCwgSSBhbSBhZnJhaWQgZHJhZnQt d2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nLTAwIGlzIG5vdCBsaW1pdGVkIHRvIGRlc2NyaWJl IGNvbW1vbiBsMiBjaGFyYWN0ZXJpc3RpYyBvZiB0aGUgaW50ZXJmYWNlLg0KVGhlbiB0dW5uZWwg aW50ZXJmYWNlIGluIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwIGFuZCBpbnRl cmZhY2UgZXh0ZW5zaW9uIHByb3Bvc2VkIGluIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQt eWFuZy0wMCBzaGFyZSBzb21lDQpDb21tb24gcHJvcGVydGllcywgc28gd2hhdCBpcyB0aGUgYmV0 dGVyIG1vZGVsIGRlc2lnbj8gUGxhY2UgYWxsIHRoZSBwcm9wZXJ0aWVzIGluIG9uZSBwbGFjZSB1 bmRlciB0dW5uZWwgaW50ZXJmYWNlIG9yIG1vdmUgdGhlc2UgcHJvcGVydGllcyBpbiANCkluIHRo ZSBzYW1lIGxldmVsIGFzIG90aGVyIHByb3BlcnRpZXMgZGVmaW5lZCB1bmRlciBpZjppbnRlcmZh Y2U/DQoNCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogQWlqdW4gV2Fu ZyBbbWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY25dIA0K5Y+R6YCB5pe26Ze0OiAyMDE1 5bm0N+aciDE15pelIDE1OjQzDQrmlLbku7bkuro6IFFpbiBXdTsgbmV0bW9kQGlldGYub3JnDQrk uLvpopg6IFJFOiBbbmV0bW9kXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd3 ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwLnR4dA0KDQpIaSwgUWluOg0KDQpUaGFua3MgZm9y IHlvdXIgY29tbWVudHMgZmlyc3QuDQpCZWxvdyBpcyBteSBhbnN3ZXIgdG8geW91ciBxdWVzdGlv bjoNCjEuIEFzIHlvdSBwb2ludGVkIG91dCwgIiBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0 LXlhbmctMDAiIGZvY3VzZXMgbWFpbmx5IG9uIHRoZSBjb21tb24gbGF5ZXIgMiBjaGFyYWN0ZXJp c3RpYyBvZiBvbmUgaW50ZXJmYWNlLCBpdCBhdWdtZW50cyB0aGUgaWV0ZjogaWYtaW50ZXJmYWNl IHlhbmcgbW9kZWwgYW5kIGNvbXBlbnNhdGVzIHRoZSBjaGFyYWN0ZXJpc3RpYyBvZiBvbmUgcGh5 c2ljYWwgaW50ZXJmYWNlLg0KMi4gRHJhZnQgImRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwt Y2ZnLTAwLnR4dCIgZGVzaWducyB0aGUgZ2VuZXJhbCB0dW5uZWwgaW50ZXJmYWNlIG1vZGVsIG9u IHRvcCBvZiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlIG1vZGVsLCBJdCBjb3ZlcnMgYW5kIHJlZmVy ZW5jZXMgdGhlIGNoYXJhY3RlcmlzdGljcyBkZWZpbmVkIGJvdGggaW4gYmFzaWMgaWV0ZjogaWYt aW50ZXJmYWNlIGFuZCBpdHMgYXVnbWVudCBsYXllcjIgY2hhcmFjdGVyaXN0aWMgbW9kZWwsIGZv ciBleGFtcGxlIHRoYXQgZGVmaW5lZCBpbiAiZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15 YW5nLTAwIi4gDQoNCkRvIHRoZSBhYm92ZSBkZXNjcmlwdGlvbnMgY2xhcmlmeSB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gdGhlbT8NCg0KQmVzdCBSZWdhcmRzLg0KDQpBaWp1biBXYW5nDQoNCkNo aW5hIFRlbGVjb20gQ29ycG9yYXRpb24gTGltaXRlZCBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHV0 ZSBJbnRlbGxpZ2VudCBOZXR3b3JrIFByb2R1Y3QgTGluZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDog V2VkbmVzZGF5LCBKdWx5IDE1LCAyMDE1IDExOjI3IEFNDQpUbzogQWlqdW4gV2FuZzsgbmV0bW9k QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy0wMC50eHQNCg0KQXV0aG9yczoN CkkgdGhpbmsgdGhpcyBkcmFmdCB3aWxsIGJlIHVzZWZ1bCB3aGVuIHdlIGNvbnNpZGVyIHRvIGNo b29zZSBhbmQgY29uZmlndXJlIGxhcmdlIG51bWJlciBvZiBkaWZmZXJlbnQgdGVjaG5vbG9neSBz cGVjaWZpYyB0dW5uZWxzIHRoYXQgc2hhcmUgYSBsb3Qgb2YgY29tbW9uIHByb3BlcnRpZXMuDQpP bmUgcXVlc3Rpb24gSSBoYXZlIGhlcmUgaXMgaG93IHRoaXMgZHJhZnQgaXMgcmVsYXRlZCB0byBk cmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmctMDA/DQpJZiBteSB1bmRlcnN0YW5kaW5n IGlzIGNvcnJlY3QsIHlvdXIgZHJhZnQgaXMgYWJvdXQgaW50ZXJmYWNlIGV4dGVuc2lvbiBmb3Ig dHVubmVsaW5nIG1hbmFnZW1lbnQuIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZy0w MCBmb2N1c2VzIG9uIGludGVyZmFjZSBleHRlbnNpb24gZm9yIEwyIHN1Yi1pbnRlcmZhY2UuDQpC dXQgdHdvIGRyYWZ0IGZvbGxvd3MgdHdvIGRpZmZlcmVudCBtb2RlbCBkZXNpZ24sIHlvdSBzcGVj aWZ5IGNvbW1vbiBwcm9wZXJ0aWVzIHdpdGhpbiB0dW5uZWwgY29udGFpbmVyIHdoaWxlIGRyYWZ0 LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMCBzcGVjaWZpZXMgY29tbW9uIHByb3BlcnRp ZXMgZGlyZWN0bHkgd2l0aGluIGlmOmludGVyZmFjZS4NCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIEFpanVuIFdhbmcNCuWPkemAgeaXtumXtDogMjAxNeW5tDfmnIg25pelIDEyOjA3 DQrmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBbbmV0bW9kXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwLnR4 dA0KDQpIaSwgYWxsOg0KDQpXZSBzdWJtaXR0ZWQgb25lIG5ldyBkcmFmdCAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwKSB0aGF0 IGRlc2NyaWJlZCBvbmUgZ2VuZXJhbCBtb2RlbCBmb3IgdGhlIHR1bm5lbCBzZXJ2aWNlcyB1c2Vk IHdpdGhpbiBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmsuIEl0IHN1bW1hcmllcyB0aGUgY29tbW9u IGNoYXJhY3RlcmlzdGljIG9mIHRoZSBjdXJyZW50IHZhcmlvdXMgdHVubmVsIHByb3RvY29scyBh bmQgY2FuIGJlIHVzZWQgYXMgb25lIGZ1bmRhbWVudGFsIG1vZGVsIGZvciB0aGUgc3BlY2lmaWMg dHVubmVsIHRlY2hub2xvZ3kuIA0KQW55IGZlZWRiYWNrIGlzIHdlbGNvbWUuDQoNCkJlc3QgUmVn YXJkLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6IEZy aWRheSwgSnVseSAwMywgMjAxNSA0OjIxIFBNDQpUbzogWml0YW8gV2FuZzsgWWFuIFpodWFuZzsg QWlqdW4gV2FuZzsgWmh1YW5neWFuOyBaaXRhbyBXYW5nOyBBaWp1biBXYW5nDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwt Y2ZnLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13d3otbmV0bW9kLXlh bmctdHVubmVsLWNmZy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Wml0YW8gV2FuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlk cmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZw0KUmV2aXNpb246CTAwDQpUaXRsZToJCVlB TkcgRGF0YSBNb2RlbCBmb3IgVHVubmVsIE1hbmFnZW1lbnQNCkRvY3VtZW50IGRhdGU6CTIwMTUt MDctMDMNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTIxDQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXd3ei1u ZXRtb2QteWFuZy10dW5uZWwtY2ZnLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd3ei1uZXRtb2QteWFuZy10dW5uZWwtY2ZnLw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13d3otbmV0 bW9kLXlhbmctdHVubmVsLWNmZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciB0aGUgY29uZmlndXJhdGlvbiBhbmQNCiAgIG1h bmFnZW1lbnQgb2YgZ2VuZXJpYyB0dW5uZWxzLiAgVGhlIGRhdGEgbW9kZWwgaW5jbHVkZXMgY29u ZmlndXJhdGlvbg0KICAgZGF0YSBhbmQgc3RhdGUgZGF0YS4gIEFuZCBpdCBjYW4gc2VydmUgYXMg YSBiYXNlIG1vZGVsIHdoaWNoIGlzDQogICBhdWdtZW50ZWQgd2l0aCB0ZWNobm9sb2d5LXNwZWNp ZmljIGRldGFpbHMgaW4gb3RoZXIsIG1vcmUgc3BlY2lmaWMNCiAgIHR1bm5lbCBtb2RlbHMuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K DQo= From nobody Wed Jul 15 06:50:34 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 E18EF1A8AE7 for ; Wed, 15 Jul 2015 06:50:32 -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 dkD0nbve7mKr for ; Wed, 15 Jul 2015 06:50:30 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088F91A9064 for ; Wed, 15 Jul 2015 06:50:30 -0700 (PDT) Received: by wgmn9 with SMTP id n9so34298460wgm.0 for ; Wed, 15 Jul 2015 06:50:28 -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=ZPgAuw1pEC4V3jX0zxy/IAUT4k+6yrPBp3X/6HRh1RY=; b=lsPBdrNC3sZVuq78VxaQ3WGyIdF3yAxglDXrjXrdB1vHUPEllfGpF/rF6cyCDC7Fh3 ml02EUrN43f/hG62RbXWeODn+/OzjiOL+1Q4YTU5rTA9WBGJkHYRjU944rtKBFHU6MPJ M2qDZeEJPfAx2zR6rzSXVXaUm+PWCFHInWhnNZk2TfLJ4VgQ9e6htZUIUORPQwpv+KYU u4y04HkrV9Mnnkg3/MA2DxAv/TZCW52t32sO5Al2A4cEkamf4g9Wa5Aenf/tGHUxhLiq pU0Z4s5iqNxquGw7tY36vBIRNKaVFdNZ9l/cyC5Ao5n2aJDTnbsr8tPRyjlnde+ej5P8 Itng== X-Received: by 10.180.72.145 with SMTP id d17mr414787wiv.69.1436968228727; Wed, 15 Jul 2015 06:50:28 -0700 (PDT) Received: from [192.168.10.175] ([147.83.206.80]) by smtp.gmail.com with ESMTPSA id lj14sm9213160wic.18.2015.07.15.06.50.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jul 2015 06:50:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_92B2DA22-0EBB-4B39-8CD1-E35AEF88A286" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Dean Bogdanovic In-Reply-To: Date: Wed, 15 Jul 2015 15:50:44 +0200 Message-Id: <3A2493D0-75B9-46C9-917A-F3CBD274CE99@gmail.com> References: To: Ladislav Lhotka X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ACL model problem 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, 15 Jul 2015 13:50:33 -0000 --Apple-Mail=_92B2DA22-0EBB-4B39-8CD1-E35AEF88A286 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lada, Our original intention was to be able to define wild cards for source = and destination ports, but what you are suggesting is also an option and = I agree your suggestion is better, so adding presence statement to port = containers, as in example below, would be the right solution grouping acl-transport-header-fields { description "Transport header fields"; container source-port-range { presence =E2=80=9CEnables source port range=E2=80=9D; description "Inclusive range representing source ports to be used. When only lower-port is present, it represents a single port."; : : Have fixed it in the model and will update on Monday the draft Dean > On Jul 14, 2015, at 3:26 PM, Ladislav Lhotka wrote: >=20 > Hi, >=20 > the module ietf-packet-fields.yang in draft-ietf-netmod-acl-model-03 > still has the problem that I discovered in the previous revision: >=20 > - Containers "source-port-range" and "destination-port-range" are both > mandatory because the child leaf "lower-port" in each is mandatory. I > think this wasn't intended. One solution would be to make both of = them > containers with presence. >=20 > (see > = https://mailarchive.ietf.org/arch/msg/netmod/ShROtXH7aMNDs5HoIiTUa99X0JY) >=20 > Even though the tree in sec. 3.1 displays "lower-port" as optional, in > reality ietf-packet-fields.yang still has this leaf as "mandatory = true;" > in both "source-port-range" and "destination-port-range". >=20 > Lada >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_92B2DA22-0EBB-4B39-8CD1-E35AEF88A286 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Lada,

Our = original intention was to be able to define wild cards for source and = destination ports, but what you are suggesting is also an option and I = agree your suggestion is better, so adding presence statement to port = containers, as in example below, would be the right solution

grouping = acl-transport-header-fields {
    = description
      "Transport header = fields";
    container source-port-range = {
      = presence =E2=80=9CEnables source port range=E2=80=9D;
      description
  =       "Inclusive range representing source ports to be = used.
        When only = lower-port is present, it represents a single port.";
      :
    =   :

Have = fixed it in the model and will update on Monday the draft

Dean

On Jul 14, 2015, at 3:26 PM, Ladislav Lhotka = <lhotka@nic.cz> = wrote:

Hi,
the module ietf-packet-fields.yang in = draft-ietf-netmod-acl-model-03
still has the problem that = I discovered in the previous revision:

- = Containers "source-port-range" and "destination-port-range" are both
 mandatory because the child leaf "lower-port" in each = is mandatory. I
 think this wasn't intended. One = solution would be to make both of them
 containers = with presence.

(see
https://mailarchive.ietf.org/arch/msg/netmod/ShROtXH7aMNDs5HoIi= TUa99X0JY)

Even though the tree in sec. = 3.1 displays "lower-port" as optional, in
reality = ietf-packet-fields.yang still has this leaf as "mandatory true;"
in both "source-port-range" and "destination-port-range".

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: = E74E8C0C

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

= --Apple-Mail=_92B2DA22-0EBB-4B39-8CD1-E35AEF88A286-- From nobody Wed Jul 15 07:15: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 6B50C1A914E for ; Wed, 15 Jul 2015 07:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 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_29=0.6, 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 64YiO2jNtO3t for ; Wed, 15 Jul 2015 07:15:01 -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 5D12E1A913D for ; Wed, 15 Jul 2015 07:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2964; q=dns/txt; s=iport; t=1436969701; x=1438179301; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=LfTiRviiee5QyAVNi2LLme6OOjdEUDlD49LGT3Gp7RU=; b=YTKc1zBJpWIM/R7cLW0mpN6jy3tB1ToRTZSY/VUTlvN4/pLjl2zSzYMi fd5tTo8k1Qbs0gKa9B2Hr3sn0Lqb4eAsAg/WhnjKkjZtBj1F+D50jGPOH jy3AGToiY9a6lYyhbqUL/yNysGJmFSS3nx2eswZYYRqQGj1K6ZQprQ2dF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CsBAAOaqZV/xbLJq1bhFCDJLgzh20CgXISAQEBAQEBAYEKhCQBAQQjDwEFQBEJAg4KAgIFFggDAgIJAwIBAgE0EQYBDAYCAQGIKp0nnRmWLwEBAQEBAQEDAQEBAQEBARuBIooqhQ2CaIFDAQSMMIgNjA6BQIQYgm2QMSZjgxo9MYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,480,1432598400"; d="scan'208";a="585062615" 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; 15 Jul 2015 14:14:59 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6FEEwah010814; Wed, 15 Jul 2015 14:14:59 GMT Message-ID: <55A66AE2.9070106@cisco.com> Date: Wed, 15 Jul 2015 15:14:58 +0100 From: Robert Wilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Qin Wu , wangzitao , "netmod@ietf.org" References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> <20150713145229.GA237@elstar.local> <55A3EF1B.4050907@cisco.com> <55A62A85.2050602@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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, 15 Jul 2015 14:15:03 -0000 Hi Qin, Please see inline ... On 15/07/2015 12:21, Qin Wu wrote: > -----邮件原件----- > 发件人: Robert Wilton [mailto:rwilton@cisco.com] > 发送时间: 2015年7月15日 17:40 > 收件人: Qin Wu; wangzitao; netmod@ietf.org > 主题: Re: [netmod] Interface Extensions YANG draft > > Hi Qin, > > > > The parent interface leaf is just one of the augmentations and is effectively the minimal information that you need to have a logical sub-interface. > > [Qin]: I see, sounds like tunnel interface defined in the draft-wwz-netmod-yang-tunnel-cfg-00 also intends to support several similar properties which make me believe you guys has some same goal. Both augment if:interface with interface specific, I am wondering which one draft has better model design, one is to place all common properties in one place while the other is distribute common properties in several places within if:interface. Yes, there is some overlap here, and I agree that there is a question of direction. It is the requirement to use XML namespaces that made me think that defining a given property in single place that spans across interfaces is easier to use. If you take the MTU lead as an example - this has been defined by both models. If you follow the way that I have proposed then the path "/if:interfaces/if:interface[if:name = XXX]/if-cmn:l2-mtu" is valid for any interface (that implements the interfaces-common YANG module). E.g. a YANG client has a well defined path to access the MTU item for any interface. An alternative approach, is for each type of interface to define an mtu leaf for that given interface type. With a bit of effort you could get the MTU node to have the same name and semantics for all interface types, but it would always have a different namespace for each interface type. Hence, to write a client function that generically gets/sets the MTU on an interface you need to know the interface type to be able to map it to the appropriate namespace that the MTU leaf has been defined in. I thought that this would be awkward and hence better to just define it in a single place. So if an approach like draft-wilton-netmod-intf-ext-yang-00 is agreed then I think that it might somewhat change the structure of draft-wwz-netmod-yang-tunnel-cfg-00 in the following way: - ip-address would be defined by the ip-cfg YANG module. - encapsulation method could potentially augment from the encapsulation choice node that has been defined in draft-wilton-netmod-intf-ext-yang-00 - MTU would be defined by l2-mtu in draft-wilton-netmod-intf-ext-yang-00 - QoS I would suggest would be defined by DiffServ or other QoS feature implementation. I.e. in essence I would think that perhaps gen-tunnel should only define properties that are strictly common to all tunnel interfaces, but that are not more widely common across all/most interfaces. Thanks, Rob From nobody Wed Jul 15 08:50:10 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 195861B2BC2 for ; Wed, 15 Jul 2015 08:50: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, HTML_MESSAGE=0.001, 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 ItnLeZNGBY7I for ; Wed, 15 Jul 2015 08:50: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 65D991B2BDF for ; Wed, 15 Jul 2015 08:49:53 -0700 (PDT) Received: from [10.147.40.77] (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 880381AE046E; Wed, 15 Jul 2015 17:49:51 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E07B390B-0B7E-4088-807B-0F72AB397D04"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Jan Lindblad In-Reply-To: <3A2493D0-75B9-46C9-917A-F3CBD274CE99@gmail.com> Date: Wed, 15 Jul 2015 17:49:10 +0200 Message-Id: <39AACF18-83A6-4BB7-86DD-39FF20B63099@tail-f.com> References: <3A2493D0-75B9-46C9-917A-F3CBD274CE99@gmail.com> To: Ladislav Lhotka , Dean Bogdanovic X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ACL model problem 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, 15 Jul 2015 15:50:09 -0000 --Apple-Mail=_E07B390B-0B7E-4088-807B-0F72AB397D04 Content-Type: multipart/alternative; boundary="Apple-Mail=_D3A6C311-84D5-458D-AE74-F1CCD7B041D6" --Apple-Mail=_D3A6C311-84D5-458D-AE74-F1CCD7B041D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lada, Dean, > Lada, >=20 > Our original intention was to be able to define wild cards for source = and destination ports, but what you are suggesting is also an option and = I agree your suggestion is better, so adding presence statement to port = containers, as in example below, would be the right solution >=20 > grouping acl-transport-header-fields { > description > "Transport header fields"; > container source-port-range { > presence =E2=80=9CEnables source port range=E2=80=9D; > description > "Inclusive range representing source ports to be used. > When only lower-port is present, it represents a single = port."; > : > : >=20 > Have fixed it in the model and will update on Monday the draft Another alternative is to leave the container as np-container, and make = the elements optional instead. This reduces the number of elements in = the configuration database and number of constraints the operator has to = abide by (might forget) and the system has to check. The expressiveness = is the same. container source-port-range { description "Specification of source port or port range."; leaf lower-port { type inet:port-number; description "When set, specifies the specific port or lower bound of = the port range this ACE rule applies to."; } leaf upper-port { type inet:port-number; description "When set, specifies the upper bound of the port range = this ACE rule applies to. The lower-port must also be set."; must ". > ../lower-port" { description "This expression is only true if lower-port exists and = is less than this element."; error-message "Lower-port is required, and must be less than = upper-port"; } } } >=20 /jan --Apple-Mail=_D3A6C311-84D5-458D-AE74-F1CCD7B041D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Lada, Dean,

Lada,

Our original intention = was to be able to define wild cards for source and destination ports, = but what you are suggesting is also an option and I agree your = suggestion is better, so adding presence statement to port containers, = as in example below, would be the right solution

grouping = acl-transport-header-fields {
    = description
      "Transport header = fields";
    container source-port-range = {
      = presence =E2=80=9CEnables source port range=E2=80=9D;
      description
  =       "Inclusive range representing source ports to be = used.
        When only = lower-port is present, it represents a single port.";
      :
    =   :

Have = fixed it in the model and will update on Monday the = draft

Another alternative is to leave the container as = np-container, and make the elements optional instead. This reduces the = number of elements in the configuration database and number of = constraints the operator has to abide by (might forget) and the system = has to check. The expressiveness is the same.

container source-port-range {
  = description "Specification of source port or port range.";
  = leaf lower-port {
    type inet:port-number;
  =   description "When set, specifies the specific port or lower bound = of the port range this ACE rule applies to.";
  = }
  leaf upper-port {
    type = inet:port-number;
    description "When set, specifies = the upper bound of the port range this ACE rule applies to. The = lower-port must also be set.";
    must ". = > ../lower-port" {
      description "This = expression is only true if lower-port exists and is less than this = element.";
      error-message "Lower-port is = required, and must be less than upper-port";
  =   }
  }
}

<= /div>

/jan

= --Apple-Mail=_D3A6C311-84D5-458D-AE74-F1CCD7B041D6-- --Apple-Mail=_E07B390B-0B7E-4088-807B-0F72AB397D04 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 iQEcBAEBCgAGBQJVpoD3AAoJEBSCnbqufIiszxgH/3CwZ70ZnjQfpda7BanHlbUF b11Q7juanFEWqTJoECrKxHhsh8hwkBg2Gn58ltRQLjitTTKk4eSm+jwI/r4l1NA4 1FQK99fEauUpsV5qpDA7tr7fysovvqxf3jsSG6W5N4m4F5urbL1EYWZZYVXlKRWV RRw97DOetuWH+mU6KYMQWimzq958AsOiyGU5f+HqVrqb/RU6Q26JSy654YWONJGT RYZKZvbIqpFl93Ignvs0+LNqGGau4hNvV4zhMcoT0oX9Oza+ahRvHLJJcknWpSuH 6e7JF03i3yCAy3VXxMcSm8atuQgJWOUzlmEibzmYOzfO4+uTuTCLPvGc6BNBKP4= =JQ6+ -----END PGP SIGNATURE----- --Apple-Mail=_E07B390B-0B7E-4088-807B-0F72AB397D04-- From nobody Wed Jul 15 13:05:25 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 D4ED01ACE16 for ; Wed, 15 Jul 2015 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 yCK6dDyBGtdw for ; Wed, 15 Jul 2015 13:05:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80991ACE13 for ; Wed, 15 Jul 2015 13:05:20 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 20:05:16 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 15 Jul 2015 20:05:15 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) with mapi id 15.01.0213.000; Wed, 15 Jul 2015 20:05:15 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: Agenda posted for IETF 93 meeting Thread-Index: AQHQvzmQspG/PexnTUKSzdxkngTaIA== Date: Wed, 15 Jul 2015 20:05:15 +0000 Message-ID: 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: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:4pVENvFXqpfyku0mkXikrshXqM6Jk8zmdsd7lg//2THxNWQLgpYkRrUTofk/YwoPf/8ag+tr3JA8u/7DjxR6xZqi/bb90bBy7LedxAYW8kI7F8KQa/OOQ0d3xhpqpZGqvRyKYLbJ2MCruWX9mp5J9A==; 24:XZYF4/gT0wq+s80lKjx5JHLKSubWHrAqzqtNqg0NpU9gQ2K6YEHtYn+l244EbvWoC0kYgQxA6lEDIsQtj2Uy6qRLaLadKRJceFvWI+EF/Zc=; 20:SEfNQj7bBDGAxlgpVHfZLAiCco8KqbX3lOKHaG4rhxvsGbElGOUMwCKuImwUeCLvu7boRs7wgdXSmJ2ChEaYsw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; co1pr05mb460: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(2351001)(54356999)(50986999)(36756003)(229853001)(2656002)(4001350100001)(92566002)(5002640100001)(66066001)(189998001)(2900100001)(2501003)(102836002)(106116001)(15975445007)(83506001)(122556002)(86362001)(19580395003)(77156002)(107886002)(16236675004)(5001960100002)(87936001)(62966003)(19617315012)(40100003)(46102003)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1CC3539BEC40kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2015 20:05:15.6867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB457; 2:/Y8jpufHTkIle80iH9Q/Ag9cUOtFNDkvgrZ9JegSTtD7K2M2LJEraSznpYjTBKoQ; 3:WULwBG+o939gCE+kKD0uAN+4hgzLmST6Uu8CSv2tVQm52IMKofc8N6UJyezlt9+ji/cMsKnuAaqZdIg119LRIP9fN2dReGo9AyK9l31KYpKpWOultP4fWtTrOX5A/U6aB0RszQdkxP3FbJ6aCGcMYA==; 25:eD/eVC1R/2u/LnZiyAoog3B5cZLbNgpj8+f18Wb5qTU7rgPQ8J3DDW6NIpZ9L+Bv4ToWm0dhvdAOtuobkW1HPzc0AVNx3xVB8Qp8OKvgV2FsUtntD+RquOrQPta+1JYbgqn6sRq7yvBZblr59lBZXPrw7oJ6M3sGLKkSs3NqOVTWsJsizRJdooCP60BVTRYseiuQWdcV/9szg0C/mQLksIgx4PDBBqIGmnzsxeYY75x16xXBDMdb5f1UeR2MO0vc4pOwoNg84XVSqjKb26BApQ==; 20:UpMuxw8Wx5BllBYI8Z98dXLbeMUebpG86oM/pdXwcSdg9FlzCNsNlucEWuV1di3R+Jp3fTZL09J/t/PkxcWa7g==; 23:EH2pqkEulabQ/N4sM3SK/mAwFVipmX7GAqnckPnNa6JDaNa8tb/hDzDqmJF9muSE0C/pHFpx4eM0Gu64Khp7ubM1l0EqM909/7qmfbLBO7/gzq1+3CBoGDpL0uppxTc4VR5GU9OynX4JLaNrBEvh3rr5KpCuXaY3w9ApSV97dK5+DDx8eqfi5SbHBJdGtnAEx7T+fMPAxSnkEd2EzmEy+O76NmdqHCjWkcUMqsGAUi9ugkzJIZ0nrse6/eZEoJtC CO1PR05MB457: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Subject: [netmod] Agenda posted for IETF 93 meeting 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, 15 Jul 2015 20:05:23 -0000 --_000_D1CC3539BEC40kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda for the two NETMOD sessions has been posted here: https://www.ietf.org/proceedings/93/agenda/agenda-93-netmod Please note that a discussion regarding Open Config will not occur due to s= cheduling conflicts. Otherwise, please let us know if any adjustments are = needed. Thanks, Kent --_000_D1CC3539BEC40kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <035E0FFA8D40C9488CF2BADE10AD186C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

The preliminary agenda for the two NETMOD sessions has been posted her= e:


Please note that a discussion regarding Open Config will not occur due= to scheduling conflicts.  Otherwise, please let us know if any adjust= ments are needed.

Thanks,
Kent




--_000_D1CC3539BEC40kwatsenjunipernet_-- From nobody Wed Jul 15 19:31:17 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 472941B350C for ; Wed, 15 Jul 2015 19:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, T_FILL_THIS_FORM_SHORT=0.01, 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 XErzqkfbEMVF for ; Wed, 15 Jul 2015 19:31:10 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 890CB1B3503 for ; Wed, 15 Jul 2015 19:31:06 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06C7tgHq9qZV17MqCw==.49520S2; Thu, 16 Jul 2015 08:12:41 +0800 (CST) From: "Aijun Wang" To: "'Qin Wu'" , References: <00de01d0b7a1$323339e0$9699ada0$@org.cn> <004b01d0bed1$eb2558c0$c1700a40$@org.cn> In-Reply-To: Date: Thu, 16 Jul 2015 10:30:19 +0800 Message-ID: <007201d0bf6f$64eb6d50$2ec247f0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0073_01D0BFB2.730EAD50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQvq4XZV95oTjfskWTpLL6pUXaNJ3cGd0wgABLsHCAAOw54A== Content-Language: zh-cn X-CM-TRANSID: Z0GX06C7tgHq9qZV17MqCw==.49520S2 X-Coremail-Antispam: 1U3129KBjvJXoWxWFy3tryUZw1UKryfCrW8Crg_yoWrAw1rpF W5GFZ8Kr4DGr1rCan7Za18Xw4Y9393K3y5uFn5G3y8A345Jry3Zryjk3yayF47CrWrXr1j vrWj93WUuayDZ3DanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjPqb7 Iv0xC_Jr1lb4IE77IF4wAFF20E14v26r1j6r4UM7C26xCjj4IEI4klw4CSwwAFxVCaYxvI 4VCIwcAKzIAtM2AExVA0xI801c8C04v7McIj6x8ErcxFaVAv8VW8AwACY4xI64xv4xAvw2 CEb4CIw280cs4lx4CE17CEb7AF67AKxVWUXVWUAjIFyTuYvjfUFE_MDUUUU Archived-At: Subject: Re: [netmod] New Version Notification for draft-wwz-netmod-yang-tunnel-cfg-00.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, 16 Jul 2015 02:31:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01D0BFB2.730EAD50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Qin, I think the answer from Robert to Mahesh on July 14(please see the = detail on the attached mail) best describes the key point of " = draft-wilton-netmod-intf-ext-yang-00": ".... Yes, I agree that a better name would be helpful, and definitely = welcome suggestions. The problem is that the module doesn't just apply = to physical interfaces. Quite a lot of the properties apply to any = interface on a router/switch, and some of the properties I would think = could apply to any network interface (e.g. MTU). Perhaps something = related to lower-layer-interface-extensions?....". The above statement show clearly the main concern of " = draft-wilton-netmod-intf-ext-yang-00", which is different from the " = draft-wwz-netmod-yang-tunnel-cfg-00.txt" . The latter draft concern = mainly the "upper-layer-interface-extensions". Some characteristics may = have same name, but different denotation(for example "MTU", it has = different value in lower-layer-interface and upper-layer-interface).=20 >From the model user viewpoint, it is benefit to separate the = lower-layer-interface and upper-layer-interface into two yang models, we = should clarify with deep consideration the belonging of the seeming = "over-lapping" characteristics, although there is not much of them from = these two drafts now. Aijun Wang China Telecom Corporation Limited Beijing Research Institute=20 Intelligent Network Product Line Tel : 010-58552347 Mobile: 13301168517 -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: Wednesday, July 15, 2015 7:38 PM To: Aijun Wang; netmod@ietf.org Subject: RE: [netmod] New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt Aijun: Please see my reply to Robert, I am afraid = draft-wilton-netmod-intf-ext-yang-00 is not limited to describe common = l2 characteristic of the interface. Then tunnel interface in draft-wwz-netmod-yang-tunnel-cfg-00 and = interface extension proposed in draft-wilton-netmod-intf-ext-yang-00 = share some Common properties, so what is the better model design? Place = all the properties in one place under tunnel interface or move these = properties in In the same level as other properties defined under = if:interface? -Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Aijun Wang = [mailto:wangaijun@tsinghua.org.cn] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B47=E6=9C=8815=E6=97=A5 = 15:43 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu; netmod@ietf.org =E4=B8=BB=E9=A2=98: RE: [netmod] New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt Hi, Qin: Thanks for your comments first. Below is my answer to your question: 1. As you pointed out, " draft-wilton-netmod-intf-ext-yang-00" focuses = mainly on the common layer 2 characteristic of one interface, it = augments the ietf: if-interface yang model and compensates the = characteristic of one physical interface. 2. Draft "draft-wwz-netmod-yang-tunnel-cfg-00.txt" designs the general = tunnel interface model on top of the physical interface model, It covers = and references the characteristics defined both in basic ietf: = if-interface and its augment layer2 characteristic model, for example = that defined in "draft-wilton-netmod-intf-ext-yang-00".=20 Do the above descriptions clarify the relationship between them? Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Intelligent = Network Product Line -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Wednesday, July 15, 2015 11:27 AM To: Aijun Wang; netmod@ietf.org Subject: RE: [netmod] New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt Authors: I think this draft will be useful when we consider to choose and = configure large number of different technology specific tunnels that = share a lot of common properties. One question I have here is how this draft is related to = draft-wilton-netmod-intf-ext-yang-00? If my understanding is correct, your draft is about interface extension = for tunneling management. draft-wilton-netmod-intf-ext-yang-00 focuses = on interface extension for L2 sub-interface. But two draft follows two different model design, you specify common = properties within tunnel container while = draft-wilton-netmod-intf-ext-yang-00 specifies common properties = directly within if:interface. -Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Aijun Wang =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B47=E6=9C=886=E6=97=A5 = 12:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org =E4=B8=BB=E9=A2=98: [netmod] New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt Hi, all: We submitted one new draft = (https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00) that = described one general model for the tunnel services used within service = provider network. It summaries the common characteristic of the current = various tunnel protocols and can be used as one fundamental model for = the specific tunnel technology.=20 Any feedback is welcome. Best Regard. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, July 03, 2015 4:21 PM To: Zitao Wang; Yan Zhuang; Aijun Wang; Zhuangyan; Zitao Wang; Aijun = Wang Subject: New Version Notification for = draft-wwz-netmod-yang-tunnel-cfg-00.txt A new version of I-D, draft-wwz-netmod-yang-tunnel-cfg-00.txt has been successfully submitted by Zitao Wang and posted to the IETF = repository. Name: draft-wwz-netmod-yang-tunnel-cfg Revision: 00 Title: YANG Data Model for Tunnel Management Document date: 2015-07-03 Group: Individual Submission Pages: 21 URL: = https://www.ietf.org/internet-drafts/draft-wwz-netmod-yang-tunnel-cfg-00.= txt Status: = https://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/ Htmlized: = https://tools.ietf.org/html/draft-wwz-netmod-yang-tunnel-cfg-00 Abstract: This document defines a YANG data model for the configuration and management of generic tunnels. The data model includes configuration data and state data. And it can serve as a base model which is augmented with technology-specific details in other, more specific tunnel models. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0073_01D0BFB2.730EAD50 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvsrjnVuD1iq for ; Tue, 14 Jul 2015 10:29:12 -0700 (PDT) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6975A1ACEE3 for ; Tue, 14 Jul 2015 10:29:14 -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 61EF41ACEE1 for ; Tue, 14 Jul 2015 10:29:11 -0700 (PDT) Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6EHT82L016052; Tue, 14 Jul 2015 17:29:09 GMT 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 Jul 2015 17:29:09 +0000 Received: from mail.ietf.org (unknown [4.31.198.44]) by app2 (Coremail) with SMTP id aEGX06ArFAAyJ6VVJiIzDA==.22180S2; Tue, 14 Jul 2015 23:13:55 +0800 (CST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E251ACEEA; Tue, 14 Jul 2015 10:29:15 -0700 (PDT) From: "Robert Wilton" Sender: "netmod" To: "Mahesh Jethanandani" Cc: References: <559D4BA1.30605@cisco.com> <57E9F3A1-6F47-4977-9904-E0B16B3BD6F4@gmail.com> In-Reply-To: <57E9F3A1-6F47-4977-9904-E0B16B3BD6F4@gmail.com> Subject: Re: [netmod] Interface Extensions YANG draft Date: Wed, 15 Jul 2015 01:29:08 +0800 Message-ID: <55A546E4.8010708@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006D_01D0BFB2.730E3820" X-Mailer: Microsoft Office Outlook 12.0 X-Original-To: netmod@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Thread-Index: AdC+R7MR8WCTC97aQv6M+fjN0OA+hg== X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Unsubscribe: , List-Help: List-Subscribe: , X-CM-TRANSID: aEGX06ArFAAyJ6VVJiIzDA==.22180S2 X-Coremail-Antispam: 1U3129KBjvJXoWxWFy3tryUZw1UKryfCrW8Crg_yoWrAw1rpF W5GFZ8Kr4DGr1rCan7Za18Xw4Y9393K3y5uFn5G3y8A345Jry3Zryjk3yayF47CrWrXr1j vrWj93WUuayDZ3DanT9S1TB71UUUUUUv73VFW2AGmfu7jjvjm3AaLaJ3UjIYCTnIWjp_UU U8B7k0a2IF6w4kM7kC6x804xWl14x267AKxVWUJVW8JwAFxVCF77xC6IxKo4kEV4yl1I0E scIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lF7I21c0EjII2zVCS5cI20VAGYxC7Mx 02cVCv0xWlc7I2V7IY0VAS07AlzVAYIcxG8wCY1x0264kExVAvwVAq07x20xylc2IjII80 xcxEwVAKI48JMxvI42IY6xIIjxv20xvE14v26r1j6r1xMxvI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lcIIF0xvEx4A2jsIE14v26r1j6r4UMxvI42IY6I8E87Iv6xkF7I0E14v2 6r1j6r4UMxCjnVCjjxCrMI8E67AF67kF1VAFwI0_Jrv_JFUI43ZEXa7xRiNBMtUUUUU== This is a multi-part message in MIME format. ------=_NextPart_000_006D_01D0BFB2.730E3820 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006E_01D0BFB2.730E3820" ------=_NextPart_001_006E_01D0BFB2.730E3820 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Hi Mahesh, Thanks for the comments. Please see inline ... On 14/07/2015 17:21, Mahesh Jethanandani wrote: Robert, I have read your draft and consider it useful for folks who are trying to use/configure/monitor particular characteristics of a physical interface. While it is an extension of the interfaces module, a lot of modules are extensions of the interface module. A more appropriate name would probably help convey the contents of the module. How about physical-interface-extensions or phys-intr-ext for short? Yes, I agree that a better name would be helpful, and definitely welcome suggestions. The problem is that the module doesn't just apply to physical interfaces. Quite a lot of the properties apply to any interface on a router/switch, and some of the properties I would think could apply to any network interface (e.g. MTU). Perhaps something related to lower-layer-interface-extensions? More comments on the draft. 3.2. Is there a counter kept for the actual short transition changes that were suppressed? Yes, there should be. I had initially concentrated on the config side, but probably operation data needs to be considered as well. 3.6 The general suggestion in YANG is to provide for one way to do things, and leave other ways of specifying or configuring to extensions/deviations etc. With that in mind, I would think keeping one leaf for MTU that is the max. size of the layer 2 frame including header and payload would make sense. OK. Yes, I think that I'm coming to the same conclusion: Although having a single MTU value will make it harder to implement for some vendors, it makes it easier for users of the YANG module. 4. I am not a particular fan of creating yet another module for ethernet-like interfaces, when I assume there is going to be a ethernet-interface module. Is there something in this module that cannot be minimally represented by a more general IEEE ethernet-interface module? I don't envisage there needing to be any additional configuration in the Ethernet-like module beyond what is already there - possibly some Ethernet framing related statistics. There are a few reasons that I put this in a separate module to ethernet: 1) It doesn't just apply to 802.3 Ethernet interfaces, but any interfaces that use Ethernet framing. 2) I wasn't sure whether the IEEE 802.3 WG would want to standardize a module that covers other interface types beyond native Ethernet. 3) There is already an etherlike.mib (although that only covers stats that applies to any Ethernet framed interfaces). Is your primary concern over the fact that this module is too small to justify its independent existence? Thanks, Rob Thanks. On Jul 8, 2015, at 9:11 AM, Robert Wilton wrote: Hi, I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices. E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses. I am hoping that this draft could be adopted and standardized by the netmod WG. https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ Any comments or feedback is appreciated. Potential points of interest/discussion may be: - Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented? - We've tried to restrict the leaves to just the interface types (using when if:type = ...) that the configuration applies to rather than adding them to all interfaces. Feedback would be welcome on whether this approach is a good idea/maintainable. - For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not. Is this a reasonable approach? Thanks, Rob _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_001_006E_01D0BFB2.730E3820 Content-Type: text/html; boundary="===============4022350752338689747=="; charset="windows-1252" Content-Transfer-Encoding: quoted-printable =20 Hi Mahesh,

Thanks for the comments.=A0 Please see inline ...

On 14/07/2015 17:21, Mahesh Jethanandani wrote:
Robert,

I have read your draft and consider it useful for folks who are trying to use/configure/monitor particular characteristics of a physical interface. While it is an extension of the interfaces module, a lot of modules are extensions of the interface module. A more appropriate name would probably help convey the contents of the module. How about physical-interface-extensions or phys-intr-ext for short?

Yes, I agree that a better name would be helpful, and definitely welcome suggestions.=A0 The problem is that the module doesn't just apply to physical interfaces.=A0 Quite a lot of the properties apply to any interface on a router/switch, and some of the properties I would think could apply to any network interface (e.g. MTU).=A0 Perhaps something related to lower-layer-interface-extensions?


More comments on the draft.

3.2.

Is there a counter kept for the actual short transition changes that were suppressed?

Yes, there should be.=A0 I had initially concentrated on the config side, but probably operation data needs to be considered as = well.
=A0


3.6

The general suggestion in YANG is to provide for = one way to do things, and leave other ways of specifying or configuring to extensions/deviations etc. With that in mind, I would think keeping one leaf for MTU that is the max. size of the layer 2 frame including header and payload would make = sense.
OK.=A0 Yes, I think that I'm coming to the same conclusion: Although having a single MTU value will make it harder to implement for some vendors, it makes it easier for users of the YANG module.


4.

I am not a particular fan of creating yet another module for ethernet-like interfaces, when I assume there is going to be a ethernet-interface module. Is there something in this module that cannot be minimally represented by a more general IEEE ethernet-interface module?

I don't envisage there needing to be any additional configuration in the Ethernet-like module beyond what is already there - possibly some Ethernet framing related statistics.

There are a few reasons that I put this in a separate module to ethernet:
=A01) It doesn't just apply to 802.3 Ethernet interfaces, but any interfaces that use Ethernet framing.
=A02) I wasn't sure whether the IEEE 802.3 WG would want to standardize a module that covers other interface types beyond native Ethernet.
=A03) There is already an etherlike.mib (although that only covers stats that applies to any Ethernet framed interfaces).

Is your primary concern over the fact that this module is too small to justify its independent existence?

Thanks,
Rob



Thanks.

On Jul 8, 2015, at 9:11 AM, Robert Wilton = <rwilton@cisco.com> wrote:

Hi,

I have submitted a new draft for provides several augmentations to the ietf if:interfaces to define configuration YANG for basic interface parameters that are commonly supported on network devices. =A0E.g. it is includes leaves such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface parent ref, and configurable interface MAC addresses. =A0I am hoping that this draft could be adopted and standardized by the netmod WG.

https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-= yang/

Any comments or feedback is appreciated.

Potential points of interest/discussion may be:
- Is it acceptable to define standard YANG for features that are not backed by any formal standard if they are commonly implemented?
- We've tried to restrict the leaves to just the interface types (using when if:type =3D ...) that the configuration applies to rather than adding them to all interfaces. =A0Feedback would be welcome on whether this approach is a good idea/maintainable.
- For MTU, I've defined two different MTU leaves because devices program interface MTU in different ways based on whether the configured MTU value includes the L2 header overhead or not. =A0Is this a reasonable approach?

Thanks,
Rob

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

Mahesh Jethanandani
mjethanandani@gmail.com






------=_NextPart_001_006E_01D0BFB2.730E3820-- ------=_NextPart_000_006D_01D0BFB2.730E3820 Content-Type: text/plain; name="ATT00020.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00020.txt" _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_006D_01D0BFB2.730E3820-- ------=_NextPart_000_0073_01D0BFB2.730EAD50-- From nobody Thu Jul 16 00:30:17 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 E52B81B36C5 for ; Thu, 16 Jul 2015 00:30:15 -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 D35i1sKnw_0H for ; Thu, 16 Jul 2015 00:30:14 -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 41AD31B36B6 for ; Thu, 16 Jul 2015 00:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3035; q=dns/txt; s=iport; t=1437031814; x=1438241414; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=By6LKDTsS/lT0A8sBctic1CefO3fJfyr6Xg93Bfd9jY=; b=O674SZ9keo/pApDa6WATJ8o1zEHErddXbKgvUlyH5pVpsYPf9qqk8aOH MwcXQBRrTxn9ixRyus2pVzyZbFxp1E+9BXn4QIL4+LfaIMKYj2bI3Pe1+ nKf/m7tp5S5qQYelPdXf5n6DqkwraPn5kb9TP2zHcHv2ZcN3imaXxAjww 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DhAgBYXKdV/xbLJq1bg2dpu0IJgWwBCYUtSgKBfxQBAQEBAQEBgQqEJAEBBAEBAWsKEQsEChMWDwkDAgECARUwBgEMBgIBAYgqDc88AQEBAQEBAQEBAQEBAQEBAQEBFgSLTIUNhCsBBJRGjBiBQ4QZgm6QNSZjgxs8MYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,486,1432598400"; d="scan'208,217";a="567796264" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Jul 2015 07:30:12 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6G7UCOa029934; Thu, 16 Jul 2015 07:30:12 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Benoit Claise Message-ID: <55A75D84.8080306@cisco.com> Date: Thu, 16 Jul 2015 09:30:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010209000708030500030306" Archived-At: Subject: Re: [netmod] Agenda posted for IETF 93 meeting 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, 16 Jul 2015 07:30:16 -0000 This is a multi-part message in MIME format. --------------010209000708030500030306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, > > The preliminary agenda for the two NETMOD sessions has been posted here: > > https://www.ietf.org/proceedings/93/agenda/agenda-93-netmod > > Please note that a discussion regarding Open Config will not occur due > to scheduling conflicts. Fine, but let's not postpone these important discussions too long. Regards, Benoit > Otherwise, please let us know if any adjustments are needed. > > Thanks, > Kent > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------010209000708030500030306 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

The preliminary agenda for the two NETMOD sessions has been posted here:


Please note that a discussion regarding Open Config will not occur due to scheduling conflicts.
Fine, but let's not postpone these important discussions too long.

Regards, Benoit
Otherwise, please let us know if any adjustments are needed.

Thanks,
Kent






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

--------------010209000708030500030306-- From nobody Thu Jul 16 01:00:20 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 1BC1F1B3734 for ; Thu, 16 Jul 2015 01:00: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 wQwuBCeqJpPN for ; Thu, 16 Jul 2015 01:00:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 028091B3732 for ; Thu, 16 Jul 2015 01:00:17 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 7777C1CC024F; Thu, 16 Jul 2015 10:00:17 +0200 (CEST) From: Ladislav Lhotka To: Jan Lindblad , Dean Bogdanovic In-Reply-To: <39AACF18-83A6-4BB7-86DD-39FF20B63099@tail-f.com> References: <3A2493D0-75B9-46C9-917A-F3CBD274CE99@gmail.com> <39AACF18-83A6-4BB7-86DD-39FF20B63099@tail-f.com> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 16 Jul 2015 10:00:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ACL model problem 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, 16 Jul 2015 08:00:19 -0000 Jan Lindblad writes: > Lada, Dean, > >> Lada, >>=20 >> Our original intention was to be able to define wild cards for source an= d destination ports, but what you are suggesting is also an option and I ag= ree your suggestion is better, so adding presence statement to port contain= ers, as in example below, would be the right solution >>=20 >> grouping acl-transport-header-fields { >> description >> "Transport header fields"; >> container source-port-range { >> presence =E2=80=9CEnables source port range=E2=80=9D; >> description >> "Inclusive range representing source ports to be used. >> When only lower-port is present, it represents a single port."; >> : >> : >>=20 >> Have fixed it in the model and will update on Monday the draft > > Another alternative is to leave the container as np-container, and > make the elements optional instead. This reduces the number of > elements in the configuration database and number of constraints the > operator has to abide by (might forget) and the system has to > check. The expressiveness is the same. I don't see why the presence container should increase the number of elements in the configuration database. Either way, the "source-port-range" container may be present or not. The constraints should also be the same: If "source-port-range" specification is present, then "lower-port" is mandatory, and "upper-port" (if present) must be greater than "lower-port". I think the setup with presence container is the most logical one, and "mandatory true" on "lower-port" is a schema constraint which can be checked even in candidate. Lada > > container source-port-range { > description "Specification of source port or port range."; > leaf lower-port { > type inet:port-number; > description "When set, specifies the specific port or lower bound of = the port range this ACE rule applies to."; > } > leaf upper-port { > type inet:port-number; > description "When set, specifies the upper bound of the port range th= is ACE rule applies to. The lower-port must also be set."; > must ". > ../lower-port" { > description "This expression is only true if lower-port exists and = is less than this element."; > error-message "Lower-port is required, and must be less than upper-= port"; > } > } > } >>=20 > > > /jan > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 16 01:20:23 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 DB5571B3765 for ; Thu, 16 Jul 2015 01:20:21 -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, HTML_MESSAGE=0.001, 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 LljmXBJQRgy5 for ; Thu, 16 Jul 2015 01:20:19 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8508B1B3764 for ; Thu, 16 Jul 2015 01:20:19 -0700 (PDT) Received: from [10.147.40.77] (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8080C1AE0286; Thu, 16 Jul 2015 10:20:17 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_837D3129-1355-4255-B707-24D8C1105C5F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Jan Lindblad In-Reply-To: Date: Thu, 16 Jul 2015 10:19:39 +0200 Message-Id: References: <3A2493D0-75B9-46C9-917A-F3CBD274CE99@gmail.com> <39AACF18-83A6-4BB7-86DD-39FF20B63099@tail-f.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ACL model problem 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, 16 Jul 2015 08:20:22 -0000 --Apple-Mail=_837D3129-1355-4255-B707-24D8C1105C5F Content-Type: multipart/alternative; boundary="Apple-Mail=_6424616A-3B75-4D73-B5B2-D4409B8BF7DF" --Apple-Mail=_6424616A-3B75-4D73-B5B2-D4409B8BF7DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lada, This is no big deal, both solutions would work. Let me anyhow = demonstrate the difference I'm pointing at. Presence-solution: Objects that have a footprint in the data store: + p-container source-port-range + leaf lower-port + leaf upper-port i.e. 3 objects for an operator and system to track Constraints: + mandatory true stmt on lower-port + must stmt on upper-port i.e. 2 constraints for operators to abide by and systems to check. Must-solution: Objects that have a footprint in the data store: + leaf lower-port + leaf upper-port i.e. 2 objects for an operator and system to track Constraints: + must stmt on upper-port i.e. 1 constraint for operators to abide by and systems to check. This means the must-solution takes less space and less time to check. = More importantly it has one failure mode less than the = presence-solution. The operator might create source-port-range, but not = set lower port. This is not possible in the must-solution. Nit pick = differences, I know. I can live with either solution, but lean slightly = towards the must-solution. In my mind it's simpler. /jan >>> Our original intention was to be able to define wild cards for = source and destination ports, but what you are suggesting is also an = option and I agree your suggestion is better, so adding presence = statement to port containers, as in example below, would be the right = solution >>>=20 >>> grouping acl-transport-header-fields { >>> description >>> "Transport header fields"; >>> container source-port-range { >>> presence =E2=80=9CEnables source port range=E2=80=9D; >>> description >>> "Inclusive range representing source ports to be used. >>> When only lower-port is present, it represents a single = port."; >>> : >>> : >>>=20 >>> Have fixed it in the model and will update on Monday the draft >>=20 >> Another alternative is to leave the container as np-container, and >> make the elements optional instead. This reduces the number of >> elements in the configuration database and number of constraints the >> operator has to abide by (might forget) and the system has to >> check. The expressiveness is the same. >=20 > I don't see why the presence container should increase the number of > elements in the configuration database. Either way, the > "source-port-range" container may be present or not. >=20 > The constraints should also be the same: If "source-port-range" > specification is present, then "lower-port" is mandatory, and > "upper-port" (if present) must be greater than "lower-port". >=20 > I think the setup with presence container is the most logical one, and > "mandatory true" on "lower-port" is a schema constraint which can be > checked even in candidate. >=20 > Lada --Apple-Mail=_6424616A-3B75-4D73-B5B2-D4409B8BF7DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Lada,

This = is no big deal, both solutions would work. Let me anyhow demonstrate the = difference I'm pointing at.


Presence-solution:

Objects that have a footprint in the data store:
+ p-container = source-port-range
+ = leaf lower-port
+ = leaf upper-port
i.e. = 3 objects for an operator and system to track

Constraints:
+ mandatory true stmt on = lower-port
+ must = stmt on upper-port
i.e.= 2 constraints for operators to abide by and systems to check.


Must-solution:

Objects that have a footprint = in the data store:
+ = leaf lower-port
+ = leaf upper-port
i.e. = 2 objects for an operator and system to track

Constraints:
+ must stmt on upper-port
i.e. 1 constraint for operators = to abide by and systems to check.


This = means the must-solution takes less space and less time to check. More = importantly it has one failure mode less than the presence-solution. The = operator might create source-port-range, but not set lower port. This is = not possible in the must-solution. Nit pick differences, I know. I can = live with either solution, but lean slightly towards the must-solution. = In my mind it's simpler.

/jan





Our original intention = was to be able to define wild cards for source and destination ports, = but what you are suggesting is also an option and I agree your = suggestion is better, so adding presence statement to port containers, = as in example below, would be the right solution

grouping acl-transport-header-fields {
   description
     "Transport header fields";
   container source-port-range {
     presence =E2=80=9CEnables = source port range=E2=80=9D;
     description
       "Inclusive range = representing source ports to be used.
       When only = lower-port is present, it represents a single port.";
     :
     :

Have fixed it in the model and will update on Monday the = draft

Another alternative is = to leave the container as np-container, and
make the = elements optional instead. This reduces the number of
elements in the configuration database and number of = constraints the
operator has to abide by (might forget) = and the system has to
check. The expressiveness is the = same.

I don't see why the presence = container should increase the number of
elements in the configuration = database. Either way, the
"source-port-range" container = may be present or not.

The constraints should also be = the same: If "source-port-range"
specification is present, then = "lower-port" is mandatory, and
"upper-port" (if present) must = be greater than "lower-port".

I think the setup with presence = container is the most logical one, and
"mandatory true" on "lower-port" = is a schema constraint which can be
checked even in = candidate.

Lada


= --Apple-Mail=_6424616A-3B75-4D73-B5B2-D4409B8BF7DF-- --Apple-Mail=_837D3129-1355-4255-B707-24D8C1105C5F 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 iQEcBAEBCgAGBQJVp2kcAAoJEBSCnbqufIisvLIIALvsMusO7P+dkcfN9KsbNfYL Q2mVkvCxmAt5y/6n/GuoB6ZSVWqpX+UDCpDOneIt+g7xE9gucxOpGcaoe/Ky8wjf qw+G1D2Ov/sSagPHjUBwUh56ofzIb73zh8bvnJD294lnGvSP88a1zF1fkjSlTXBC FinlFNaIXtZaoprfN2YXiaAPqb+BMUj4phuc+rfp9IVQec+pbitdJglomKukr1vW mBj4uKSZ7k4tz/L2pjGUGmROy89ZgdxtDjnwhrsXqjXvCNUaZB8mnucyOOHZlvXu bWNOYO739Lf7PUSarz3/O5O6XJ4V3Z6+Y9dkj35MHgoSO/uFjtPem+n1V4yGaQU= =IWLF -----END PGP SIGNATURE----- --Apple-Mail=_837D3129-1355-4255-B707-24D8C1105C5F-- From nobody Thu Jul 16 04:10: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 325AB1B39B9 for ; Thu, 16 Jul 2015 04:10:01 -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 KamhvU5lcuVQ for ; Thu, 16 Jul 2015 04:09:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FDA1B35D8 for ; Thu, 16 Jul 2015 04:09:58 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:75b7:76a3:a0ae:ae3b] (unknown [IPv6:2001:718:1a02:1:75b7:76a3:a0ae:ae3b]) by mail.nic.cz (Postfix) with ESMTPSA id B14E41816EC; Thu, 16 Jul 2015 13:09:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437044995; bh=uT/nr98wl+6g3AZBUSqmbgwW5p2pCoPO0X9yUZowVTw=; h=From:Date:To; b=Wku/d6SjQuV8qDi61v8s9Hs1fnlHC3xW0K0gUWFjYcBMETgNcybY/WAGDFZ9fl7CW I3a5slQstY9lVsI4aCEfcjTMh65kzAZfvzH2TSof8fIcuO5sZz1iZmPoCvXlhq3JlD IsbzEZX/aKe7ukjkhpu3QMuEBE23ROAFBew0ejpY= Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_200B8A2C-613E-40B9-8879-4297C608E5B0"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5 From: Ladislav Lhotka In-Reply-To: Date: Thu, 16 Jul 2015 13:09:59 +0200 Message-Id: <3CA537E3-8C6D-47FC-B7C2-E52B2811E4A9@nic.cz> References: <3A2493D0-75B9-46C9-917A-F3CBD274CE99@gmail.com> <39AACF18-83A6-4BB7-86DD-39FF20B63099@tail-f.com> To: Jan Lindblad X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ACL model problem 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, 16 Jul 2015 11:10:01 -0000 --Apple-Mail=_200B8A2C-613E-40B9-8879-4297C608E5B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2015, at 10:19, Jan Lindblad wrote: >=20 > Lada, >=20 > This is no big deal, both solutions would work. Let me anyhow = demonstrate the difference I'm pointing at. >=20 >=20 > Presence-solution: >=20 > Objects that have a footprint in the data store: > + p-container source-port-range > + leaf lower-port > + leaf upper-port > i.e. 3 objects for an operator and system to track >=20 > Constraints: > + mandatory true stmt on lower-port > + must stmt on upper-port > i.e. 2 constraints for operators to abide by and systems to check. >=20 >=20 > Must-solution: >=20 > Objects that have a footprint in the data store: > + leaf lower-port > + leaf upper-port > i.e. 2 objects for an operator and system to track I think the number of =E2=80=9Cobjects=E2=80=9D in either case is = implementation-specific. YANG has no notion of objects. >=20 > Constraints: > + must stmt on upper-port > i.e. 1 constraint for operators to abide by and systems to check. But we have in fact two constraints: if upper-port exists, then - lower-port must also exist - upper-port > lower-port It is just the way XPath works that both are covered by one expression. Of course, I am biased towards schema-based validation, and for it = =E2=80=9Cmandatory true=E2=80=9D is much more valuable. Actually, one = could argue that the =E2=80=9Cmandatory=E2=80=9D statement can be = replaced with =E2=80=9Cmust=E2=80=9D constraints entirely. Lada >=20 >=20 > This means the must-solution takes less space and less time to check. = More importantly it has one failure mode less than the = presence-solution. The operator might create source-port-range, but not = set lower port. This is not possible in the must-solution. Nit pick = differences, I know. I can live with either solution, but lean slightly = towards the must-solution. In my mind it's simpler. >=20 > /jan >=20 >=20 >=20 >=20 >=20 >>>> Our original intention was to be able to define wild cards for = source and destination ports, but what you are suggesting is also an = option and I agree your suggestion is better, so adding presence = statement to port containers, as in example below, would be the right = solution >>>>=20 >>>> grouping acl-transport-header-fields { >>>> description >>>> "Transport header fields"; >>>> container source-port-range { >>>> presence =E2=80=9CEnables source port range=E2=80=9D; >>>> description >>>> "Inclusive range representing source ports to be used. >>>> When only lower-port is present, it represents a single = port."; >>>> : >>>> : >>>>=20 >>>> Have fixed it in the model and will update on Monday the draft >>>=20 >>> Another alternative is to leave the container as np-container, and >>> make the elements optional instead. This reduces the number of >>> elements in the configuration database and number of constraints the >>> operator has to abide by (might forget) and the system has to >>> check. The expressiveness is the same. >>=20 >> I don't see why the presence container should increase the number of >> elements in the configuration database. Either way, the >> "source-port-range" container may be present or not. >>=20 >> The constraints should also be the same: If "source-port-range" >> specification is present, then "lower-port" is mandatory, and >> "upper-port" (if present) must be greater than "lower-port". >>=20 >> I think the setup with presence container is the most logical one, = and >> "mandatory true" on "lower-port" is a schema constraint which can be >> checked even in candidate. >>=20 >> Lada >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_200B8A2C-613E-40B9-8879-4297C608E5B0 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----- iEYEARECAAYFAlWnkQgACgkQWQVCj+dOjAyP5QCePrFExZ6YnNrV3URybzyH1sb+ z6kAn1mASF/IE+mRra3SDLIrmshsw4Vu =51x5 -----END PGP SIGNATURE----- --Apple-Mail=_200B8A2C-613E-40B9-8879-4297C608E5B0-- From nobody Thu Jul 16 05:29:22 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 CA7B31A8994 for ; Thu, 16 Jul 2015 05:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, 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 Q9dQ-J3BfXfE for ; Thu, 16 Jul 2015 05:29:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE5B1A8993 for ; Thu, 16 Jul 2015 05:29:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYV65239; Thu, 16 Jul 2015 12:29:16 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jul 2015 13:29:15 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 16 Jul 2015 20:29:06 +0800 From: Qin Wu To: Robert Wilton , wangzitao , "netmod@ietf.org" Thread-Topic: [netmod] Interface Extensions YANG draft Thread-Index: AQHQuZjA2JPLlJ1PpUGHzt5SYGcGf53YlmAAgAAtRwCAAAGTAIAANiyAgAACYICAACRGgIACqT8A////74CAAIsMEP//wa4AgAHwIVA= Date: Thu, 16 Jul 2015 12:29:06 +0000 Message-ID: References: <559D4BA1.30605@cisco.com> <55A39FEC.4090406@cisco.com> <20150713113006.GA6797@elstar.local> <55A3CEAF.7090800@cisco.com> <20150713145229.GA237@elstar.local> <55A3EF1B.4050907@cisco.com> <55A62A85.2050602@cisco.com> <55A66AE2.9070106@cisco.com> In-Reply-To: <55A66AE2.9070106@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Interface Extensions YANG draft 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, 16 Jul 2015 12:29:21 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBSb2JlcnQgV2lsdG9uIFttYWlsdG86 cndpbHRvbkBjaXNjby5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0N+aciDE15pelIDIyOjE1 DQrmlLbku7bkuro6IFFpbiBXdTsgd2FuZ3ppdGFvOyBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mimDog UmU6IFtuZXRtb2RdIEludGVyZmFjZSBFeHRlbnNpb25zIFlBTkcgZHJhZnQNCg0KSGkgUWluLA0K DQpQbGVhc2Ugc2VlIGlubGluZSAuLi4NCg0KT24gMTUvMDcvMjAxNSAxMjoyMSwgUWluIFd1IHdy b3RlOg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogUm9iZXJ0IFdpbHRv biBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTXlubQ35pyI MTXml6UgMTc6NDANCj4g5pS25Lu25Lq6OiBRaW4gV3U7IHdhbmd6aXRhbzsgbmV0bW9kQGlldGYu b3JnDQo+IOS4u+mimDogUmU6IFtuZXRtb2RdIEludGVyZmFjZSBFeHRlbnNpb25zIFlBTkcgZHJh ZnQNCj4NCj4gSGkgUWluLA0KPg0KPiA8c25pcD4NCj4NCj4gVGhlIHBhcmVudCBpbnRlcmZhY2Ug bGVhZiBpcyBqdXN0IG9uZSBvZiB0aGUgYXVnbWVudGF0aW9ucyBhbmQgaXMgZWZmZWN0aXZlbHkg dGhlIG1pbmltYWwgaW5mb3JtYXRpb24gdGhhdCB5b3UgbmVlZCB0byBoYXZlIGEgbG9naWNhbCBz dWItaW50ZXJmYWNlLg0KPg0KPiBbUWluXTogSSBzZWUsIHNvdW5kcyBsaWtlIHR1bm5lbCBpbnRl cmZhY2UgZGVmaW5lZCBpbiB0aGUgZHJhZnQtd3d6LW5ldG1vZC15YW5nLXR1bm5lbC1jZmctMDAg YWxzbyBpbnRlbmRzIHRvIHN1cHBvcnQgc2V2ZXJhbCBzaW1pbGFyIHByb3BlcnRpZXMgd2hpY2gg bWFrZSBtZSBiZWxpZXZlIHlvdSBndXlzIGhhcyBzb21lIHNhbWUgZ29hbC4gQm90aCBhdWdtZW50 IGlmOmludGVyZmFjZSB3aXRoIGludGVyZmFjZSBzcGVjaWZpYywgSSBhbSB3b25kZXJpbmcgd2hp Y2ggb25lIGRyYWZ0IGhhcyBiZXR0ZXIgbW9kZWwgZGVzaWduLCBvbmUgaXMgdG8gcGxhY2UgYWxs IGNvbW1vbiBwcm9wZXJ0aWVzIGluIG9uZSBwbGFjZSB3aGlsZSB0aGUgb3RoZXIgaXMgZGlzdHJp YnV0ZSBjb21tb24gcHJvcGVydGllcyBpbiBzZXZlcmFsIHBsYWNlcyB3aXRoaW4gaWY6aW50ZXJm YWNlLg0KWWVzLCB0aGVyZSBpcyBzb21lIG92ZXJsYXAgaGVyZSwgYW5kIEkgYWdyZWUgdGhhdCB0 aGVyZSBpcyBhIHF1ZXN0aW9uIG9mIGRpcmVjdGlvbi4gIEl0IGlzIHRoZSByZXF1aXJlbWVudCB0 byB1c2UgWE1MIG5hbWVzcGFjZXMgdGhhdCBtYWRlIG1lIHRoaW5rIHRoYXQgZGVmaW5pbmcgYSBn aXZlbiBwcm9wZXJ0eSBpbiBzaW5nbGUgcGxhY2UgdGhhdCBzcGFucyBhY3Jvc3MgaW50ZXJmYWNl cyBpcyBlYXNpZXIgdG8gdXNlLg0KDQpbUWluXTogSWYgdGhlcmUgaXMgYW55IG92ZXJsYXAsIGl0 IGlzIGJldHRlciB0byBmaXggdGhpcyBpbiB0aGUgZmlyc3QgcGxhY2UuIA0KDQpJZiB5b3UgdGFr ZSB0aGUgTVRVIGxlYWQgYXMgYW4gZXhhbXBsZSAtIHRoaXMgaGFzIGJlZW4gZGVmaW5lZCBieSBi b3RoIG1vZGVscy4NCg0KSWYgeW91IGZvbGxvdyB0aGUgd2F5IHRoYXQgSSBoYXZlIHByb3Bvc2Vk IHRoZW4gdGhlIHBhdGggIi9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZVtpZjpuYW1lID0gWFhY XS9pZi1jbW46bDItbXR1IiBpcyB2YWxpZCBmb3IgYW55IGludGVyZmFjZSAodGhhdCBpbXBsZW1l bnRzIHRoZSBpbnRlcmZhY2VzLWNvbW1vbiBZQU5HIG1vZHVsZSkuICBFLmcuIA0KYSBZQU5HIGNs aWVudCBoYXMgYSB3ZWxsIGRlZmluZWQgcGF0aCB0byBhY2Nlc3MgdGhlIE1UVSBpdGVtIGZvciBh bnkgaW50ZXJmYWNlLg0KDQpbUWluXTogSSBhbSBub3QgY29udmluY2luZyB0aGF0IGwyLW10dSBp cyBjb21tb24gdG8gYW55IGludGVyZmFjZS4gDQoNCkFuIGFsdGVybmF0aXZlIGFwcHJvYWNoLCBp cyBmb3IgZWFjaCB0eXBlIG9mIGludGVyZmFjZSB0byBkZWZpbmUgYW4gbXR1IGxlYWYgZm9yIHRo YXQgZ2l2ZW4gaW50ZXJmYWNlIHR5cGUuICBXaXRoIGEgYml0IG9mIGVmZm9ydCB5b3UgY291bGQg Z2V0IHRoZSBNVFUgbm9kZSB0byBoYXZlIHRoZSBzYW1lIG5hbWUgYW5kIHNlbWFudGljcyBmb3Ig YWxsIGludGVyZmFjZSB0eXBlcywgYnV0IGl0IHdvdWxkIGFsd2F5cyBoYXZlIGEgZGlmZmVyZW50 IG5hbWVzcGFjZSBmb3IgZWFjaCBpbnRlcmZhY2UgdHlwZS4gIEhlbmNlLCB0byB3cml0ZSBhIGNs aWVudCBmdW5jdGlvbiB0aGF0IGdlbmVyaWNhbGx5IGdldHMvc2V0cyB0aGUgTVRVIG9uIGFuIGlu dGVyZmFjZSB5b3UgbmVlZCB0byBrbm93IHRoZSBpbnRlcmZhY2UgdHlwZSB0byBiZSBhYmxlIHRv IG1hcCBpdCB0byB0aGUgYXBwcm9wcmlhdGUgbmFtZXNwYWNlIHRoYXQgdGhlIE1UVSBsZWFmIGhh cyBiZWVuIGRlZmluZWQgaW4uICBJIHRob3VnaHQgdGhhdCB0aGlzIHdvdWxkIGJlIGF3a3dhcmQg YW5kIGhlbmNlIGJldHRlciB0byBqdXN0IGRlZmluZSBpdCBpbiBhIHNpbmdsZSBwbGFjZS4NCg0K U28gaWYgYW4gYXBwcm9hY2ggbGlrZSBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmct MDAgaXMgYWdyZWVkIHRoZW4gSSB0aGluayB0aGF0IGl0IG1pZ2h0IHNvbWV3aGF0IGNoYW5nZSB0 aGUgc3RydWN0dXJlIG9mDQpkcmFmdC13d3otbmV0bW9kLXlhbmctdHVubmVsLWNmZy0wMCBpbiB0 aGUgZm9sbG93aW5nIHdheToNCg0KICAtIGlwLWFkZHJlc3Mgd291bGQgYmUgZGVmaW5lZCBieSB0 aGUgaXAtY2ZnIFlBTkcgbW9kdWxlLg0KDQpbUWluXTogVGhpcyBpcyB3aGF0IGRyYWZ0LXd3ei1u ZXRtb2QteWFuZy10dW5uZWwtY2ZnIHByb3Bvc2VkLCBJIGJlbGlldmUuDQoNCiAgLSBlbmNhcHN1 bGF0aW9uIG1ldGhvZCBjb3VsZCBwb3RlbnRpYWxseSBhdWdtZW50IGZyb20gdGhlIGVuY2Fwc3Vs YXRpb24gY2hvaWNlIG5vZGUgdGhhdCBoYXMgYmVlbiBkZWZpbmVkIGluDQpkcmFmdC13aWx0b24t bmV0bW9kLWludGYtZXh0LXlhbmctMDANCg0KW1Fpbl06IEkgdGhpbmsgZW5jYXBzdWxhdGlvbiBt ZXRob2QgaXMgb25lIHByb3BlcnR5IHRoYXQgaXMgY29tbW9uIHRvIGFsbCB0dW5uZWwgaW50ZXJm YWNlLCBpcyBlbmNhcHN1bGF0aW9uIG1ldGhvZCBjb21tb24gdG8gYm90aCBWTEFOIGludGVyZmFj ZSBhbmQgVHVubmVsIGludGVyZmFjZT8NCg0KICAtIE1UVSB3b3VsZCBiZSBkZWZpbmVkIGJ5IGwy LW10dSBpbiBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmctMDANCg0KW1Fpbl06IHdo YXQgYWJvdXQgSVAgTVRVLCBzdXBwb3NlIHR1bm5lbCBpbnRlcmZhY2UgaXMgZGVmaW5lZCBhcyBM YXllciAzIGludGVyZmFjZSwgSVAgTVRVIHNob3VsZCBiZSB1c2VkLg0KDQogIC0gUW9TIEkgd291 bGQgc3VnZ2VzdCB3b3VsZCBiZSBkZWZpbmVkIGJ5IERpZmZTZXJ2IG9yIG90aGVyIFFvUyBmZWF0 dXJlIGltcGxlbWVudGF0aW9uLg0KDQpbUWluXTogQWdyZWUgd2l0aCB5b3UuDQoNCkkuZS4gaW4g ZXNzZW5jZSBJIHdvdWxkIHRoaW5rIHRoYXQgcGVyaGFwcyBnZW4tdHVubmVsIHNob3VsZCBvbmx5 IGRlZmluZSBwcm9wZXJ0aWVzIHRoYXQgYXJlIHN0cmljdGx5IGNvbW1vbiB0byBhbGwgdHVubmVs IGludGVyZmFjZXMsIGJ1dCB0aGF0IGFyZSBub3QgbW9yZSB3aWRlbHkgY29tbW9uIGFjcm9zcyBh bGwvbW9zdCBpbnRlcmZhY2VzLg0KDQpbUWluXTogQWdyZWUsIEkgdGhpbmsgYXQgZmlyc3Qgd2Ug c2hvdWxkIHVuZGVyc3RhbmQgdGhlIGNsZWFyIHJlbGF0aW9uIGJldHdlZW4gc3ViaW50ZXJmYWNl LCBWTEFOIGludGVyZmFjZSBhbmQgVHVubmVsIGludGVyZmFjZSwgTG9vcGJhY2sgaW50ZXJmYWNl IGFuZCB0aGVuIHdlIGNhbiBkZWNpZGUgd2hhdCBraW5kIG9mIG1vZGVsIHN0cnVjdHVyZSBpcyBt b3JlIGZpdCBmb3IgdHVubmVsIGludGVyZmFjZS4NCg0KVGhhbmtzLA0KUm9iDQoNCg== From nobody Fri Jul 17 01:47:34 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 6437C1B31B2 for ; Fri, 17 Jul 2015 01:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zPuINekIrhNr for ; Fri, 17 Jul 2015 01:47:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268E01B31B0 for ; Fri, 17 Jul 2015 01:47:29 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 17 Jul 2015 08:47:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) with mapi id 15.01.0213.021; Fri, 17 Jul 2015 08:47:12 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] Agenda posted for IETF 93 meeting Thread-Index: AQHQwG0sspG/PexnTUKSzdxkngTaIA== Date: Fri, 17 Jul 2015 08:47:11 +0000 Message-ID: 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: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:2ZTrIIHFvqcAFHrLW72NV00gg7mxiG/7wgd5h10gApBlZp4pI5AEfgS8BBUgQMkdIAiKcC1NFPf70FOnZObH3e4CmirHkQ0Fd3G+OsldEAhCpOQXPhhGAKkTh8uoSBijphgshW6OCmvpqc00iiJOuw==; 24:GpFsbndWkDOX7GuD1aJh4gzPxNabXejtzMR1oZRvpqoNJ33DwTGFJne1opszbftXlyb70z7WPMIKk7LjVY2kvMtP3KdLqNDKB5yIOr2W3H4=; 20:Wz6gYyjkHkkAW0vTHWX63WUdz3BOspnOWGLgP+BycQJRktd0fD3I9ZaDJbJdxEMbU4NP8HD1wjDdywEPg2mgjA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; co1pr05mb459: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06400060E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(106116001)(19580405001)(19580395003)(83506001)(99286002)(86362001)(66066001)(2656002)(50986999)(87936001)(54356999)(189998001)(77156002)(36756003)(102836002)(5001960100002)(2351001)(107886002)(450100001)(19617315012)(46102003)(92566002)(40100003)(2900100001)(2501003)(4001350100001)(16236675004)(122556002)(5001920100001)(110136002)(15975445007)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1CE3462BFA85kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2015 08:47:11.8266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [netmod] Agenda posted for IETF 93 meeting 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: Fri, 17 Jul 2015 08:47:32 -0000 --_000_D1CE3462BFA85kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, the agenda has been updated as follows: 1. Pravin Gohite is now presenting draft-ietf-netmod-syslog-model-04 2. Added 5 minutes for draft-bogdanovic-netmod-yang-model-classification-= 03 3. Added 5 minutes for draft-wilton-netmod-intf-vlan-yang-00 4. Reordered Tuesday's presentations Presenters: - please send your slides to the chairs no later than the night before yo= ur presentation - Monday's schedule has no wiggle room, please adhere to your time alloca= tions! Thanks, Kent From: Kent Watsen > Date: Wednesday, July 15, 2015 at 4:05 PM To: "netmod@ietf.org" > Subject: [netmod] Agenda posted for IETF 93 meeting The preliminary agenda for the two NETMOD sessions has been posted here: https://www.ietf.org/proceedings/93/agenda/agenda-93-netmod Please note that a discussion regarding Open Config will not occur due to s= cheduling conflicts. Otherwise, please let us know if any adjustments are = needed. Thanks, Kent --_000_D1CE3462BFA85kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <59705CEE1890434783F957E56E785E6C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

All, the agenda has been updated as follo= ws:

  1. Pravin Gohite is now presenting=  draft-ietf-netmod-syslog-mod= el-04
  2. Added 5 minutes for draft-bogdanovic-netmod-yang-model-class= ification-03
  3. Added 5 minutes for &nbs= p;draft-wilton-netmod-intf-vlan-ya= ng-00
  4. Reordered Tuesday's p= resentations

Presenters: 
  - please send your slides to the chairs no later than the night befo= re your presentation
  - Monday's schedule has no wi= ggle room, please adhere to your time allocations!


Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, July 15, 2015 at 4= :05 PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] Agenda posted for= IETF 93 meeting


The preliminary agenda for the two NETMOD sessions has been posted her= e:


Please note that a discussion regarding Open Config will not occur due= to scheduling conflicts.  Otherwise, please let us know if any adjust= ments are needed.

Thanks,
Kent




 --_000_D1CE3462BFA85kwatsenjunipernet_-- From nobody Fri Jul 17 09:58:36 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 C8C191AC3ED; Fri, 17 Jul 2015 09:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 x9PTXib5Jhx6; Fri, 17 Jul 2015 09:58:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 30DA91AC3EE; Fri, 17 Jul 2015 09:58:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7C887180204; Fri, 17 Jul 2015 09:54:49 -0700 (PDT) To: rwilton@cisco.com, mbj@tail-f.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150717165449.7C887180204@rfc-editor.org> Date: Fri, 17 Jul 2015 09:54:49 -0700 (PDT) Archived-At: Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Errata Verified] RFC7223 (4405) 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: Fri, 17 Jul 2015 16:58:31 -0000 The following errata report has been verified for RFC7223, "A YANG Data Model for Interface Management". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7223&eid=4405 -------------------------------------- Status: Verified Type: Editorial Reported by: Rob Wilton Date Reported: 2015-06-29 Verified by: Benoit Claise (IESG) Section: 1.2. Original Text ------------- o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. Corrected Text -------------- o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes either a list or a leaf-list. Notes ----- Change "list and leaf-list" to "list or leaf-list" -------------------------------------- RFC7223 (draft-ietf-netmod-interfaces-cfg-16) -------------------------------------- Title : A YANG Data Model for Interface Management Publication Date : May 2014 Author(s) : M. Bjorklund Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Jul 17 14:35: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 48BAD1A886B for ; Fri, 17 Jul 2015 14:35:26 -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 5DhY6qECJ-H7 for ; Fri, 17 Jul 2015 14:35:24 -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 ACBBF1A21B1 for ; Fri, 17 Jul 2015 14:35:23 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id D547C70D029CE for ; Fri, 17 Jul 2015 21:35:17 +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 t6HLZI8Z020122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jul 2015 21:35:20 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 17 Jul 2015 17:35:18 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: ACL Model 03 - ACL Type should be mandatory Thread-Index: AQHQnK3+1WRBFqzUuEu69dSP2qQCIp3gdK+Q Date: Fri, 17 Jul 2015 21:35:18 +0000 Message-ID: References: In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [netmod] ACL Model 03 - ACL Type should be mandatory 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: Fri, 17 Jul 2015 21:35:26 -0000 SGkgYWxsLA0KDQpJIHRoaW5rIHdlIG5lZWQgdG8gcmV2aXNpdCB0aGlzIGRpc2N1c3Npb24gYWJv dXQgaG93IEFDTCB0eXBlIHdvcmtzIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wMy4N Cg0KSXQgc2hvdWxkIGJlIG1hbmRhdG9yeSBhbmQgd2Ugc2hvdWxkIHNlcGFyYXRlIHY0IGZyb20g djYuICBWZW5kb3JzIGNhbiBhdWdtZW50IGZvciBmdXR1cmUgIm1peGVkIiB0eXBlcyAob3IgbWF5 YmUgd2Ugc2hvdWxkIG1ha2UgYW4gaWYtZmVhdHVyZSBmb3IgYSAibWl4ZWQiIHR5cGUgbm93IHRo YXQgbWVhbnMgImFueXRoaW5nIGdvZXMiKS4NCg0KV2Ugc2hvdWxkIGZvbGxvdyBleGlzdGluZyBj b21tb24gaW1wbGVtZW50YXRpb25zIGZvciB0aGlzIGluIG9yZGVyIHRvIGZvc3RlciBiZXR0ZXIg YWRvcHRpb24uDQoNCkNpc2NvIElPUy1YUiBoYXMgc2VwYXJhdGUgbGlzdHMgZm9yIGlwdjQgYW5k IGlwdjYgYW5kIHBhcnQgb2Ygc3BlY2lmeWluZyB0aGUgbGlzdDoNCmlwdjQgYWNjZXNzLWxpc3Qg PG5hbWU+DQppcHY2IGFjY2Vzcy1saXN0IDxuYW1lPg0KIA0KSnVub3MgaGFzIHNlcGFyYXRlIGxp c3RzIGZvciB2NCBhbmQgdjY6DQphY2Nlc3MtbGlzdCA8eHl6PiAuLi4NCmlwdjYgYWNjZXNzLWxp c3QgPGFiYz4gLi4uDQogDQpBTFUgU1IgT1MgaGFzIHNlcGFyYXRlIGxpc3RzIGZvciB2NCwgdjYg YW5kIG1hYzoNCmNvbmZpZyBmaWx0ZXIgaXAtZmlsdGVyIDxhYmM+DQpjb25maWcgZmlsdGVyIGlw djYtZmlsdGVyIDxkZWY+DQpjb25maWcgZmlsdGVyIG1hYy1maWx0ZXIgPGdoaT4NCiANCkh1YXdl aSB1c2VzIHNlcGFyYXRlIGxpc3RzIGZvciB2NCBhbmQgdjY6DQphY2wgbnVtYmVyIDMwMDANCmFj bCBpcHY2IG51bWJlciAzMDAwDQoNClBsZWFzZSBzZWUgYmVsb3cgd2l0aCBbPj5KVFNdDQoNClJl Z2FyZHMsDQpKYXNvbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9k IFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJt YW4NClNlbnQ6IE1vbmRheSwgSnVuZSAwMSwgMjAxNSAxNzowMA0KVG86IE5hYmlsIE1pY2hyYWYN CkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBtYW5kYXRvcnkgQUNM IHR5cGUgKHdhcyAiY29tbWVudHMgb24gYWNsLW1vZGVsLTAyIikNCg0KSGksDQoNCg0KVGhhdCBh cHBlYXJzIHRvIGJlIHRoZSBjdXJyZW50IHZlcnNpb24gb24gdGhlIGRhdGEtdHJhY2tlci4NCkkg YWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgYWNjZXNzLWNvbnRyb2wtbGlzdC10eXBlIGxlYWYgc2hv dWxkIGJlIG1hbmRhdG9yeS4NCg0KSSBub3RpY2VkIHRoYXQgdGhlIGV4YW1wbGUgaW4gRmlndXJl IDIgaGFzIGFuIGV4dHJhICd0b3AnDQpjb250YWluZXIgYW5kIHRoZSBuYW1lc3BhY2UgZm9yICdh Y2Nlc3MtbGlzdHMnIGlzIG1pc3NpbmcuDQoNCg0KQW5keQ0KDQpPbiBNb24sIEp1biAxLCAyMDE1 IGF0IDExOjMxIEFNLCBOYWJpbCBNaWNocmFmIDxuYWJpbC5taWNocmFmQGdtYWlsLmNvbT4gd3Jv dGU6DQo+IEhpIGFsbCwNCj4NCj4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSBpZiB3ZSBhcmUgdGFs a2luZyBhYm91dCANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1uZXRtb2Qt YWNsLW1vZGVsLTAyLnR4dCBvciBzb21lIA0KPiBvdGhlciBkcmFmdD8NCj4gSSBqdXN0IHdhbnQg dG8gbWFrZSBzdXJlIEkgYW0gbG9va2luZyBhdCB0aGUgcmlnaHQgQUNMIG1vZGVsIHZlcnNpb24u DQo+DQo+IFRoYW5rIHlvdSwNCj4gTmFiaWwNCj4NCj4gT24gTW9uLCBKdW4gMSwgMjAxNSBhdCA3 OjA2IEFNLCBEYW5hIEJsYWlyIChkYmxhaXIpIDxkYmxhaXJAY2lzY28uY29tPg0KPiB3cm90ZToN Cj4+DQo+Pg0KPj4NCj4+IE9uIDQvMTMvMTUsIDEwOjExIEFNLCAiU3Rlcm5lLCBKYXNvbiAoSmFz b24pIg0KPj4gPGphc29uLnN0ZXJuZUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPj4NCj4+ ID5IaSBndXlzLA0KPj4gPg0KPj4gPkV4dHJhY3RpbmcgbXkgY29tbWVudHMgYWJvdXQgQUNMIHR5 cGUgaW50byBpdHMgb3duIHRocmVhZC4gIEkgc2F3IA0KPj4gPk1hcnRpbiBhbHNvIGhhZCBzb21l IGNvbW1lbnRzIG9uIHRoaXMgdG9waWMuDQo+PiA+DQo+PiA+VGhlIEFDTCB0eXBlIHdhcyBtYW5k YXRvcnkgaW4gYW4gb2xkZXIgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYW5kIEkgDQo+PiA+dGhpbmsg d2Ugc2hvdWxkIHB1dCBpdCBiYWNrIGFzIG1hbmRhdG9yeS4gIEltcGxlbWVudGF0aW9ucyB0aGF0 IA0KPj4gPmRvbid0ICpuZWVkKiB0aGF0IGxlYWYgdmFsdWUgY2FuIHdvcmsgZmluZSB3aGV0aGVy IHRoZXkgZ2V0IGl0IA0KPj4gPmR1cmluZyBBQ0wgY3JlYXRpb24gb3Igbm90IGJ1dCBzb21lIGlt cGxlbWVudGF0aW9ucyBuZWVkIHRvIGtub3cgdGhlIHR5cGUuDQo+Pg0KPj4gV2UgZG9uwrl0IHdh bnQgdG8gbWFrZSB0aGUgQUNMIHR5cGUgbWFuZGF0b3J5IGJlY2F1c2UgdGhlbiB3ZSBoYXZlIHRv IA0KPj4gYSBjcmVhdGUgYSBuZXcgdHlwZSBmb3IgZXZlcnkgY29tYmluYXRpb24gb2YgbWF0Y2gg Y3JpdGVyaWEuICBUaGUgDQo+PiBtb2RlbCBzaG91bGQgc3VwcG9ydCBhbnkgY29tYmluYXRpb24g b2YgbWF0Y2ggY3JpdGVyaWEgd2l0aCB0eXBpbmcgDQo+PiBvcHRpb25hbCB0byBtYXAgdG8gcHJl LWV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gIFRoaXMgaXMgYSB0cmFkZW9mZiANCj4+IGJldHdl ZW4gbWFraW5nIHRoZSBtb2RlbCBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgDQo+ PiBpbXBsZW1lbnRhdGlvbnMgYnV0IG1ha2UgaXQgZmxleGlibGUgZW5vdWdoIHNvIHRoYXQgYSBu ZXcgbWF0Y2ggDQo+PiBjcml0ZXJpYSBkb2VzbsK5dCByZXF1aXJlIGEgbmV3IHR5cGUuDQoNCls+ PkpUU10gV2UgY2FuIGp1c3QgY3JlYXRlIGEgIm1peGVkIiAoaS5lLiB1bnNwZWNpZmllZCkgdHlw ZSBhbmQgcHV0IGl0IHVuZGVyIGFuIGlmLWZlYXR1cmUuIEV4aXN0aW5nIGltcGxlbWVudGF0aW9u cyBoYXZlIGEgc2luZ2xlIHR5cGUgKGFuZCByZXF1aXJlIGtub3dpbmcgdGhlIHR5cGUgYXQgbGlz dCBjcmVhdGlvbiB0aW1lKS4NCg0KPj4NCj4+ID4NCj4+ID5JdCB3b3VsZCBhbHNvIGJlIGdvb2Qg dG8gY3JlYXRlIHNlcGFyYXRlIGlkZW50aXRpZXMgZm9yIA0KPj4gPklQdjQtYWNjZXNzLWNvbnRy b2wtbGlzdCBhbmQgSVB2Ni1hY2Nlc3MtY29udHJvbC1saXN0IGluc3RlYWQgb2YgDQo+PiA+YnVu ZGxpbmcgdGhlbSBpbnRvIElQLWFjY2Vzcy1jb250cm9sLWxpc3QuIElmIHdlJ3JlIHNlcGFyYXRp bmcgaW50byANCj4+ID50eXBlcyBpbiB0aGUgbW9kZWwgaXQgc2hvdWxkIGJlIHRoZSAzIGJhc2lj IHR5cGVzIGluIHRoZSBiYXNlIG1vZGVsOiAgdjQsIHY2IGFuZCBlbmV0Lg0KPj4NCj4+IEEgdmVu ZG9yIHNwZWNpZmljIGF1Z21lbnRhdGlvbi9pbXBsZW1lbnRhdGlvbiBjb3VsZCBkbyB0aGlzLCBi dXQgdGhlIA0KPj4gbW9kZWwgbmVlZHMgdG8gc3VwcG9ydCBpbmNsdXNpb24gb2YgaXB2NCBhbmQg aXB2NiBpbiB0aGUgc2FtZSBhY2wuICANCj4+IEnCuW0gYXdhcmUgb2Ygb3V0c3RhbmRpbmcgY3Vz dG9tZXJzIHJlcXVlc3RzIGZvciBjb21iaW5pbmcgaXB2NCBydWxlcyANCj4+IGFuZCBpcHY2IHJ1 bGVzIGluIHRoZSBzYW1lIGFjbCwgYnV0IG1vc3QgaW1wbGVtZW50YXRpb25zIGhhdmUgbm90IA0K Pj4gY2F1Z2h0IHVwIHRvIHRoaXMuICBXaGVuIGl0IGNvbWVzIHRvIG1hbmFnaW5nIGFjbHMgdGhl cmUgc2hvdWxkbsK5dCBiZSANCj4+IHRoaXMgZGlzdGluY3Rpb24gYmV0d2VlbiBJUHY2IGFuZCBJ UHY0LiAgVGhleSBhcmUgYm90aCBJUCBhZGRyZXNzZXMuDQoNCg0KWz4+SlRTXSBBZ2FpbiAtIGxl dCdzIGZvY3VzIG9uIGNhcHR1cmluZyBjb21tb24gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGlu IHRoZXNlIHN0YW5kYXJkIG1vZGVscyAod2hpbGUgYWxzbyBhbGxvd2luZyBmb3IgYXVnbWVudGF0 aW9uIGFuZCBmbGV4aWJpbGl0eSkuICBWNCBhbmQgVjYgYXJlIGluIHNlcGFyYXRlIGxpc3RzIHRv ZGF5LiAgQSBmdXR1cmUgbWl4ZWQgbGlzdCBjYW4gdXNlIHRoZSAibWl4ZWQiIHR5cGUgb3IgaW52 ZW50IGEgbmV3ICJ2NCt2NiIgdHlwZS4NCg0KPj4NCj4+ID4NCj4+ID5UaGF0IHdvdWxkIGFsc28g aGVscCBpZiB3ZSBkZWNpZGUgdG8gcHV0IHNvbWUgY29uc3RyYWludHMgdGhhdCANCj4+ID5hbGxv dy9kaXNhbGxvdyBjZXJ0YWluIG1hdGNoaW5nIGNyaXRlcmlhIHdoZW4gdGhlIHR5cGUgaXMgYSBz cGVjaWZpYyANCj4+ID52YWx1ZSAoZS5nLiBkb24ndCBhbGxvdyBhIHY2IGFkZHJlc3MgbWF0Y2gg aW4gYSB2NCBsaXN0KS4NCj4+ID4gIFdlJ2QgaGF2ZSB0byBiZSBjYXJlZnVsIGFib3V0IGhvdyB0 aG9zZSBjb25zdHJhaW50cyBhcmUgZm9ybXVsYXRlZCANCj4+ID50aG91Z2ggLSBlc3BlY2lhbGx5 IGlmIHdlIHdhbnQgdG8gYWxsb3cgYXVnbWVudGF0aW9ucyBvZiB0aGUgDQo+PiA+bGlzdC10eXBl IGZvciAibWl4ZWQiIEFDTHMuIEEgbmV3ICJtaXhlZC12NC1lbmV0IiB0eXBlIChpZGVudGl0eSkg DQo+PiA+d291bGQgYWxzbyBuZWVkIHRvIHVzZSB0aGUgZGVzdGluYXRpb24taXB2NC1uZXR3b3Jr IG1hdGNoaW5nIA0KPj4gPmNyaXRlcmlhIChjYW4gIndoZW4iIG9yICJtdXN0IiBsb2dpYyBiZSBj aGFuZ2VkIGJ5IGFuIGF1Z21lbnRhdGlvbiA/ICBJJ20gbm90IHN1cmUgdGhhdCB3b3JrcykuDQo+ Pg0KPj4gWWVzLCB3b3VsZCBoYXZlIHRvIGJlIGNhcmVmdWwsIGFuZCBkZWZpbmluZyBjb25zdHJh aW50cyBiYXNlZCBvbiBleGlzdGluZw0KPj4gaW1wbGVtZW50YXRpb25zIGNvdWxkIGJlIGEgdmVy eSBzbGlwcGVyeSBzbG9wZS4gICBWZW5kb3JzIHNob3VsZCBiZSBhYmxlDQo+PiB0byBtYXAgdG8g dGhlaXIgaW1wbGVtZW50YXRpb25zIGFuZC9vciBoYXZlIGEgcHJvcHJpZXRhcnkgDQo+PiBhdWdt ZW50YXRpb24gdGhhdCBjb25zdHJhaW5zIHRoaW5ncyBtb3JlIGFjY29yZGluZyB0bw0KPj4gdGhl aXIgaW1wbGVtZW50YXRpb24uICAgUHJvcHJpZXRhcnkgYXVnbWVudGF0aW9ucyBjb3VsZCBiZSBw cm9wb3NlZCwgYW5kDQo+PiByZXZpZXdlZCBmb3Igc3RhbmRhcmRpemF0aW9uLg0KDQoNCls+PkpU U10gVGhlIGRyYWZ0IGRvZXNuJ3QgaGF2ZSBhbnkgY29uc3RyYWludHMgYmFzZWQgb24gdHlwZSBz byBJIHN1cHBvc2UgdGhpcyBwb2ludCBpcyBtb290Lg0KDQo+Pg0KPj4gdGhhbmtzLA0KPj4gRGFu YQ0KPj4NCj4+ID4NCj4+ID5SZWdhcmRzLA0KPj4gPkphc29uDQo+PiA+DQo+PiA+DQo+PiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5uZXRtb2Qg bWFpbGluZyBsaXN0DQo+PiA+bmV0bW9kQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0 bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlz dA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0K From nobody Sun Jul 19 08:11:37 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 6F7741AD378 for ; Sun, 19 Jul 2015 08:11:36 -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 NTaqVH65k0VV for ; Sun, 19 Jul 2015 08:11:34 -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 91CA41AD373 for ; Sun, 19 Jul 2015 08:11:34 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 6195CED4FBF0B; Sun, 19 Jul 2015 15:11:30 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t6JFBUBE018373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Jul 2015 15:11:31 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 19 Jul 2015 11:11:30 -0400 From: "Sterne, Jason (Jason)" To: Andy Bierman , "Acee Lindem (acee)" , "netmod@ietf.org" Thread-Topic: [netmod] Access Control List Ordering Thread-Index: AQHQZnVoj2WSOQuQ4UyjZc+5fKmQnJ0sZZkAgAABYID//73dQIAATJwAgLco75A= Date: Sun, 19 Jul 2015 15:11:30 +0000 Message-ID: References: <20150324205924.GA61096@elstar.local> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Access Control List Ordering 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: Sun, 19 Jul 2015 15:11:36 -0000 SGkgYWxsLA0KDQpBbm90aGVyIHRvcGljIHRoYXQgSSBzdGlsbCB0aGluayB3YXJyYW50cyBtb3Jl IGRpc2N1c3Npb24gaXMgdGhlIHVzZSBvZiBleHBsaWNpdCBlbnRyeSBudW1iZXJzIGZvciBBQ0Vz IGluc3RlYWQgb2YgYXJiaXRyYXJ5IHN0cmluZyBuYW1lcy4gICBOYW1lcyBhcmUgZ3JlYXQgZm9y IG9iamVjdHMgbGlrZSBBQ0xzLCBpbnRlcmZhY2VzLCBldGMgYnV0IHdlIHNob3VsZCByZWFsbHkg Y29uc2lkZXIgdXNpbmcgZXhwbGljaXQgb3JkZXIgYmFzZWQgb24gYSBudW1lcmljYWwga2V5IGZv ciBBQ0VzLg0KDQpBQ0VzIGNhbiBoYXZlIGEgdGV4dCAnZGVzY3JpcHRpb24nIGxlYWYgdG8gZXhw bGFpbiB0aGVpciBwdXJwb3NlIChpbnN0ZWFkIG9mIHRyeWluZyB0byBvdmVybG9hZCB0aGF0IGlu dG8gYSBsaW1pdGVkIG5hbWUpLg0KDQpTb21lIG1heSBmZWVsIHRoYXQgbnVtYmVyZWQgSURzIGFy ZSAiYXJjaGFpYyIuICBJIGFncmVlIGZvciBsaXN0cyB3aGVyZSBlbnRyaWVzIGRvbid0IHJlYWxs eSBoYXZlIGFueSBvcmRlciByZWxhdGl2ZSB0byBlYWNoIG90aGVyIGJ1dCBqdXN0IGJlY2F1c2Ug bnVtZXJpY2FsIEFDRXMgaGF2ZSBiZWVuIGFyb3VuZCBmb3IgYSBsb25nIHRpbWUgZG9lc24ndCBt ZWFuIHRoZXkgYXJlIGEgYmFkIGlkZWEuIA0KDQpXaHkgYSBudW1lcmljYWwgSUQgPw0KLSBhcyBw ZXIgdGhlIGJyaWVmIGV4Y2hhbmdlIGJldHdlZW4gQW5keSAmIEkgYmVsb3c6ICBleHBsaWNpdCBu dW1lcmljYWwgZW50cnkgIyB3aWxsIHBsYXkgbmljZXIgd2l0aCBTTk1QIGFuZCBvdGhlciBub24t TkVUQ09ORi9ZQU5HIG1ldGhvZHMgdG8gYWNjZXNzIHRoZSBkYXRhDQotIG51bWJlcmVkIEFDRXMg YXJlIGp1c3QgZWFzaWVyIGZvciBwZW9wbGUgdG8gcmVhZCAmIG1hbmlwdWxhdGUuICBZb3UgY2Fu IGVhc2lseSByZWZlciB0byBhbiBBQ0UgYW5kIHNvbWVvbmUgZWxzZSBjYW4gZmluZCBpdCBpbiB0 aGUgbGlzdCBxdWlja2x5LiAgDQotIHRoZXJlIGFyZSBtYW55IGltcGxlbWVudGF0aW9ucyBvdXQg dGhlcmUgdGhhdCB1c2UgbnVtZXJpY2FsIEFDRSBJRHMgYW5kIG9wZXJhdG9ycyBhcmUgdXNlZCB0 byBtYW5hZ2luZyB0aGVtIHRoYXQgd2F5DQotIEl0IGlzIGVhc2llciB0byBjcmVhdGUgYmxvY2tz IG9mIElEcyBmb3IgZGlmZmVyZW50IHNlY3Rpb25zIG9mIHRoZSBBQ0wgYW5kIHRvIHVuZGVyc3Rh bmQgd2hlcmUgdGhvc2UgYmxvY2tzIGxpdmUgaW4gdGhlIEFDTCByZWxhdGl2ZSB0byBlYWNob3Ro ZXIgKGUuZy4gZW50cmllcyBpbnNlcnRlZCBieSBGbG93U3BlYyBnbyBoZXJlLCBlbnRyaWVzIGlu c2VydGVkIGJ5IFJBRElVUyBnbyBoZXJlKS4NCi0gSGlnaCBzcGVlZCBkYXRhIHBhdGhzIHVzZSBU Q0FNcyBmb3IgQUNMcyBhbmQgaW4gdGhlIGVuZCB0aG9zZSB1c2UgbnVtZXJpY2FsIElEcyBmb3Ig b3JkZXJpbmcvcHJlY2VkZW5jZS4gIFJlZmxlY3RpbmcgdGhhdCB1cCB0b3dhcmRzIHRoZSBkZXZp Y2UgY29uZmlnIGxheWVyIGFsbG93cyBvcHRpbWl6YXRpb25zIHRvIGF2b2lkL3JlZHVjZSByZW9y ZGVyaW5nIGluIHRoZSBkZXZpY2UuDQoNClJlZ2FyZHMsDQpKYXNvbg0KDQpPbiBUdWUsIE1hciAy NCwgMjAxNSBhdCA0OjUwIFBNLCBTdGVybmUsIEphc29uIChKYXNvbikgPGphc29uLnN0ZXJuZUBh bGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPiBIaSBndXlzLA0KPg0KLi4uc25pcC4uLg0KPg0K PiBNYXliZSBpdCBpc27igJl0IGEgcHJpb3JpdHkgZm9yIHNvbWUgc3lzdGVtcyBidXQgSSBhbHNv IHdvbmRlciBob3cgU05NUCB3b3VsZCByZXByZXNlbnQgb3JkZXJlZCBhY2wtZW50cmllcyBpZiB0 aGVyZSBpc24ndCBhIHNlcXVlbmNlIG51bWJlciB0aGF0IGNhbiBiZSB1c2VkIGFzIChhdCBsZWFz dCBwYXJ0IG9mKSB0aGUga2V5Lg0KPg0KDQpVc2VyLW9yZGVyZWQgbGlzdHMgYXJlIFlBTkctc3Bl Y2lmaWMuDQpJIGFkdmljZSBhZ2FpbnN0IHVzaW5nIHRoZW0gaWYgeW91IHdhbnQgbXVsdGlwbGUg cHJvdG9jb2xzIGxpa2UgU05NUCBhbmQgQ0xJIHRvIHdvcmsgd2l0aCB0aGUgZGF0YS4NCg0KDQo+ IFJlZ2FyZHMsDQo+IEphc29uDQo+DQoNCg0K From nobody Sun Jul 19 09:58:37 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 6A15E1B2A13 for ; Sun, 19 Jul 2015 09:58:36 -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 ad2T34hH5L2x for ; Sun, 19 Jul 2015 09:58: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 BF39D1B2A11 for ; Sun, 19 Jul 2015 09:58:33 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id EECD79B570AB6 for ; Sun, 19 Jul 2015 16:58:27 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t6JGwULL020958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 19 Jul 2015 16:58:30 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sun, 19 Jul 2015 12:58:30 -0400 From: "Sterne, Jason (Jason)" To: "Sterne, Jason (Jason)" , "netmod@ietf.org" Thread-Topic: ACL Model 03 - ACL Type should be mandatory Thread-Index: AQHQnK3+1WRBFqzUuEu69dSP2qQCIp3gdK+QgAK8bbA= Date: Sun, 19 Jul 2015 16:58:29 +0000 Message-ID: References: In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory 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: Sun, 19 Jul 2015 16:58:36 -0000 R2l2ZW4gdGhlIGRhdGEgbW9kZWxzIGJlbG93IGluIHNvbWUgb2YgdGhlIG1ham9yIGltcGxlbWVu dGF0aW9ucyBpdCBhbHNvIHNlZW1zIGxpa2Ugd2Ugc2hvdWxkIGFsc28gKHJlLSljb25zaWRlciBo YXZpbmcgdGhlICd0eXBlJyBhcyBwYXJ0IG9mIHRoZSBBQ0wga2V5ICgidHlwZSBuYW1lIikuICAN Cg0KSW4gYWxsIHRob3NlIGNhc2VzIGJlbG93IGl0IGxvb2tzIGxpa2UgYW4gb3BlcmF0b3IgY2Fu IGN1cnJlbnRseSBjb25maWd1cmUgdHdvIGRpZmZlcmVudCBBQ0xzIChlLmcuIGFuIElQdjQgYW5k IGFuIElQdjYgQUNMKSB3aXRoIHRoZSBzYW1lIG5hbWUvaWQgdmlhIHRoZWlyIENMSSAoZS5nLiBh IHY0IEFDTCBjYWxsZWQgIm15LWFjbCIgYW5kIGEgdjYgQUNMIGNhbGxlZCAibXktYWNsIikuICAN Cg0KSG93IHdvdWxkIHRob3NlIGxpc3RzIGJlIHJlYWQgaW4gYSA8Z2V0LWNvbmZpZz4gdmlhIHRo ZSBpZXRmIEFDTCBZQU5HIG1vZHVsZXMgPyAgV2UnZCBhbGwgaGF2ZSB0byBtYW5nbGUgdGhlIG5h bWVzIGFuZCByZXNlcnZlIHNwZWNpYWwgbmFtZXMvcHJlZml4LWNoYXJzIChlLmcuIF9pcHY0LW15 LWFjbCBhbmQgX2lwdjYtbXktYWNsKSB0byBzZW5kIHRoZW0gYmFjayB0byBhIE5DIGNsaWVudC4g IEknbSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBtdWNoIG9mIGEgZGlzYWR2YW50YWdlIG9mIGp1c3Qg aGF2aW5nIHR5cGUgaW4gdGhlIGtleSAoYXNzdW1pbmcgaXQgaXMgbWFuZGF0b3J5IGFzIGFkdm9j YXRlZCBiZWxvdykuDQoNCkkgYWxzbyBsb29rZWQgYnJpZWZseSBhdCB0aGUgQnJvY2FkZSBZQU5H IG1vZGVscyBvbiBnaXRodWIuICBJdCBsb29rcyBsaWtlIHRoZXkgaGF2ZSBtdWx0aXBsZSBsaXN0 cyBhcyB3ZWxsIGZvciB2NCB2cyB2NiAoYW5kIGV2ZW4gb3IgZGlmZmVyZW50IHR5cGVzIG9mIG5v cm1hbCB2cyBleHRlbmRlZCBBQ0xzIC0gdGhhdCBjb3VsZCBiZSBoYW5kbGVkIGJ5IGF1Z21lbnRp bmcgdGhlIHR5cGUgd2l0aCBhICd2NC1leHRlbmRlZCcgdHlwZSBmb3IgZXhhbXBsZSkuDQoNClJl Z2FyZHMsDQpKYXNvbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9k IFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVybmUsIEph c29uIChKYXNvbikNClNlbnQ6IEZyaWRheSwgSnVseSAxNywgMjAxNSAyMzozNQ0KVG86IG5ldG1v ZEBpZXRmLm9yZw0KU3ViamVjdDogW25ldG1vZF0gQUNMIE1vZGVsIDAzIC0gQUNMIFR5cGUgc2hv dWxkIGJlIG1hbmRhdG9yeQ0KDQpIaSBhbGwsDQoNCkkgdGhpbmsgd2UgbmVlZCB0byByZXZpc2l0 IHRoaXMgZGlzY3Vzc2lvbiBhYm91dCBob3cgQUNMIHR5cGUgd29ya3MgaW4gZHJhZnQtaWV0Zi1u ZXRtb2QtYWNsLW1vZGVsLTAzLg0KDQpJdCBzaG91bGQgYmUgbWFuZGF0b3J5IGFuZCB3ZSBzaG91 bGQgc2VwYXJhdGUgdjQgZnJvbSB2Ni4gIFZlbmRvcnMgY2FuIGF1Z21lbnQgZm9yIGZ1dHVyZSAi bWl4ZWQiIHR5cGVzIChvciBtYXliZSB3ZSBzaG91bGQgbWFrZSBhbiBpZi1mZWF0dXJlIGZvciBh ICJtaXhlZCIgdHlwZSBub3cgdGhhdCBtZWFucyAiYW55dGhpbmcgZ29lcyIpLg0KDQpXZSBzaG91 bGQgZm9sbG93IGV4aXN0aW5nIGNvbW1vbiBpbXBsZW1lbnRhdGlvbnMgZm9yIHRoaXMgaW4gb3Jk ZXIgdG8gZm9zdGVyIGJldHRlciBhZG9wdGlvbi4NCg0KQ2lzY28gSU9TLVhSIGhhcyBzZXBhcmF0 ZSBsaXN0cyBmb3IgaXB2NCBhbmQgaXB2NiBhbmQgcGFydCBvZiBzcGVjaWZ5aW5nIHRoZSBsaXN0 Og0KaXB2NCBhY2Nlc3MtbGlzdCA8bmFtZT4NCmlwdjYgYWNjZXNzLWxpc3QgPG5hbWU+DQogDQpK dW5vcyBoYXMgc2VwYXJhdGUgbGlzdHMgZm9yIHY0IGFuZCB2NjoNCmFjY2Vzcy1saXN0IDx4eXo+ IC4uLg0KaXB2NiBhY2Nlc3MtbGlzdCA8YWJjPiAuLi4NCiANCkFMVSBTUiBPUyBoYXMgc2VwYXJh dGUgbGlzdHMgZm9yIHY0LCB2NiBhbmQgbWFjOg0KY29uZmlnIGZpbHRlciBpcC1maWx0ZXIgPGFi Yz4NCmNvbmZpZyBmaWx0ZXIgaXB2Ni1maWx0ZXIgPGRlZj4NCmNvbmZpZyBmaWx0ZXIgbWFjLWZp bHRlciA8Z2hpPg0KIA0KSHVhd2VpIHVzZXMgc2VwYXJhdGUgbGlzdHMgZm9yIHY0IGFuZCB2NjoN CmFjbCBudW1iZXIgMzAwMA0KYWNsIGlwdjYgbnVtYmVyIDMwMDANCg0KUGxlYXNlIHNlZSBiZWxv dyB3aXRoIFs+PkpUU10NCg0KUmVnYXJkcywNCkphc29uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogTW9uZGF5LCBKdW5lIDAxLCAyMDE1IDE3OjAw DQpUbzogTmFiaWwgTWljaHJhZg0KQ2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtu ZXRtb2RdIG1hbmRhdG9yeSBBQ0wgdHlwZSAod2FzICJjb21tZW50cyBvbiBhY2wtbW9kZWwtMDIi KQ0KDQpIaSwNCg0KDQpUaGF0IGFwcGVhcnMgdG8gYmUgdGhlIGN1cnJlbnQgdmVyc2lvbiBvbiB0 aGUgZGF0YS10cmFja2VyLg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBhY2Nlc3MtY29udHJv bC1saXN0LXR5cGUgbGVhZiBzaG91bGQgYmUgbWFuZGF0b3J5Lg0KDQpJIG5vdGljZWQgdGhhdCB0 aGUgZXhhbXBsZSBpbiBGaWd1cmUgMiBoYXMgYW4gZXh0cmEgJ3RvcCcNCmNvbnRhaW5lciBhbmQg dGhlIG5hbWVzcGFjZSBmb3IgJ2FjY2Vzcy1saXN0cycgaXMgbWlzc2luZy4NCg0KDQpBbmR5DQoN Ck9uIE1vbiwgSnVuIDEsIDIwMTUgYXQgMTE6MzEgQU0sIE5hYmlsIE1pY2hyYWYgPG5hYmlsLm1p Y2hyYWZAZ21haWwuY29tPiB3cm90ZToNCj4gSGkgYWxsLA0KPg0KPiBDYW4geW91IHBsZWFzZSBj bGFyaWZ5IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDIudHh0IG9yIHNvbWUgDQo+IG90aGVyIGRy YWZ0Pw0KPiBJIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUgSSBhbSBsb29raW5nIGF0IHRoZSByaWdo dCBBQ0wgbW9kZWwgdmVyc2lvbi4NCj4NCj4gVGhhbmsgeW91LA0KPiBOYWJpbA0KPg0KPiBPbiBN b24sIEp1biAxLCAyMDE1IGF0IDc6MDYgQU0sIERhbmEgQmxhaXIgKGRibGFpcikgPGRibGFpckBj aXNjby5jb20+DQo+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gT24gNC8xMy8xNSwgMTA6MTEgQU0s ICJTdGVybmUsIEphc29uIChKYXNvbikiDQo+PiA8amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50 LmNvbT4gd3JvdGU6DQo+Pg0KPj4gPkhpIGd1eXMsDQo+PiA+DQo+PiA+RXh0cmFjdGluZyBteSBj b21tZW50cyBhYm91dCBBQ0wgdHlwZSBpbnRvIGl0cyBvd24gdGhyZWFkLiAgSSBzYXcgDQo+PiA+ TWFydGluIGFsc28gaGFkIHNvbWUgY29tbWVudHMgb24gdGhpcyB0b3BpYy4NCj4+ID4NCj4+ID5U aGUgQUNMIHR5cGUgd2FzIG1hbmRhdG9yeSBpbiBhbiBvbGRlciB2ZXJzaW9uIG9mIHRoZSBkcmFm dCBhbmQgSSANCj4+ID50aGluayB3ZSBzaG91bGQgcHV0IGl0IGJhY2sgYXMgbWFuZGF0b3J5LiAg SW1wbGVtZW50YXRpb25zIHRoYXQgDQo+PiA+ZG9uJ3QgKm5lZWQqIHRoYXQgbGVhZiB2YWx1ZSBj YW4gd29yayBmaW5lIHdoZXRoZXIgdGhleSBnZXQgaXQgDQo+PiA+ZHVyaW5nIEFDTCBjcmVhdGlv biBvciBub3QgYnV0IHNvbWUgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8ga25vdyB0aGUgdHlwZS4N Cj4+DQo+PiBXZSBkb27CuXQgd2FudCB0byBtYWtlIHRoZSBBQ0wgdHlwZSBtYW5kYXRvcnkgYmVj YXVzZSB0aGVuIHdlIGhhdmUgdG8gDQo+PiBhIGNyZWF0ZSBhIG5ldyB0eXBlIGZvciBldmVyeSBj b21iaW5hdGlvbiBvZiBtYXRjaCBjcml0ZXJpYS4gIFRoZSANCj4+IG1vZGVsIHNob3VsZCBzdXBw b3J0IGFueSBjb21iaW5hdGlvbiBvZiBtYXRjaCBjcml0ZXJpYSB3aXRoIHR5cGluZyANCj4+IG9w dGlvbmFsIHRvIG1hcCB0byBwcmUtZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBpcyBh IHRyYWRlb2ZmIA0KPj4gYmV0d2VlbiBtYWtpbmcgdGhlIG1vZGVsIGJhY2t3YXJkIGNvbXBhdGli bGUgd2l0aCBleGlzdGluZyANCj4+IGltcGxlbWVudGF0aW9ucyBidXQgbWFrZSBpdCBmbGV4aWJs ZSBlbm91Z2ggc28gdGhhdCBhIG5ldyBtYXRjaCANCj4+IGNyaXRlcmlhIGRvZXNuwrl0IHJlcXVp cmUgYSBuZXcgdHlwZS4NCg0KWz4+SlRTXSBXZSBjYW4ganVzdCBjcmVhdGUgYSAibWl4ZWQiIChp LmUuIHVuc3BlY2lmaWVkKSB0eXBlIGFuZCBwdXQgaXQgdW5kZXIgYW4gaWYtZmVhdHVyZS4gRXhp c3RpbmcgaW1wbGVtZW50YXRpb25zIGhhdmUgYSBzaW5nbGUgdHlwZSAoYW5kIHJlcXVpcmUga25v d2luZyB0aGUgdHlwZSBhdCBsaXN0IGNyZWF0aW9uIHRpbWUpLg0KDQo+Pg0KPj4gPg0KPj4gPkl0 IHdvdWxkIGFsc28gYmUgZ29vZCB0byBjcmVhdGUgc2VwYXJhdGUgaWRlbnRpdGllcyBmb3IgDQo+ PiA+SVB2NC1hY2Nlc3MtY29udHJvbC1saXN0IGFuZCBJUHY2LWFjY2Vzcy1jb250cm9sLWxpc3Qg aW5zdGVhZCBvZiANCj4+ID5idW5kbGluZyB0aGVtIGludG8gSVAtYWNjZXNzLWNvbnRyb2wtbGlz dC4gSWYgd2UncmUgc2VwYXJhdGluZyBpbnRvIA0KPj4gPnR5cGVzIGluIHRoZSBtb2RlbCBpdCBz aG91bGQgYmUgdGhlIDMgYmFzaWMgdHlwZXMgaW4gdGhlIGJhc2UgbW9kZWw6ICB2NCwgdjYgYW5k IGVuZXQuDQo+Pg0KPj4gQSB2ZW5kb3Igc3BlY2lmaWMgYXVnbWVudGF0aW9uL2ltcGxlbWVudGF0 aW9uIGNvdWxkIGRvIHRoaXMsIGJ1dCB0aGUgDQo+PiBtb2RlbCBuZWVkcyB0byBzdXBwb3J0IGlu Y2x1c2lvbiBvZiBpcHY0IGFuZCBpcHY2IGluIHRoZSBzYW1lIGFjbC4NCj4+IEnCuW0gYXdhcmUg b2Ygb3V0c3RhbmRpbmcgY3VzdG9tZXJzIHJlcXVlc3RzIGZvciBjb21iaW5pbmcgaXB2NCBydWxl cyANCj4+IGFuZCBpcHY2IHJ1bGVzIGluIHRoZSBzYW1lIGFjbCwgYnV0IG1vc3QgaW1wbGVtZW50 YXRpb25zIGhhdmUgbm90IA0KPj4gY2F1Z2h0IHVwIHRvIHRoaXMuICBXaGVuIGl0IGNvbWVzIHRv IG1hbmFnaW5nIGFjbHMgdGhlcmUgc2hvdWxkbsK5dCBiZSANCj4+IHRoaXMgZGlzdGluY3Rpb24g YmV0d2VlbiBJUHY2IGFuZCBJUHY0LiAgVGhleSBhcmUgYm90aCBJUCBhZGRyZXNzZXMuDQoNCg0K Wz4+SlRTXSBBZ2FpbiAtIGxldCdzIGZvY3VzIG9uIGNhcHR1cmluZyBjb21tb24gZXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zIGluIHRoZXNlIHN0YW5kYXJkIG1vZGVscyAod2hpbGUgYWxzbyBhbGxv d2luZyBmb3IgYXVnbWVudGF0aW9uIGFuZCBmbGV4aWJpbGl0eSkuICBWNCBhbmQgVjYgYXJlIGlu IHNlcGFyYXRlIGxpc3RzIHRvZGF5LiAgQSBmdXR1cmUgbWl4ZWQgbGlzdCBjYW4gdXNlIHRoZSAi bWl4ZWQiIHR5cGUgb3IgaW52ZW50IGEgbmV3ICJ2NCt2NiIgdHlwZS4NCg0KPj4NCj4+ID4NCj4+ ID5UaGF0IHdvdWxkIGFsc28gaGVscCBpZiB3ZSBkZWNpZGUgdG8gcHV0IHNvbWUgY29uc3RyYWlu dHMgdGhhdCANCj4+ID5hbGxvdy9kaXNhbGxvdyBjZXJ0YWluIG1hdGNoaW5nIGNyaXRlcmlhIHdo ZW4gdGhlIHR5cGUgaXMgYSBzcGVjaWZpYyANCj4+ID52YWx1ZSAoZS5nLiBkb24ndCBhbGxvdyBh IHY2IGFkZHJlc3MgbWF0Y2ggaW4gYSB2NCBsaXN0KS4NCj4+ID4gIFdlJ2QgaGF2ZSB0byBiZSBj YXJlZnVsIGFib3V0IGhvdyB0aG9zZSBjb25zdHJhaW50cyBhcmUgZm9ybXVsYXRlZCANCj4+ID50 aG91Z2ggLSBlc3BlY2lhbGx5IGlmIHdlIHdhbnQgdG8gYWxsb3cgYXVnbWVudGF0aW9ucyBvZiB0 aGUgDQo+PiA+bGlzdC10eXBlIGZvciAibWl4ZWQiIEFDTHMuIEEgbmV3ICJtaXhlZC12NC1lbmV0 IiB0eXBlIChpZGVudGl0eSkgDQo+PiA+d291bGQgYWxzbyBuZWVkIHRvIHVzZSB0aGUgZGVzdGlu YXRpb24taXB2NC1uZXR3b3JrIG1hdGNoaW5nIA0KPj4gPmNyaXRlcmlhIChjYW4gIndoZW4iIG9y ICJtdXN0IiBsb2dpYyBiZSBjaGFuZ2VkIGJ5IGFuIGF1Z21lbnRhdGlvbiA/ICBJJ20gbm90IHN1 cmUgdGhhdCB3b3JrcykuDQo+Pg0KPj4gWWVzLCB3b3VsZCBoYXZlIHRvIGJlIGNhcmVmdWwsIGFu ZCBkZWZpbmluZyBjb25zdHJhaW50cyBiYXNlZCBvbiBleGlzdGluZw0KPj4gaW1wbGVtZW50YXRp b25zIGNvdWxkIGJlIGEgdmVyeSBzbGlwcGVyeSBzbG9wZS4gICBWZW5kb3JzIHNob3VsZCBiZSBh YmxlDQo+PiB0byBtYXAgdG8gdGhlaXIgaW1wbGVtZW50YXRpb25zIGFuZC9vciBoYXZlIGEgcHJv cHJpZXRhcnkgDQo+PiBhdWdtZW50YXRpb24gdGhhdCBjb25zdHJhaW5zIHRoaW5ncyBtb3JlIGFj Y29yZGluZyB0bw0KPj4gdGhlaXIgaW1wbGVtZW50YXRpb24uICAgUHJvcHJpZXRhcnkgYXVnbWVu dGF0aW9ucyBjb3VsZCBiZSBwcm9wb3NlZCwgYW5kDQo+PiByZXZpZXdlZCBmb3Igc3RhbmRhcmRp emF0aW9uLg0KDQoNCls+PkpUU10gVGhlIGRyYWZ0IGRvZXNuJ3QgaGF2ZSBhbnkgY29uc3RyYWlu dHMgYmFzZWQgb24gdHlwZSBzbyBJIHN1cHBvc2UgdGhpcyBwb2ludCBpcyBtb290Lg0KDQo+Pg0K Pj4gdGhhbmtzLA0KPj4gRGFuYQ0KPj4NCj4+ID4NCj4+ID5SZWdhcmRzLA0KPj4gPkphc29uDQo+ PiA+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID5uZXRtb2QgbWFpbGluZyBsaXN0DQo+PiA+bmV0bW9kQGlldGYub3JnDQo+PiA+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1v ZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Sun Jul 19 10:43: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 D73B21B2ACF for ; Sun, 19 Jul 2015 10:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ZuTjSJq_kXpD for ; Sun, 19 Jul 2015 10:43:27 -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 BB85E1B2ACA for ; Sun, 19 Jul 2015 10:43:26 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E198DF5A7C36B for ; Sun, 19 Jul 2015 17:43:20 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t6JHhNlI016183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 19 Jul 2015 17:43:23 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sun, 19 Jul 2015 13:43:23 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: A few other misc. comments on draft-ietf-netmod-acl-model-03 Thread-Index: AdDCSmd3mYKQXXKSQAekT07WIMveDA== Date: Sun, 19 Jul 2015 17:43:23 +0000 Message-ID: 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: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CAA0619US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: [netmod] A few other misc. comments on draft-ietf-netmod-acl-model-03 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: Sun, 19 Jul 2015 17:43:34 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CAA0619US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I brought up ACL types and ACE numerical IDs in other separate email thread= s. This one is for a set of other misc. comments (one functional, the rest= are more editorial). A) Please make the metadata optional with an if-feature (or make each of in= put-interface & time-range their own if-features - that is probably better)= . Or drop those out of the model and leave them to augmentations. If we= do keep input-interface in the model as an if-feature then: - should we import ietf-interfaces with just the prefix"if" ? That is the = prefix in the ietf-interfaces module and what is used in the routing model = for example. - shouldn't the input-interface be a leafref (e.g. if:interface-ref) ? B) In section 3 there is a sentence about Metadata that mentions 'destinati= on prefix length'. I'm not sure that makes sense. A prefix length is part = of a prefix matching criteria (i.e. a rule in an ACE) and not really a piec= e of metadata about a particular packet. C) Is the access-list-entries container needed/useful ? If there is some r= eason to keep that then should we call it acl-entries ? (like how we have a= cl-name, acl-type, acl-oper-data, etc) D) Should we perhaps create identities for the protocols (based on whatever= IANA assignments there are) ? Right now all it says is uint8. We should = at least have a reference to some registry/document/rfc. E) We should mention that port means TCP or UDP port. Should we also consi= der some sort of 'when' statement such that port is only valid when protoco= l =3D tcp or udp ? Related to this -> some implementations use a wildcar= d of some sort that means "TCP or UDP". Maybe we should add that as an ide= ntity into "protocol" ? Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5CAA0619US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I brought up ACL types and ACE numerical IDs in other separate email t= hreads.  This one is for a set of other misc. comments (one functional= , the rest are more editorial).
 
A) Please make the metadata optional with an if-feature (or make each = of input-interface & time-range their own if-features – that is p= robably better).  Or drop those out of the model and leave them to aug= mentations.    If we do keep input-interface in the model as an if-feature then:
- should we import ietf-interfaces with just the prefix"if" = ?  That is the prefix in the ietf-interfaces module and what is used i= n the routing model for example.
- shouldn’t the input-interface be a leafref (e.g. if:interface-= ref) ?
 
B) In section 3 there is a sentence about Metadata that mentions 'dest= ination prefix length'.  I'm not sure that makes sense. A prefix lengt= h is part of a prefix matching criteria (i.e. a rule in an ACE) and not rea= lly a piece of metadata about a particular packet.
 
C) Is the access-list-entries container needed/useful ?  If there= is some reason to keep that then should we call it acl-entries ? (like how= we have acl-name, acl-type, acl-oper-data, etc)
 
D) Should we perhaps create identities for the protocols (based on wha= tever IANA assignments there are) ?  Right now all it says is uint8.&n= bsp; We should at least have a reference to some registry/document/rfc.
 
E) We should mention that port means TCP or UDP port.  Should we = also consider some sort of ‘when’ statement such that port is o= nly valid when protocol =3D tcp or udp ?    Related to this = -> some implementations use a wildcard of some sort that means “TC= P or UDP”.  Maybe we should add that as an identity into “pr= otocol” ?
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5CAA0619US70TWXCHMBA11z_-- From nobody Mon Jul 20 05:45:19 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 9D92B1A8740 for ; Mon, 20 Jul 2015 05:45: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] 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 ls3EAELwsVLp for ; Mon, 20 Jul 2015 05:45:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCAD1A8700 for ; Mon, 20 Jul 2015 05:45:14 -0700 (PDT) Received: from localhost (unknown [130.129.13.254]) by trail.lhotka.name (Postfix) with ESMTPSA id BA2181CC03EE for ; Mon, 20 Jul 2015 14:45:18 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 20 Jul 2015 14:45:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] Y34 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: Mon, 20 Jul 2015 12:45:18 -0000 Hi, after listening to the presentation of draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering whether the solution chosen for Y34 is really useful. The draft states they want to reuse ietf-interfaces but their tree in fact is +--rw device +--rw info | +--rw device-type? enumeration +--rw hardware +--rw interfaces | +--rw interface* [name] | ... +--rw qos So the "interfaces" container is no more a top-level node. There are three possible options: 1. Change the ietf-interfaces module. 2. Replicate its contents in another module. 3. Extend YANG so that a *specific* schema tree can be grafted at a given data node. IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it seems it is not so because it doesn't specify a concrete data model that's allowed at a given location. On the other hand, the only real contribution of "anydata" over "anyxml" is that is doesn't permit mixed content in XML, which is IMO not much. I know Y34 was already closed but I think it is more important to do things right before YANG 1.1 becomes an RFC. What I want to propose is this: - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but keep it for backward compatibility). - Introduce a new statement and data node type, e.g. "root", that will extend the schema tree starting from that data node with a precisely specified data model. The specification can be same or similar as in yang-library. I believe there are other use cases in the existing modules. For example, the ietf-routing module could simply define the data model for a single routing instance (i.e. without "routing-instance" list at the top), and it can be then used without changes on simple devices, and more complex router implementations can graft it as a subtree under "routing-instance", "networking-instance" or whatever. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 20 05:48:44 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 CEEDA1A87CC for ; Mon, 20 Jul 2015 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 SyfQyOFkufGN for ; Mon, 20 Jul 2015 05:48:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AD81A87B2 for ; Mon, 20 Jul 2015 05:48:06 -0700 (PDT) Received: from [IPv6:2001:df8:ffff:13:3999:35fe:238f:9582] (unknown [IPv6:2001:df8:ffff:13:3999:35fe:238f:9582]) by mail.nic.cz (Postfix) with ESMTPSA id CC0B3181413 for ; Mon, 20 Jul 2015 14:48:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437396484; bh=gGGTxrKH5BDRSkF5/nfH1aFcmwTWX10qWM5XrOpFyCY=; h=From:Date:To; b=ToMa+cpQTg9eWiuXQmc7G+D9Ue+wXviGTn0mGYQYbr50QWJLJOAIkKT4eaoNspeoW Aa14NZZQaHffdKrsiDEeXqfP6ul0Zk+Yrkho4xh76QWoTPGixURFfLt2BCC78CNz0d Da/Hl2/atXiP3ID3Cr0Hic64RSHN2TXcCBxLALT0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Jul 2015 14:48:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: netmod@ietf.org X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 12:48:42 -0000 > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > Hi, > > after listening to the presentation of > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > whether the solution chosen for Y34 is really useful. > > The draft states they want to reuse ietf-interfaces but their tree in > fact is > > +--rw device > +--rw info > | +--rw device-type? enumeration > +--rw hardware > +--rw interfaces > | +--rw interface* [name] > | ... > +--rw qos > > So the "interfaces" container is no more a top-level node. There are > three possible options: > > 1. Change the ietf-interfaces module. > 2. Replicate its contents in another module. > 3. Extend YANG so that a *specific* schema tree can be grafted at a > given data node. > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > seems it is not so because it doesn't specify a concrete data model > that's allowed at a given location. > > On the other hand, the only real contribution of "anydata" over "anyxml" > is that is doesn't permit mixed content in XML, which is IMO not much. > > I know Y34 was already closed but I think it is more important to do > things right before YANG 1.1 becomes an RFC. > > What I want to propose is this: > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > keep it for backward compatibility). s/Rename/Introduce/ > > - Introduce a new statement and data node type, e.g. "root", that will > extend the schema tree starting from that data node with a precisely > specified data model. The specification can be same or similar as > in yang-library. > > I believe there are other use cases in the existing modules. For > example, the ietf-routing module could simply define the data model for > a single routing instance (i.e. without "routing-instance" list at the > top), and it can be then used without changes on simple devices, and > more complex router implementations can graft it as a subtree under > "routing-instance", "networking-instance" or whatever. > > Lada > > -- > 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 Mon Jul 20 05:55:11 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 723E71A8704 for ; Mon, 20 Jul 2015 05:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Xu2ecPPmaYqL for ; Mon, 20 Jul 2015 05:55:08 -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 C09CD1A21C4 for ; Mon, 20 Jul 2015 05:55:07 -0700 (PDT) Received: by lblf12 with SMTP id f12so94558473lbl.2 for ; Mon, 20 Jul 2015 05: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=jiO36mbZ9xypY9wji3cseFPTaxIxcbhuE1sh51oHehU=; b=YQwY22pvlXcmiizkplAakVjYwDQ73uoGWuBc+UYv6TgvhnsOyVpsZr4Dvyx083dTLG i17GAF9za52+40CzECImTB5zqhSY4+aH/7TzQ8sXaVwQKs+a1wtjIID+vRGBckhWfQ4x RDl9oOOFLrXIMpIB5e2NVnE04oSwPdcBOcQ1y/L4Yod02pbjNxz2eE3rqyO2wrdpkqz3 nqjzp4JOakesIeep9Hl06WD0O+d3P+Pr0j4YFroh513fF0QJ+nty1boyFU5b5IfI8iwV 9spYZAlvoRWlZG8wiCOrXXJG2wt1NXY6VSKnmefMW8/N4Gmw9jF311fYfvxfq2EZhLru P2zQ== X-Gm-Message-State: ALoCoQmhRvKkvysGhATOeYkOdDuIgV8LmwXyfC51BBwbbftyJKW01pBrXBamK0nPrZJ9nfE+KhdP MIME-Version: 1.0 X-Received: by 10.112.24.71 with SMTP id s7mr26908899lbf.37.1437396906245; Mon, 20 Jul 2015 05:55:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 20 Jul 2015 05:55:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2015 05:55:06 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11343832ff9fba051b4e0b1b Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 12:55:10 -0000 --001a11343832ff9fba051b4e0b1b Content-Type: text/plain; charset=UTF-8 Hi, Can you explain why we need 2 broken anyxmls? (The original and a synonym?) The whole point of anydata is that it does not have XML cruft in it. I also don't get the value of a single top-level node called 'device' that every YANG model on the planet is supposed to augment. Can you explain why a protocol operation to retrieve the document root (/) is not sufficient for the top-level node? Andy On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > Hi, > > > > after listening to the presentation of > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > whether the solution chosen for Y34 is really useful. > > > > The draft states they want to reuse ietf-interfaces but their tree in > > fact is > > > > +--rw device > > +--rw info > > | +--rw device-type? enumeration > > +--rw hardware > > +--rw interfaces > > | +--rw interface* [name] > > | ... > > +--rw qos > > > > So the "interfaces" container is no more a top-level node. There are > > three possible options: > > > > 1. Change the ietf-interfaces module. > > 2. Replicate its contents in another module. > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > given data node. > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > seems it is not so because it doesn't specify a concrete data model > > that's allowed at a given location. > > > > On the other hand, the only real contribution of "anydata" over "anyxml" > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > I know Y34 was already closed but I think it is more important to do > > things right before YANG 1.1 becomes an RFC. > > > > What I want to propose is this: > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > > keep it for backward compatibility). > > s/Rename/Introduce/ > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > extend the schema tree starting from that data node with a precisely > > specified data model. The specification can be same or similar as > > in yang-library. > > > > I believe there are other use cases in the existing modules. For > > example, the ietf-routing module could simply define the data model for > > a single routing instance (i.e. without "routing-instance" list at the > > top), and it can be then used without changes on simple devices, and > > more complex router implementations can graft it as a subtree under > > "routing-instance", "networking-instance" or whatever. > > > > Lada > > > > -- > > 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 > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11343832ff9fba051b4e0b1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Can you explain why we need 2 broke= n anyxmls?
(The original and a synonym?) =C2=A0The whole point of=
anydata is that it does not have XML cruft in it.

=
I also don't get the value of a single top-level node called= 'device'
that every YANG model on the planet is supposed= to augment.
Can you explain why a protocol operation to retrieve= the
document root (/) is not sufficient for the top-level node?<= /div>

Andy



On Mon, Jul 20, 2015 = at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> Hi,
>
> after listening to the presentation of
> draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering=
> whether the solution chosen for Y34 is really useful.
>
> The draft states they want to reuse ietf-interfaces but their tree in<= br> > fact is
>
>=C2=A0 =C2=A0+--rw device
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw device-type?=C2=A0 =C2= =A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardware
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos
>
> So the "interfaces" container is no more a top-level node. T= here are
> three possible options:
>
> 1. Change the ietf-interfaces module.
> 2. Replicate its contents in another module.
> 3. Extend YANG so that a *specific* schema tree can be grafted at a >=C2=A0 =C2=A0given data node.
>
> IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 bu= t it
> seems it is not so because it doesn't specify a concrete data mode= l
> that's allowed at a given location.
>
> On the other hand, the only real contribution of "anydata" o= ver "anyxml"
> is that is doesn't permit mixed content in XML, which is IMO not m= uch.
>
> I know Y34 was already closed but I think it is more important to do > things right before YANG 1.1 becomes an RFC.
>
> What I want to propose is this:
>
> - Rename "anydata" as a synonym to "anyxml", and d= eprecate "anyxml" (but
>=C2=A0 keep it for backward compatibility).

s/Rename/Introduce/

>
> - Introduce a new statement and data node type, e.g. "root",= that will
>=C2=A0 extend the schema tree starting from that data node with a preci= sely
>=C2=A0 specified data model. The specification can be same or similar a= s
>=C2=A0 in yang-library.
>
> I believe there are other use cases in the existing modules. For
> example, the ietf-routing module could simply define the data model fo= r
> a single routing instance (i.e. without "routing-instance" l= ist at the
> top), and it can be then used without changes on simple devices, and > more complex router implementations can graft it as a subtree under > "routing-instance", "networking-instance" or whate= ver.
>
> Lada
>
> --
> 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




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

--001a11343832ff9fba051b4e0b1b-- From nobody Mon Jul 20 06:08: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 48BCC1A8778 for ; Mon, 20 Jul 2015 06:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 Ocdu0x4QzqIP for ; Mon, 20 Jul 2015 06:08:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DE41A8704 for ; Mon, 20 Jul 2015 06:08:19 -0700 (PDT) Received: from [IPv6:2001:df8:ffff:13:3999:35fe:238f:9582] (unknown [IPv6:2001:df8:ffff:13:3999:35fe:238f:9582]) by mail.nic.cz (Postfix) with ESMTPSA id 79D8018161D; Mon, 20 Jul 2015 15:08:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437397698; bh=eyVvqXQzDB2spL2e3unQ+wUIbGyJPp0Mbnuam/yelug=; h=From:Date:To; b=b+4mk/jcrZw7zpU4lU7w7N8VBuV+w6X7E3EFt6lwqPi5D8mUzbFRiHZZSZAHNE7Co AW02OqCK1tA/2qat4qpnWFlB5J025Tr8dRNIs0Sp04WsYbSse5quZ6gdNR6GqddLbM 1m94OUhNqu3FGDZFTUrFME5tE3cuDPYYt5G6u/pE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Jul 2015 15:08:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 13:08:22 -0000 > On 20 Jul 2015, at 14:55, Andy Bierman wrote: >=20 > Hi, >=20 > Can you explain why we need 2 broken anyxmls? > (The original and a synonym?) The whole point of > anydata is that it does not have XML cruft in it. Yes, I understand this was your main priority. For implementors using = off-the-shelf XML parsers and tools the XML cruft is not an issue at = all. Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2=80=A6= with no (YANG) schema available. My only complaint to =E2=80=9Canyxml=E2=80= =9D has always been that it is a misnomer for encodings other than XML. >=20 > I also don't get the value of a single top-level node called 'device' > that every YANG model on the planet is supposed to augment. > Can you explain why a protocol operation to retrieve the > document root (/) is not sufficient for the top-level node? I don=E2=80=99t intend to defend their model, the more serious problem = IMO is that a model for a single device/function may be needed in = another device that hosts many virtualised devices/functions of the = former type. We don=E2=80=99t have a good solution for this rather = typical situation. Lada >=20 > Andy >=20 >=20 >=20 > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka = wrote: >=20 > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > Hi, > > > > after listening to the presentation of > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am = wondering > > whether the solution chosen for Y34 is really useful. > > > > The draft states they want to reuse ietf-interfaces but their tree = in > > fact is > > > > +--rw device > > +--rw info > > | +--rw device-type? enumeration > > +--rw hardware > > +--rw interfaces > > | +--rw interface* [name] > > | ... > > +--rw qos > > > > So the "interfaces" container is no more a top-level node. There are > > three possible options: > > > > 1. Change the ietf-interfaces module. > > 2. Replicate its contents in another module. > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > given data node. > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but = it > > seems it is not so because it doesn't specify a concrete data model > > that's allowed at a given location. > > > > On the other hand, the only real contribution of "anydata" over = "anyxml" > > is that is doesn't permit mixed content in XML, which is IMO not = much. > > > > I know Y34 was already closed but I think it is more important to do > > things right before YANG 1.1 becomes an RFC. > > > > What I want to propose is this: > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" = (but > > keep it for backward compatibility). >=20 > s/Rename/Introduce/ >=20 > > > > - Introduce a new statement and data node type, e.g. "root", that = will > > extend the schema tree starting from that data node with a = precisely > > specified data model. The specification can be same or similar as > > in yang-library. > > > > I believe there are other use cases in the existing modules. For > > example, the ietf-routing module could simply define the data model = for > > a single routing instance (i.e. without "routing-instance" list at = the > > top), and it can be then used without changes on simple devices, and > > more complex router implementations can graft it as a subtree under > > "routing-instance", "networking-instance" or whatever. > > > > Lada > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 20 08:00:44 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 5778E1A8A72 for ; Mon, 20 Jul 2015 08:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1QEMYC_7rtYS for ; Mon, 20 Jul 2015 08:00:40 -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 44F511A8A13 for ; Mon, 20 Jul 2015 08:00:34 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so97044100lbb.0 for ; Mon, 20 Jul 2015 08:00: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; bh=3pZ5CgpBvjvphUDELHMByN8UpIEjGNE213vZ62LbcMw=; b=e3pB3Pti4Vqce3X75VIck/pW5T4QgHv+l7l9L4dWQrEl3o6wLnKwtKsH0Zjot5ClVl NtED+E5RWNyKVTwsZl9FbELR6uCq3LHRiJwfAEnBWHEE8Ek76kCwQ0upei06rQWt7CTl tPyIdRhVueHB8rovcezpF/1kd6l2pMR8B9+PUUIesfQfRobAHN0Wuxbp8Ws50iVYx604 j/tZ3bigBdQQAe41ojnSdkfBAWkTyrpyg9ftql8apbm1pp6CUV8usXADduvFfLZKOpW2 m2iOACPYi6MqV5k6on3DQO8yWBZYflC4R4FE2O7tLJlbrMO4uxm3VgevSnZdwBVj25dw 7oAw== X-Gm-Message-State: ALoCoQnG64nKBFqaQ1vHJQnHL4qyjnMSODPZXGccopcUKj7m0LhYyZkhLmiSBj9OQ4JAMmThjHZQ MIME-Version: 1.0 X-Received: by 10.152.42.205 with SMTP id q13mr27870225lal.119.1437404432640; Mon, 20 Jul 2015 08:00:32 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 20 Jul 2015 08:00:32 -0700 (PDT) In-Reply-To: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> Date: Mon, 20 Jul 2015 08:00:32 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c353e89b368a051b4fcc65 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 15:00:43 -0000 --001a11c353e89b368a051b4fcc65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > Hi, > > > > Can you explain why we need 2 broken anyxmls? > > (The original and a synonym?) The whole point of > > anydata is that it does not have XML cruft in it. > > Yes, I understand this was your main priority. For implementors using > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > yes it is an issue. We need something to model a container full of arbitrary YANG data nodes. This is something that can be applied to the contents of a datastore. > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2=80= =A6 with > no (YANG) schema available. My only complaint to =E2=80=9Canyxml=E2=80=9D= has always been > that it is a misnomer for encodings other than XML. > The message encoding on the wire is not the same issue as the contents of a datastore. Our server stores its own internal data structures. XML, JSON, CBOR are just message encoding formats between client and server. The datastore is not encoded in any of these formats. > > > > > I also don't get the value of a single top-level node called 'device' > > that every YANG model on the planet is supposed to augment. > > Can you explain why a protocol operation to retrieve the > > document root (/) is not sufficient for the top-level node? > > I don=E2=80=99t intend to defend their model, the more serious problem IM= O is that > a model for a single device/function may be needed in another device that > hosts many virtualised devices/functions of the former type. We don=E2=80= =99t have > a good solution for this rather typical situation. > But a single container called "whatever" provides no such aggregation. You would need a list for that. And the NMS might have multiple layers of hierarchy to represent various aggregations. The NP container called "device" is not helpful for aggregation. > Lada > Andy > > > > > Andy > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > Hi, > > > > > > after listening to the presentation of > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wonderin= g > > > whether the solution chosen for Y34 is really useful. > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > fact is > > > > > > +--rw device > > > +--rw info > > > | +--rw device-type? enumeration > > > +--rw hardware > > > +--rw interfaces > > > | +--rw interface* [name] > > > | ... > > > +--rw qos > > > > > > So the "interfaces" container is no more a top-level node. There are > > > three possible options: > > > > > > 1. Change the ietf-interfaces module. > > > 2. Replicate its contents in another module. > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > given data node. > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but i= t > > > seems it is not so because it doesn't specify a concrete data model > > > that's allowed at a given location. > > > > > > On the other hand, the only real contribution of "anydata" over > "anyxml" > > > is that is doesn't permit mixed content in XML, which is IMO not much= . > > > > > > I know Y34 was already closed but I think it is more important to do > > > things right before YANG 1.1 becomes an RFC. > > > > > > What I want to propose is this: > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" > (but > > > keep it for backward compatibility). > > > > s/Rename/Introduce/ > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that wil= l > > > extend the schema tree starting from that data node with a precisely > > > specified data model. The specification can be same or similar as > > > in yang-library. > > > > > > I believe there are other use cases in the existing modules. For > > > example, the ietf-routing module could simply define the data model f= or > > > a single routing instance (i.e. without "routing-instance" list at th= e > > > top), and it can be then used without changes on simple devices, and > > > more complex router implementations can graft it as a subtree under > > > "routing-instance", "networking-instance" or whatever. > > > > > > Lada > > > > > > -- > > > 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 > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c353e89b368a051b4fcc65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> Can you explain why we need 2 broken anyxmls?
> (The original and a synonym?)=C2=A0 The whole point of
> anydata is that it does not have XML cruft in it.

Yes, I understand this was your main priority. For implementors using off-t= he-shelf XML parsers and tools the XML cruft is not an issue at all.


yes it is an issue.
We need = something to model a container full of arbitrary YANG data nodes.
This is something that can be applied to the contents of a datastore.

=C2=A0
Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2=80=A6= with no (YANG) schema available. My only complaint to =E2=80=9Canyxml=E2= =80=9D has always been that it is a misnomer for encodings other than XML.<= br>

The message encoding on the wire is not= the same issue
as the contents of a datastore.=C2=A0 Our server = stores its own
internal data structures.=C2=A0 XML, JSON, CBOR ar= e just message
encoding formats between client and server.=C2=A0 = The datastore
is not encoded in any of these formats.
<= br>


=C2=A0

>
> I also don't get the value of a single top-level node called '= device'
> that every YANG model on the planet is supposed to augment.
> Can you explain why a protocol operation to retrieve the
> document root (/) is not sufficient for the top-level node?

I don=E2=80=99t intend to defend their model, the more serious problem IMO = is that a model for a single device/function may be needed in another devic= e that hosts many virtualised devices/functions of the former type. We don= =E2=80=99t have a good solution for this rather typical situation.

But a single container called "whatever&qu= ot; provides no such aggregation.
You would need a list for that.= And the NMS might have multiple
layers of hierarchy to represent= various aggregations.=C2=A0 The NP
container called "device= " is not helpful for aggregation.


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


Andy
=C2= =A0

>
> Andy
>
>
>
> On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > Hi,
> >
> > after listening to the presentation of
> > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wond= ering
> > whether the solution chosen for Y34 is really useful.
> >
> > The draft states they want to reuse ietf-interfaces but their tre= e in
> > fact is
> >
> >=C2=A0 =C2=A0+--rw device
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw device-type?=C2= =A0 =C2=A0enumeration
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardware
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interfaces
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw interface* [name]=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos
> >
> > So the "interfaces" container is no more a top-level no= de. There are
> > three possible options:
> >
> > 1. Change the ietf-interfaces module.
> > 2. Replicate its contents in another module.
> > 3. Extend YANG so that a *specific* schema tree can be grafted at= a
> >=C2=A0 =C2=A0given data node.
> >
> > IMO #1 & #2 are really bad. I thought Y34-04 was essentially = #3 but it
> > seems it is not so because it doesn't specify a concrete data= model
> > that's allowed at a given location.
> >
> > On the other hand, the only real contribution of "anydata&qu= ot; over "anyxml"
> > is that is doesn't permit mixed content in XML, which is IMO = not much.
> >
> > I know Y34 was already closed but I think it is more important to= do
> > things right before YANG 1.1 becomes an RFC.
> >
> > What I want to propose is this:
> >
> > - Rename "anydata" as a synonym to "anyxml", = and deprecate "anyxml" (but
> >=C2=A0 keep it for backward compatibility).
>
> s/Rename/Introduce/
>
> >
> > - Introduce a new statement and data node type, e.g. "root&q= uot;, that will
> >=C2=A0 extend the schema tree starting from that data node with a = precisely
> >=C2=A0 specified data model. The specification can be same or simi= lar as
> >=C2=A0 in yang-library.
> >
> > I believe there are other use cases in the existing modules. For<= br> > > example, the ietf-routing module could simply define the data mod= el for
> > a single routing instance (i.e. without "routing-instance&qu= ot; list at the
> > top), and it can be then used without changes on simple devices, = and
> > more complex router implementations can graft it as a subtree und= er
> > "routing-instance", "networking-instance" or = whatever.
> >
> > Lada
> >
> > --
> > 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
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod >

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c353e89b368a051b4fcc65-- From nobody Mon Jul 20 10:16:06 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 125EE1B2C78 for ; Mon, 20 Jul 2015 10:16:05 -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 a1kT2035czRo for ; Mon, 20 Jul 2015 10:16:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8B91B2CA0 for ; Mon, 20 Jul 2015 10:15:58 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:34c3:d2ae:b281:6803] (unknown [IPv6:2001:67c:370:176:34c3:d2ae:b281:6803]) by mail.nic.cz (Postfix) with ESMTPSA id D3AD31813D0 for ; Mon, 20 Jul 2015 19:15:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437412556; bh=hQtiTCe62AbJ1oRHDfQAyZEc2+3HLpv60qYHfAVN5sE=; h=From:Date:To; b=CQmVx3HgYsbFKRAghi2cH79sNxPCDWjCY+A5JxnDV3jqTAszQRVo8F2/K3sS4/pbf 8wIGw2LKrumWKD15ieFhrElAi+cHbspAjKk7KUEqdN738j4KIotNfNofFvLkaYZW0B TwvBQqNSCcm931TISHkBIUVbSQsiPim8BWQUJFNo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Jul 2015 19:15:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> To: NETMOD Working Group X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 17:16:05 -0000 > On 20 Jul 2015, at 17:00, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka = wrote: >=20 > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > Hi, > > > > Can you explain why we need 2 broken anyxmls? > > (The original and a synonym?) The whole point of > > anydata is that it does not have XML cruft in it. >=20 > Yes, I understand this was your main priority. For implementors using = off-the-shelf XML parsers and tools the XML cruft is not an issue at = all. >=20 >=20 > yes it is an issue. > We need something to model a container full of arbitrary YANG data = nodes. > This is something that can be applied to the contents of a datastore. anyxml can do that, too. >=20 > =20 > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2=80= =A6 with no (YANG) schema available. My only complaint to =E2=80=9Canyxml=E2= =80=9D has always been that it is a misnomer for encodings other than = XML. >=20 > The message encoding on the wire is not the same issue > as the contents of a datastore. Our server stores its own > internal data structures. XML, JSON, CBOR are just message > encoding formats between client and server. The datastore > is not encoded in any of these formats. The payload of anyxml needn=E2=80=99t directly map to a data subtree in = the usual sense. >=20 >=20 >=20 > =20 >=20 > > > > I also don't get the value of a single top-level node called = 'device' > > that every YANG model on the planet is supposed to augment. > > Can you explain why a protocol operation to retrieve the > > document root (/) is not sufficient for the top-level node? >=20 > I don=E2=80=99t intend to defend their model, the more serious problem = IMO is that a model for a single device/function may be needed in = another device that hosts many virtualised devices/functions of the = former type. We don=E2=80=99t have a good solution for this rather = typical situation. >=20 > But a single container called "whatever" provides no such aggregation. > You would need a list for that. And the NMS might have multiple > layers of hierarchy to represent various aggregations. The NP > container called "device" is not helpful for aggregation. The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D node = would be like a mount point in a Unix filesystem. Lada >=20 >=20 >=20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > Andy > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka = wrote: > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > Hi, > > > > > > after listening to the presentation of > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am = wondering > > > whether the solution chosen for Y34 is really useful. > > > > > > The draft states they want to reuse ietf-interfaces but their tree = in > > > fact is > > > > > > +--rw device > > > +--rw info > > > | +--rw device-type? enumeration > > > +--rw hardware > > > +--rw interfaces > > > | +--rw interface* [name] > > > | ... > > > +--rw qos > > > > > > So the "interfaces" container is no more a top-level node. There = are > > > three possible options: > > > > > > 1. Change the ietf-interfaces module. > > > 2. Replicate its contents in another module. > > > 3. Extend YANG so that a *specific* schema tree can be grafted at = a > > > given data node. > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 = but it > > > seems it is not so because it doesn't specify a concrete data = model > > > that's allowed at a given location. > > > > > > On the other hand, the only real contribution of "anydata" over = "anyxml" > > > is that is doesn't permit mixed content in XML, which is IMO not = much. > > > > > > I know Y34 was already closed but I think it is more important to = do > > > things right before YANG 1.1 becomes an RFC. > > > > > > What I want to propose is this: > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate = "anyxml" (but > > > keep it for backward compatibility). > > > > s/Rename/Introduce/ > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that = will > > > extend the schema tree starting from that data node with a = precisely > > > specified data model. The specification can be same or similar as > > > in yang-library. > > > > > > I believe there are other use cases in the existing modules. For > > > example, the ietf-routing module could simply define the data = model for > > > a single routing instance (i.e. without "routing-instance" list at = the > > > top), and it can be then used without changes on simple devices, = and > > > more complex router implementations can graft it as a subtree = under > > > "routing-instance", "networking-instance" or whatever. > > > > > > Lada > > > > > > -- > > > 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 > > > > > > > > > > _______________________________________________ > > 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 From nobody Mon Jul 20 10:29:13 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 627251B2CE2 for ; Mon, 20 Jul 2015 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 YDwgJETgJSjp for ; Mon, 20 Jul 2015 10:29:08 -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 D88931B2CF4 for ; Mon, 20 Jul 2015 10:29:06 -0700 (PDT) Received: by lagw2 with SMTP id w2so101356317lag.3 for ; Mon, 20 Jul 2015 10:29: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:cc:content-type; bh=oKLv4D/eDTmbZiXuJ+zJfAALdfA7eXv4hnuboWBUkHU=; b=M6WU1hFJHcPIzJCV3r/krdINYSGW1rz6FbdLXvXXuYTM/E3BHv+YiEIPvlJy614OKi NdMgsRvWjKQDo1+7Uce2F97ASXNNsE2SN2W1Zgs17yAALyy0sKnsFOUPCZtmzA0VbQzO 9RDz68NhSfinBkD3pjLHcMZA/Gfgx4XKCftmhb3MioLsvp6GNgYCDIYNmmnVtc7j7gtC qD4HAxdmO4WDQsl12KARwWLBQHSk7wWKcJtTC1+klr8idCjgvsaw2P+/O2ZzV0cbAWlb y5Rs3UgpHkpKOCgQmdy1RVPT0mYNVgfKd+TMT6vAAIDvvOklLqyo+V5VwBMJew6lLtMx jB/g== X-Gm-Message-State: ALoCoQltOSfkFT5m5+SczkNraDsjkf6nJzwexC2w7I5J8SrLjZgEgnF49ALi5RtRJglHKkbp+Fvh MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr28350441lbc.82.1437413345392; Mon, 20 Jul 2015 10:29:05 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 20 Jul 2015 10:29:05 -0700 (PDT) In-Reply-To: <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> Date: Mon, 20 Jul 2015 10:29:05 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134dcc8d91130051b51df64 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 17:29:11 -0000 --001a1134dcc8d91130051b51df64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > > > Hi, > > > > > > Can you explain why we need 2 broken anyxmls? > > > (The original and a synonym?) The whole point of > > > anydata is that it does not have XML cruft in it. > > > > Yes, I understand this was your main priority. For implementors using > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > > > > > yes it is an issue. > > We need something to model a container full of arbitrary YANG data node= s. > > This is something that can be applied to the contents of a datastore. > > anyxml can do that, too. > the WG already decided it can't. The extra XML PIs, etc. are not accepted by all servers, remember? There is no use for the extra stuff in the datastore. I don't see why we need 2 anyxml constructs that are not supported by the industry. One is already too many. > > > > > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2= =80=A6 with > no (YANG) schema available. My only complaint to =E2=80=9Canyxml=E2=80=9D= has always been > that it is a misnomer for encodings other than XML. > > > > The message encoding on the wire is not the same issue > > as the contents of a datastore. Our server stores its own > > internal data structures. XML, JSON, CBOR are just message > > encoding formats between client and server. The datastore > > is not encoded in any of these formats. > > The payload of anyxml needn=E2=80=99t directly map to a data subtree in t= he usual > sense. > that's precisely the difference between anyxml and anydata. The anydata node MUST map directly into data subtrees. > > > > > > > > > > > > > > > > > I also don't get the value of a single top-level node called 'device' > > > that every YANG model on the planet is supposed to augment. > > > Can you explain why a protocol operation to retrieve the > > > document root (/) is not sufficient for the top-level node? > > > > I don=E2=80=99t intend to defend their model, the more serious problem = IMO is > that a model for a single device/function may be needed in another device > that hosts many virtualised devices/functions of the former type. We don= =E2=80=99t > have a good solution for this rather typical situation. > > > > But a single container called "whatever" provides no such aggregation. > > You would need a list for that. And the NMS might have multiple > > layers of hierarchy to represent various aggregations. The NP > > container called "device" is not helpful for aggregation. > > The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D node wo= uld be like a > mount point in a Unix filesystem. > > Are you saying all data on a device needs to be in a top-level list called 'device' because an NMS might exist that wants to have the datastores from lots of devices? As Martin pointed out several times, the NMS can make its own container or lists. It does not need the device to mirror its own structure. Lada > Andy > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Andy > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > wrote: > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > Hi, > > > > > > > > after listening to the presentation of > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > wondering > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > The draft states they want to reuse ietf-interfaces but their tree = in > > > > fact is > > > > > > > > +--rw device > > > > +--rw info > > > > | +--rw device-type? enumeration > > > > +--rw hardware > > > > +--rw interfaces > > > > | +--rw interface* [name] > > > > | ... > > > > +--rw qos > > > > > > > > So the "interfaces" container is no more a top-level node. There ar= e > > > > three possible options: > > > > > > > > 1. Change the ietf-interfaces module. > > > > 2. Replicate its contents in another module. > > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > > given data node. > > > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but > it > > > > seems it is not so because it doesn't specify a concrete data model > > > > that's allowed at a given location. > > > > > > > > On the other hand, the only real contribution of "anydata" over > "anyxml" > > > > is that is doesn't permit mixed content in XML, which is IMO not > much. > > > > > > > > I know Y34 was already closed but I think it is more important to d= o > > > > things right before YANG 1.1 becomes an RFC. > > > > > > > > What I want to propose is this: > > > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" > (but > > > > keep it for backward compatibility). > > > > > > s/Rename/Introduce/ > > > > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that > will > > > > extend the schema tree starting from that data node with a precise= ly > > > > specified data model. The specification can be same or similar as > > > > in yang-library. > > > > > > > > I believe there are other use cases in the existing modules. For > > > > example, the ietf-routing module could simply define the data model > for > > > > a single routing instance (i.e. without "routing-instance" list at > the > > > > top), and it can be then used without changes on simple devices, an= d > > > > more complex router implementations can graft it as a subtree under > > > > "routing-instance", "networking-instance" or whatever. > > > > > > > > Lada > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134dcc8d91130051b51df64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > Can you explain why we need 2 broken anyxmls?
> > (The original and a synonym?)=C2=A0 The whole point of
> > anydata is that it does not have XML cruft in it.
>
> Yes, I understand this was your main priority. For implementors using = off-the-shelf XML parsers and tools the XML cruft is not an issue at all. >
>
> yes it is an issue.
> We need something to model a container full of arbitrary YANG data nod= es.
> This is something that can be applied to the contents of a datastore.<= br>
anyxml can do that, too.


the WG already decided it can't.
The extra XML PIs, etc. are= not accepted by all servers, remember?
There is no use for the e= xtra stuff in the datastore.
=C2=A0I don't see why we need 2 = anyxml constructs that are not
supported by the industry.=C2=A0 O= ne is already too many.


>
>
> Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2= =80=A6 with no (YANG) schema available. My only complaint to =E2=80=9Canyxm= l=E2=80=9D has always been that it is a misnomer for encodings other than X= ML.
>
> The message encoding on the wire is not the same issue
> as the contents of a datastore.=C2=A0 Our server stores its own
> internal data structures.=C2=A0 XML, JSON, CBOR are just message
> encoding formats between client and server.=C2=A0 The datastore
> is not encoded in any of these formats.

The payload of anyxml needn=E2=80=99t directly map to a data subtree in the= usual sense.

that's precisely the = difference between anyxml and anydata.
The anydata node MUST map = directly into data subtrees.

=C2=A0

>
>
>
>
>
> >
> > I also don't get the value of a single top-level node called = 'device'
> > that every YANG model on the planet is supposed to augment.
> > Can you explain why a protocol operation to retrieve the
> > document root (/) is not sufficient for the top-level node?
>
> I don=E2=80=99t intend to defend their model, the more serious problem= IMO is that a model for a single device/function may be needed in another = device that hosts many virtualised devices/functions of the former type. We= don=E2=80=99t have a good solution for this rather typical situation.
>
> But a single container called "whatever" provides no such ag= gregation.
> You would need a list for that. And the NMS might have multiple
> layers of hierarchy to represent various aggregations.=C2=A0 The NP > container called "device" is not helpful for aggregation.
The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D node woul= d be like a mount point in a Unix filesystem.


Are you saying all data on a device ne= eds to be in a top-level list called 'device'
because an = NMS might exist that =C2=A0wants to have the datastores from lots of device= s?
As Martin pointed out several times, the NMS can make its own = container or
lists.=C2=A0 It does not need the device to mirror i= ts own structure.=C2=A0


Lada

Andy
=C2=A0

>
>
>
> Lada
>
>
> Andy
>
>
> >
> > Andy
> >
> >
> >
> > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > Hi,
> > >
> > > after listening to the presentation of
> > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am= wondering
> > > whether the solution chosen for Y34 is really useful.
> > >
> > > The draft states they want to reuse ietf-interfaces but thei= r tree in
> > > fact is
> > >
> > >=C2=A0 =C2=A0+--rw device
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw device-type?= =C2=A0 =C2=A0enumeration
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardware
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interfaces
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw interface* [= name]
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0... > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos
> > >
> > > So the "interfaces" container is no more a top-lev= el node. There are
> > > three possible options:
> > >
> > > 1. Change the ietf-interfaces module.
> > > 2. Replicate its contents in another module.
> > > 3. Extend YANG so that a *specific* schema tree can be graft= ed at a
> > >=C2=A0 =C2=A0given data node.
> > >
> > > IMO #1 & #2 are really bad. I thought Y34-04 was essenti= ally #3 but it
> > > seems it is not so because it doesn't specify a concrete= data model
> > > that's allowed at a given location.
> > >
> > > On the other hand, the only real contribution of "anyda= ta" over "anyxml"
> > > is that is doesn't permit mixed content in XML, which is= IMO not much.
> > >
> > > I know Y34 was already closed but I think it is more importa= nt to do
> > > things right before YANG 1.1 becomes an RFC.
> > >
> > > What I want to propose is this:
> > >
> > > - Rename "anydata" as a synonym to "anyxml&qu= ot;, and deprecate "anyxml" (but
> > >=C2=A0 keep it for backward compatibility).
> >
> > s/Rename/Introduce/
> >
> > >
> > > - Introduce a new statement and data node type, e.g. "r= oot", that will
> > >=C2=A0 extend the schema tree starting from that data node wi= th a precisely
> > >=C2=A0 specified data model. The specification can be same or= similar as
> > >=C2=A0 in yang-library.
> > >
> > > I believe there are other use cases in the existing modules.= For
> > > example, the ietf-routing module could simply define the dat= a model for
> > > a single routing instance (i.e. without "routing-instan= ce" list at the
> > > top), and it can be then used without changes on simple devi= ces, and
> > > more complex router implementations can graft it as a subtre= e under
> > > "routing-instance", "networking-instance"= ; or whatever.
> > >
> > > Lada
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/net= mod
> >
> > --
> > 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




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

--001a1134dcc8d91130051b51df64-- From nobody Mon Jul 20 10:42:53 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 89D701B2CCE for ; Mon, 20 Jul 2015 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 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, 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 7EvmJ8pRsIbW for ; Mon, 20 Jul 2015 10:42:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0DE1B2A1C for ; Mon, 20 Jul 2015 10:42:50 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:34c3:d2ae:b281:6803] (unknown [IPv6:2001:67c:370:176:34c3:d2ae:b281:6803]) by mail.nic.cz (Postfix) with ESMTPSA id 33990180E5E; Mon, 20 Jul 2015 19:42:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437414169; bh=mOk5e1XhxAPReRMf0M/PbrlSqUzIW5N6U3fhJ6NUWPU=; h=From:Date:To; b=Z2zGkqnEX7oYv5WHYrQqrv1IALAK9QGkEZQ7Jc8ajpn0nIZzfSilE8tXReLEGzcFX RjnoW2vqFN6hXcnGJZrtuBWuD9IbXG0LPtHTYeeiEo1zWmUnRdqJKhXOKL6Op0nN4h SgHlURo5c7wUdP+faLYfqqv8DNTs40yjTaS7YrTA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Jul 2015 19:42:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 17:42:52 -0000 > On 20 Jul 2015, at 19:29, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka = wrote: >=20 > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka = wrote: > > > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > > > Hi, > > > > > > Can you explain why we need 2 broken anyxmls? > > > (The original and a synonym?) The whole point of > > > anydata is that it does not have XML cruft in it. > > > > Yes, I understand this was your main priority. For implementors = using off-the-shelf XML parsers and tools the XML cruft is not an issue = at all. > > > > > > yes it is an issue. > > We need something to model a container full of arbitrary YANG data = nodes. > > This is something that can be applied to the contents of a = datastore. >=20 > anyxml can do that, too. >=20 >=20 > the WG already decided it can't. > The extra XML PIs, etc. are not accepted by all servers, remember? > There is no use for the extra stuff in the datastore. > I don't see why we need 2 anyxml constructs that are not > supported by the industry. One is already too many. I agree, but this is what we are going to have. My proposal was to have = just one with two different names. >=20 >=20 > > > > > > Anyway, I believe there are use cases for arbitrary = XML/JSON/CBOR/=E2=80=A6 with no (YANG) schema available. My only = complaint to =E2=80=9Canyxml=E2=80=9D has always been that it is a = misnomer for encodings other than XML. > > > > The message encoding on the wire is not the same issue > > as the contents of a datastore. Our server stores its own > > internal data structures. XML, JSON, CBOR are just message > > encoding formats between client and server. The datastore > > is not encoded in any of these formats. >=20 > The payload of anyxml needn=E2=80=99t directly map to a data subtree = in the usual sense. >=20 > that's precisely the difference between anyxml and anydata. > The anydata node MUST map directly into data subtrees. If the server doesn=E2=80=99t know the YANG data model at run time = (which is possible) then it cannot do it - for instance, it cannot = properly map module names to namespace URI or handle lists. >=20 > =20 >=20 > > > > > > > > > > > > > > > > I also don't get the value of a single top-level node called = 'device' > > > that every YANG model on the planet is supposed to augment. > > > Can you explain why a protocol operation to retrieve the > > > document root (/) is not sufficient for the top-level node? > > > > I don=E2=80=99t intend to defend their model, the more serious = problem IMO is that a model for a single device/function may be needed = in another device that hosts many virtualised devices/functions of the = former type. We don=E2=80=99t have a good solution for this rather = typical situation. > > > > But a single container called "whatever" provides no such = aggregation. > > You would need a list for that. And the NMS might have multiple > > layers of hierarchy to represent various aggregations. The NP > > container called "device" is not helpful for aggregation. >=20 > The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D node = would be like a mount point in a Unix filesystem. >=20 >=20 > Are you saying all data on a device needs to be in a top-level list = called 'device' > because an NMS might exist that wants to have the datastores from = lots of devices? > As Martin pointed out several times, the NMS can make its own = container or > lists. It does not need the device to mirror its own structure. As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevice=E2=80=9D= container. What would be really useful is to have the possibility to do = e.g. this: virtual-node* [name] name if:interfaces ... to support the use case where all virtual nodes are managed by the same = NETCONF/RESTCONF server. Lada > =20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Andy > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka = wrote: > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > Hi, > > > > > > > > after listening to the presentation of > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am = wondering > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > The draft states they want to reuse ietf-interfaces but their = tree in > > > > fact is > > > > > > > > +--rw device > > > > +--rw info > > > > | +--rw device-type? enumeration > > > > +--rw hardware > > > > +--rw interfaces > > > > | +--rw interface* [name] > > > > | ... > > > > +--rw qos > > > > > > > > So the "interfaces" container is no more a top-level node. There = are > > > > three possible options: > > > > > > > > 1. Change the ietf-interfaces module. > > > > 2. Replicate its contents in another module. > > > > 3. Extend YANG so that a *specific* schema tree can be grafted = at a > > > > given data node. > > > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 = but it > > > > seems it is not so because it doesn't specify a concrete data = model > > > > that's allowed at a given location. > > > > > > > > On the other hand, the only real contribution of "anydata" over = "anyxml" > > > > is that is doesn't permit mixed content in XML, which is IMO not = much. > > > > > > > > I know Y34 was already closed but I think it is more important = to do > > > > things right before YANG 1.1 becomes an RFC. > > > > > > > > What I want to propose is this: > > > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate = "anyxml" (but > > > > keep it for backward compatibility). > > > > > > s/Rename/Introduce/ > > > > > > > > > > > - Introduce a new statement and data node type, e.g. "root", = that will > > > > extend the schema tree starting from that data node with a = precisely > > > > specified data model. The specification can be same or similar = as > > > > in yang-library. > > > > > > > > I believe there are other use cases in the existing modules. For > > > > example, the ietf-routing module could simply define the data = model for > > > > a single routing instance (i.e. without "routing-instance" list = at the > > > > top), and it can be then used without changes on simple devices, = and > > > > more complex router implementations can graft it as a subtree = under > > > > "routing-instance", "networking-instance" or whatever. > > > > > > > > Lada > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 20 10:57:26 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 0BF1B1A87CD for ; Mon, 20 Jul 2015 10:57:25 -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 e66KudcqD0Ap for ; Mon, 20 Jul 2015 10:57:24 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A371B2FE8 for ; Mon, 20 Jul 2015 10:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=322; q=dns/txt; s=iport; t=1437415044; x=1438624644; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/f9N4wfSd1uNsVQPM00apRvhzA8FY5GN/tB4S2sbGVI=; b=O58NWDotTtCcvgY8xCTtzFtOKxj1INFQcWelrGT8sbCbSuFlyseS+9n0 /+n9ymbAMqUs+4Szf2VU/L6a2Mg1vADYSU7de4LgQR/2UyVJFbKDXTAYo lk1hkMBxagwbm3pgaiTVDb3OtbikYX0x+XbNywuFI9jaSUyA29kfMTbWS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BLBQDUNa1V/4UNJK1cgxOBQ4McwGiBEzsRAQEBAQEBAYEKhCojEVcBIgImAgQwFRIEiEGibo9flggBAQEBAQUBAQEBAQEBARqBIpIfL4EUBZRSAYwggUOTY4NhJoN8gjaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,509,1432598400"; d="scan'208";a="170553277" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 20 Jul 2015 17:57:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6KHvLCn007536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 17:57:21 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.211]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 12:57:21 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: draft-ietf-netmod-syslog-model-04.txt Implementations Thread-Index: AQHQwxWGxQGyOXXviEa7Q4QKBWrxOQ== Date: Mon, 20 Jul 2015 17:57:21 +0000 Message-ID: <445033FD-900B-4143-932A-5E38BCF836B4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.181] Content-Type: text/plain; charset="utf-8" Content-ID: <3C5CD229CACA0A46A15760759F7094EA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [netmod] draft-ietf-netmod-syslog-model-04.txt Implementations 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: Mon, 20 Jul 2015 17:57:25 -0000 Q2FybCwNCg0KVGhhbmtzIGZvciB5b3VyIHF1ZXN0aW9uIGluIHRoZSBOZXRtb2QgbWVldGluZyBk dXJpbmcgdGhlIHJldmlldyBvZiB0aGUgaWV0Zi1zeXNsb2cgbW9kZWwuDQoNClJlZ2FyZGluZyB0 aGUgbW9kZWwgaW1wbGVtZW50YXRpb246IHRoZSBtb2RlbCBoYXMgYmVlbiBpbXBsZW1lbnRlZCBp biBPREwgYW5kIGludGVybmFsbHkgaW4gQ2lzY28ncyBOWE9TLg0KDQpUaGFua3MsDQoNCkNseWRl DQoNCg== From nobody Mon Jul 20 11:15: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 D2EB31A0093 for ; Mon, 20 Jul 2015 11:14:59 -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 nSvF9n_BV31M for ; Mon, 20 Jul 2015 11:14:58 -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 192EE1B2A71 for ; Mon, 20 Jul 2015 11:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=535; q=dns/txt; s=iport; t=1437416089; x=1438625689; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eQTAgWkH0leMZZJEg8+HocLZPS7o8czsIKN46WbYl4M=; b=lgTKbCWqRFgdvD5zP/6dfq1AzWn8rjWHnJ5GVs4dDD4DpwbUkpEDRP05 uABvC5yh9ld6Q/fsUZOGQuacXinHuEG6zdBJf4k/5VTnWIvFmO8+o8zX5 w219fB3iIDa7FSIQ0gsCmJMpC1AiRGnFNNFvtuSqUqL1/VJ0EDYbeblPA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfAwBCOq1V/4ENJK1cgxNUWg8Gu2cJgWsKhTdKAoEvOBQBAQEBAQEBgQqEIwEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FiCYIDchBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLTIRTMweEKwWUUgGMIIFDk2ODYSaDfG+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,509,1432598400"; d="scan'208";a="17084743" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jul 2015 18:14:48 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6KIEmSa025017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 18:14:48 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 13:14:47 -0500 From: "Carl Moberg (camoberg)" To: "Clyde Wildes (cwildes)" Thread-Topic: [netmod] draft-ietf-netmod-syslog-model-04.txt Implementations Thread-Index: AQHQwxWGxQGyOXXviEa7Q4QKBWrxOZ3k/h0A Date: Mon, 20 Jul 2015 18:14:46 +0000 Message-ID: <1B4AE25D-C720-4593-881D-979064BCAABA@cisco.com> References: <445033FD-900B-4143-932A-5E38BCF836B4@cisco.com> In-Reply-To: <445033FD-900B-4143-932A-5E38BCF836B4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.211.189] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C8E41EDD40F23439A516EBF2F8EB19B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-syslog-model-04.txt Implementations 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: Mon, 20 Jul 2015 18:15:00 -0000 Clyde, Excellent, thanks! > On Jul 20, 2015, at 7:57 PM, Clyde Wildes (cwildes) w= rote: >=20 > Carl, >=20 > Thanks for your question in the Netmod meeting during the review of the i= etf-syslog model. >=20 > Regarding the model implementation: the model has been implemented in ODL= and internally in Cisco's NXOS. >=20 > Thanks, >=20 > Clyde >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jul 20 14:00:56 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 23D301B31CC for ; Mon, 20 Jul 2015 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_210=0.6, 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 StfP35eS_SbJ for ; Mon, 20 Jul 2015 14:00: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 AFF2F1B31CB for ; Mon, 20 Jul 2015 14:00:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8968B10DB; Mon, 20 Jul 2015 23:00: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 Pn385QLDYvYT; Mon, 20 Jul 2015 23:00:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 20 Jul 2015 23:00:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 256222003A; Mon, 20 Jul 2015 23:00: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 8oMkKYEiOucu; Mon, 20 Jul 2015 23:00: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 9D09520037; Mon, 20 Jul 2015 23:00:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 913BF3545327; Mon, 20 Jul 2015 23:00:42 +0200 (CEST) Date: Mon, 20 Jul 2015 23:00:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150720210041.GA17614@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 20 Jul 2015 21:00:55 -0000 Lada, Y34 is closed and I have not seen any new argument here that indicates we made a major mistake with the resolution of Y34. As such, Y34 remains closed. If you want to discuss new ideas to relocate or "symlink" data models, please do so in a separate thread. (And no, we do not accept new issues for YANG 1.1 either at this point in time.) /js On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 19:29, Andy Bierman wrote: > > > > > > > > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > > > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > Can you explain why we need 2 broken anyxmls? > > > > (The original and a synonym?) The whole point of > > > > anydata is that it does not have XML cruft in it. > > > > > > Yes, I understand this was your main priority. For implementors using off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > > > > > > > > yes it is an issue. > > > We need something to model a container full of arbitrary YANG data nodes. > > > This is something that can be applied to the contents of a datastore. > > > > anyxml can do that, too. > > > > > > the WG already decided it can't. > > The extra XML PIs, etc. are not accepted by all servers, remember? > > There is no use for the extra stuff in the datastore. > > I don't see why we need 2 anyxml constructs that are not > > supported by the industry. One is already too many. > > I agree, but this is what we are going to have. My proposal was to have just one with two different names. > > > > > > > > > > > > > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no (YANG) schema available. My only complaint to “anyxml” has always been that it is a misnomer for encodings other than XML. > > > > > > The message encoding on the wire is not the same issue > > > as the contents of a datastore. Our server stores its own > > > internal data structures. XML, JSON, CBOR are just message > > > encoding formats between client and server. The datastore > > > is not encoded in any of these formats. > > > > The payload of anyxml needn’t directly map to a data subtree in the usual sense. > > > > that's precisely the difference between anyxml and anydata. > > The anydata node MUST map directly into data subtrees. > > If the server doesn’t know the YANG data model at run time (which is possible) then it cannot do it - for instance, it cannot properly map module names to namespace URI or handle lists. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also don't get the value of a single top-level node called 'device' > > > > that every YANG model on the planet is supposed to augment. > > > > Can you explain why a protocol operation to retrieve the > > > > document root (/) is not sufficient for the top-level node? > > > > > > I don’t intend to defend their model, the more serious problem IMO is that a model for a single device/function may be needed in another device that hosts many virtualised devices/functions of the former type. We don’t have a good solution for this rather typical situation. > > > > > > But a single container called "whatever" provides no such aggregation. > > > You would need a list for that. And the NMS might have multiple > > > layers of hierarchy to represent various aggregations. The NP > > > container called "device" is not helpful for aggregation. > > > > The parent node can be a list as well. The “root” node would be like a mount point in a Unix filesystem. > > > > > > Are you saying all data on a device needs to be in a top-level list called 'device' > > because an NMS might exist that wants to have the datastores from lots of devices? > > As Martin pointed out several times, the NMS can make its own container or > > lists. It does not need the device to mirror its own structure. > > As I said, I don’t care that much about the “device” container. What would be really useful is to have the possibility to do e.g. this: > > virtual-node* [name] > name > if:interfaces > ... > > to support the use case where all virtual nodes are managed by the same NETCONF/RESTCONF server. > > Lada > > > > > > > > > Lada > > > > Andy > > > > > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > > > Hi, > > > > > > > > > > after listening to the presentation of > > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > > > fact is > > > > > > > > > > +--rw device > > > > > +--rw info > > > > > | +--rw device-type? enumeration > > > > > +--rw hardware > > > > > +--rw interfaces > > > > > | +--rw interface* [name] > > > > > | ... > > > > > +--rw qos > > > > > > > > > > So the "interfaces" container is no more a top-level node. There are > > > > > three possible options: > > > > > > > > > > 1. Change the ietf-interfaces module. > > > > > 2. Replicate its contents in another module. > > > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > > > given data node. > > > > > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > > > > seems it is not so because it doesn't specify a concrete data model > > > > > that's allowed at a given location. > > > > > > > > > > On the other hand, the only real contribution of "anydata" over "anyxml" > > > > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > > > > > > > I know Y34 was already closed but I think it is more important to do > > > > > things right before YANG 1.1 becomes an RFC. > > > > > > > > > > What I want to propose is this: > > > > > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > > > > > keep it for backward compatibility). > > > > > > > > s/Rename/Introduce/ > > > > > > > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > > > > extend the schema tree starting from that data node with a precisely > > > > > specified data model. The specification can be same or similar as > > > > > in yang-library. > > > > > > > > > > I believe there are other use cases in the existing modules. For > > > > > example, the ietf-routing module could simply define the data model for > > > > > a single routing instance (i.e. without "routing-instance" list at the > > > > > top), and it can be then used without changes on simple devices, and > > > > > more complex router implementations can graft it as a subtree under > > > > > "routing-instance", "networking-instance" or whatever. > > > > > > > > > > Lada > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > _______________________________________________ > > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 21 00:16:53 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 106911AD0C3 for ; Tue, 21 Jul 2015 00:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 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, MIME_8BIT_HEADER=0.3, 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 pek4JrOot4jw for ; Tue, 21 Jul 2015 00:16:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2AC1A002D for ; Tue, 21 Jul 2015 00:16:48 -0700 (PDT) Received: from [IPv6:2001:df8:ffff:13:e415:234f:a7c:b9a8] (unknown [IPv6:2001:df8:ffff:13:e415:234f:a7c:b9a8]) by mail.nic.cz (Postfix) with ESMTPSA id 26685181724; Tue, 21 Jul 2015 09:16:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437463007; bh=TPRHIasSLNJ0qCbF1hy67j9cmLKLdSS5jvA+q41l+ho=; h=From:Date:To; b=rw3piMTKpB7x9AoczW3FIIxS/mmlCrVNOw2XhexsEQTrbrVLTHqHLrp1UkyUDT4Av JaMvJqihifftNhBMpKj7ptOcoLv7CA7PjLv+u3UkYYpH1F57O6YpnqXJ++UlZs6i2S DN+uMxpSu0SlgK5HQOEzc2iEbaWq//f6LAP0E+n4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150720210041.GA17614@elstar.local> Date: Tue, 21 Jul 2015 09:16:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Tue, 21 Jul 2015 07:16:52 -0000 > On 20 Jul 2015, at 23:00, Juergen Schoenwaelder = wrote: >=20 > Lada, >=20 > Y34 is closed and I have not seen any new argument here that indicates > we made a major mistake with the resolution of Y34. As such, Y34 > remains closed. Of course, I was expecting this reaction. I think I did present *some* = arguments, and I am leaving it to others to judge whether they are = relevant or not. Even if it was a minor mistake, it is IMO still worth = fixing. >=20 > If you want to discuss new ideas to relocate or "symlink" data models, > please do so in a separate thread. (And no, we do not accept new > issues for YANG 1.1 either at this point in time.) It=E2=80=99s not about symlinks in the data tree but rather about a = method for combining schemas that is complementary to =E2=80=9Caugment=E2=80= =9D - pull versus push. There is sufficient evidence that it was one of the use cases for = =E2=80=9Canydata=E2=80=9D, e.g. in configlets. The gap in =E2=80=9Canydata= =E2=80=9D definition for similar use cases is that it cannot specify a = schema for its contents. Lada=20 >=20 > /js >=20 > On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 20 Jul 2015, at 19:29, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka = wrote: >>>=20 >>>> On 20 Jul 2015, at 17:00, Andy Bierman wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka = wrote: >>>>=20 >>>>> On 20 Jul 2015, at 14:55, Andy Bierman wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Can you explain why we need 2 broken anyxmls? >>>>> (The original and a synonym?) The whole point of >>>>> anydata is that it does not have XML cruft in it. >>>>=20 >>>> Yes, I understand this was your main priority. For implementors = using off-the-shelf XML parsers and tools the XML cruft is not an issue = at all. >>>>=20 >>>>=20 >>>> yes it is an issue. >>>> We need something to model a container full of arbitrary YANG data = nodes. >>>> This is something that can be applied to the contents of a = datastore. >>>=20 >>> anyxml can do that, too. >>>=20 >>>=20 >>> the WG already decided it can't. >>> The extra XML PIs, etc. are not accepted by all servers, remember? >>> There is no use for the extra stuff in the datastore. >>> I don't see why we need 2 anyxml constructs that are not >>> supported by the industry. One is already too many. >>=20 >> I agree, but this is what we are going to have. My proposal was to = have just one with two different names. >>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Anyway, I believe there are use cases for arbitrary = XML/JSON/CBOR/=E2=80=A6 with no (YANG) schema available. My only = complaint to =E2=80=9Canyxml=E2=80=9D has always been that it is a = misnomer for encodings other than XML. >>>>=20 >>>> The message encoding on the wire is not the same issue >>>> as the contents of a datastore. Our server stores its own >>>> internal data structures. XML, JSON, CBOR are just message >>>> encoding formats between client and server. The datastore >>>> is not encoded in any of these formats. >>>=20 >>> The payload of anyxml needn=E2=80=99t directly map to a data subtree = in the usual sense. >>>=20 >>> that's precisely the difference between anyxml and anydata. >>> The anydata node MUST map directly into data subtrees. >>=20 >> If the server doesn=E2=80=99t know the YANG data model at run time = (which is possible) then it cannot do it - for instance, it cannot = properly map module names to namespace URI or handle lists. >>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> I also don't get the value of a single top-level node called = 'device' >>>>> that every YANG model on the planet is supposed to augment. >>>>> Can you explain why a protocol operation to retrieve the >>>>> document root (/) is not sufficient for the top-level node? >>>>=20 >>>> I don=E2=80=99t intend to defend their model, the more serious = problem IMO is that a model for a single device/function may be needed = in another device that hosts many virtualised devices/functions of the = former type. We don=E2=80=99t have a good solution for this rather = typical situation. >>>>=20 >>>> But a single container called "whatever" provides no such = aggregation. >>>> You would need a list for that. And the NMS might have multiple >>>> layers of hierarchy to represent various aggregations. The NP >>>> container called "device" is not helpful for aggregation. >>>=20 >>> The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D = node would be like a mount point in a Unix filesystem. >>>=20 >>>=20 >>> Are you saying all data on a device needs to be in a top-level list = called 'device' >>> because an NMS might exist that wants to have the datastores from = lots of devices? >>> As Martin pointed out several times, the NMS can make its own = container or >>> lists. It does not need the device to mirror its own structure. >>=20 >> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevice=E2=80= =9D container. What would be really useful is to have the possibility to = do e.g. this: >>=20 >> virtual-node* [name] >> name >> if:interfaces >> ... >>=20 >> to support the use case where all virtual nodes are managed by the = same NETCONF/RESTCONF server. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>>=20 >>> Lada >>>=20 >>> Andy >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Lada >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka = wrote: >>>>>=20 >>>>>> On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> after listening to the presentation of >>>>>> draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am = wondering >>>>>> whether the solution chosen for Y34 is really useful. >>>>>>=20 >>>>>> The draft states they want to reuse ietf-interfaces but their = tree in >>>>>> fact is >>>>>>=20 >>>>>> +--rw device >>>>>> +--rw info >>>>>> | +--rw device-type? enumeration >>>>>> +--rw hardware >>>>>> +--rw interfaces >>>>>> | +--rw interface* [name] >>>>>> | ... >>>>>> +--rw qos >>>>>>=20 >>>>>> So the "interfaces" container is no more a top-level node. There = are >>>>>> three possible options: >>>>>>=20 >>>>>> 1. Change the ietf-interfaces module. >>>>>> 2. Replicate its contents in another module. >>>>>> 3. Extend YANG so that a *specific* schema tree can be grafted at = a >>>>>> given data node. >>>>>>=20 >>>>>> IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 = but it >>>>>> seems it is not so because it doesn't specify a concrete data = model >>>>>> that's allowed at a given location. >>>>>>=20 >>>>>> On the other hand, the only real contribution of "anydata" over = "anyxml" >>>>>> is that is doesn't permit mixed content in XML, which is IMO not = much. >>>>>>=20 >>>>>> I know Y34 was already closed but I think it is more important to = do >>>>>> things right before YANG 1.1 becomes an RFC. >>>>>>=20 >>>>>> What I want to propose is this: >>>>>>=20 >>>>>> - Rename "anydata" as a synonym to "anyxml", and deprecate = "anyxml" (but >>>>>> keep it for backward compatibility). >>>>>=20 >>>>> s/Rename/Introduce/ >>>>>=20 >>>>>>=20 >>>>>> - Introduce a new statement and data node type, e.g. "root", that = will >>>>>> extend the schema tree starting from that data node with a = precisely >>>>>> specified data model. The specification can be same or similar as >>>>>> in yang-library. >>>>>>=20 >>>>>> I believe there are other use cases in the existing modules. For >>>>>> example, the ietf-routing module could simply define the data = model for >>>>>> a single routing instance (i.e. without "routing-instance" list = at the >>>>>> top), and it can be then used without changes on simple devices, = and >>>>>> more complex router implementations can graft it as a subtree = under >>>>>> "routing-instance", "networking-instance" or whatever. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 21 00:44:36 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 F10EE1AD218 for ; Tue, 21 Jul 2015 00:44:34 -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 ag2xSsuY711S for ; Tue, 21 Jul 2015 00:44:32 -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 9554B1A8A82 for ; Tue, 21 Jul 2015 00:44:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D1044A14; Tue, 21 Jul 2015 09:44:29 +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 liTn-nusTtw7; Tue, 21 Jul 2015 09:44:28 +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, 21 Jul 2015 09:44:28 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E09D920037; Tue, 21 Jul 2015 09:44:29 +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 s82GMZXdzBeP; Tue, 21 Jul 2015 09:44:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61A5C20036; Tue, 21 Jul 2015 09:44:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5561335457FF; Tue, 21 Jul 2015 09:44:28 +0200 (CEST) Date: Tue, 21 Jul 2015 09:44:28 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150721074428.GC18607@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <4D704311-D5B7-43F3-BD23-C13D5289CF46@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: <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Tue, 21 Jul 2015 07:44:35 -0000 On Tue, Jul 21, 2015 at 09:16:46AM +0200, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 23:00, Juergen Schoenwaelder wrote: > > > > Lada, > > > > Y34 is closed and I have not seen any new argument here that indicates > > we made a major mistake with the resolution of Y34. As such, Y34 > > remains closed. > > Of course, I was expecting this reaction. I think I did present *some* arguments, and I am leaving it to others to judge whether they are relevant or not. Even if it was a minor mistake, it is IMO still worth fixing. > > > > > If you want to discuss new ideas to relocate or "symlink" data models, > > please do so in a separate thread. (And no, we do not accept new > > issues for YANG 1.1 either at this point in time.) > > It’s not about symlinks in the data tree but rather about a method for combining schemas that is complementary to “augment” - pull versus push. > > There is sufficient evidence that it was one of the use cases for “anydata”, e.g. in configlets. The gap in “anydata” definition for similar use cases is that it cannot specify a schema for its contents. > Lada, you can't simply 'mount' a data model into a different place. Think about paths in must or when expressions, or think about paths contraints in leafrefs etc. And Y34 was not trying to solve this problem, so this discussion is IMHO under a misleading subject line. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 21 02:21:25 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 7769E1A1A7D for ; Tue, 21 Jul 2015 02:21:23 -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 N5d53YPnpoI7 for ; Tue, 21 Jul 2015 02:21:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17FE1A1A57 for ; Tue, 21 Jul 2015 02:21:21 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:1a:249c:825e:9faf] (unknown [IPv6:2001:67c:370:176:1a:249c:825e:9faf]) by mail.nic.cz (Postfix) with ESMTPSA id 88429180ECA; Tue, 21 Jul 2015 11:21:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437470479; bh=QoA515Pmk/8fTFr99XgneTcVqji/9K715d2Lyg604sE=; h=From:Date:To; b=me6mAlnWU+iUsQAWkP+Io7E3FX11DAPN7QO+OAUDKE2o9/nIx85TXsTUbs2jsvk5a 9y+yi7gg5W2xP8tWKWm+Ee1O6VbAFad+zKsXjoiKf+PyrShX45CHLdanr9mJTgzpUV cjBkWL1szykT5d4q5rgWq16USUG8meVbQAiOhR3w= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150721074428.GC18607@elstar.local> Date: Tue, 21 Jul 2015 11:21:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6ECE8AED-0C40-43AF-A90F-779D8DC2CDA7@nic.cz> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> <20150721074428.GC18607@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Tue, 21 Jul 2015 09:21:23 -0000 > On 21 Jul 2015, at 09:44, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jul 21, 2015 at 09:16:46AM +0200, Ladislav Lhotka wrote: >>=20 >>> On 20 Jul 2015, at 23:00, Juergen Schoenwaelder = wrote: >>>=20 >>> Lada, >>>=20 >>> Y34 is closed and I have not seen any new argument here that = indicates >>> we made a major mistake with the resolution of Y34. As such, Y34 >>> remains closed. >>=20 >> Of course, I was expecting this reaction. I think I did present = *some* arguments, and I am leaving it to others to judge whether they = are relevant or not. Even if it was a minor mistake, it is IMO still = worth fixing. >>=20 >>>=20 >>> If you want to discuss new ideas to relocate or "symlink" data = models, >>> please do so in a separate thread. (And no, we do not accept new >>> issues for YANG 1.1 either at this point in time.) >>=20 >> It=E2=80=99s not about symlinks in the data tree but rather about a = method for combining schemas that is complementary to =E2=80=9Caugment=E2=80= =9D - pull versus push. >>=20 >> There is sufficient evidence that it was one of the use cases for = =E2=80=9Canydata=E2=80=9D, e.g. in configlets. The gap in =E2=80=9Canydata= =E2=80=9D definition for similar use cases is that it cannot specify a = schema for its contents. >>=20 >=20 > Lada, you can't simply 'mount' a data model into a different place. > Think about paths in must or when expressions, or think about paths > contraints in leafrefs etc. And Y34 was not trying to solve this This is a fair point but =E2=80=9Canydata=E2=80=9D where the schema is = supplied somehow out of band faces the same issue. Lada > problem, so this discussion is IMHO under a misleading subject line. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 21 02:57:29 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 D735D1B2CDB for ; Tue, 21 Jul 2015 02:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 loAhJrWHpqwc for ; Tue, 21 Jul 2015 02:57:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDB01B2CD8 for ; Tue, 21 Jul 2015 02:57:25 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.219.17; Tue, 21 Jul 2015 09:57:08 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.137]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.137]) with mapi id 15.01.0219.018; Tue, 21 Jul 2015 09:57:07 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] Agenda posted for IETF 93 meeting Thread-Index: AQHQwG0sspG/PexnTUKSzdxkngTaIJ3l19yA Date: Tue, 21 Jul 2015 09:57:07 +0000 Message-ID: References: In-Reply-To: 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: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:m4rmzRjqlDk1cYtPIOmqW7LMpmrU9XgL3XmFNHSBCBWJnW67bVBu2VxI/lDTpz0BcBPcw/dNZbOKvmPglRAtkiT80yNbzwQhmt8VqXg+S1yvgbpNgX/RYi2iSusDWRkehJI+P7EBW7XEs+WNruEQoQ==; 24:z6URv2d3E4jxcJjovMWs8+SLPCZu7afe3ohWvGXJv0fkpJnfrvR+5MaxyBGw7wNCWGzp3Bk/utiFDyep9wlNdYRvH92CNdY2TWa9h58flxM=; 20:Q2TgmHhBSXlyHrKXvwKv9vuWbT+arEyqOIadkOhIqJddmSb2XuWcdyrVYlzEHNSOGSSB9GDu7c9zlXXNlK2CLQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; bn1pr05mb453: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(19580405001)(110136002)(5002640100001)(106116001)(5001960100002)(36756003)(122556002)(19580395003)(40100003)(189998001)(66066001)(107886002)(99286002)(2501003)(4001350100001)(2351001)(5001920100001)(19617315012)(2900100001)(92566002)(76176999)(54356999)(50986999)(16236675004)(15975445007)(46102003)(102836002)(2656002)(450100001)(2950100001)(86362001)(62966003)(87936001)(77156002)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1D3E277C17CFkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2015 09:57:07.5181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Subject: Re: [netmod] Agenda posted for IETF 93 meeting 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: Tue, 21 Jul 2015 09:57:28 -0000 --_000_D1D3E277C17CFkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, the agenda for today's meeting has been updated. The update is as fol= lows: * 10 min: draft-bjorklund-netmod-openconfig-reply-00 (Juergen Schoenwaeld= er) Thanks, Kent From: Kent Watsen > Date: Friday, July 17, 2015 at 10:47 AM To: "netmod@ietf.org" > Subject: Re: [netmod] Agenda posted for IETF 93 meeting All, the agenda has been updated as follows: 1. Pravin Gohite is now presenting draft-ietf-netmod-syslog-model-04 2. Added 5 minutes for draft-bogdanovic-netmod-yang-model-classification-= 03 3. Added 5 minutes for draft-wilton-netmod-intf-vlan-yang-00 4. Reordered Tuesday's presentations Presenters: - please send your slides to the chairs no later than the night before yo= ur presentation - Monday's schedule has no wiggle room, please adhere to your time alloca= tions! Thanks, Kent From: Kent Watsen > Date: Wednesday, July 15, 2015 at 4:05 PM To: "netmod@ietf.org" > Subject: [netmod] Agenda posted for IETF 93 meeting The preliminary agenda for the two NETMOD sessions has been posted here: https://www.ietf.org/proceedings/93/agenda/agenda-93-netmod Please note that a discussion regarding Open Config will not occur due to s= cheduling conflicts. Otherwise, please let us know if any adjustments are = needed. Thanks, Kent --_000_D1D3E277C17CFkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <2E5AB9321B912C4EA2B1320FD5FCC592@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

All, the agenda for today's meeting has been updated.  The update= is as follows:

  * 10 min: draft-bjorklund-netmod-openconfig-reply-00 (Juergen S= choenwaelder)

Thanks,
Kent

From: Kent Watsen <kwatsen@juniper.net>
Date: Friday, July 17, 2015 at 10:4= 7 AM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] Agenda posted= for IETF 93 meeting


All, the agenda has been updated as follo= ws:

  1. Pravin Gohite is now presenting=  draft-ietf-netmod-syslog-mod= el-04
  2. Added 5 minutes for draft-bogdanovic-netmod-yang-model-class= ification-03
  3. Added 5 minutes for &nbs= p;draft-wilton-netmod-intf-vlan-ya= ng-00
  4. Reordered Tuesday's p= resentations

Presenters: 
  - please send your slides to the chairs no later than the night befo= re your presentation
  - Monday's schedule has no wi= ggle room, please adhere to your time allocations!


Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, July 15, 2015 at 4= :05 PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] Agenda posted for= IETF 93 meeting


The preliminary agenda for the two NETMOD sessions has been posted her= e:


Please note that a discussion regarding Open Config will not occur due= to scheduling conflicts.  Otherwise, please let us know if any adjust= ments are needed.

Thanks,
Kent




 --_000_D1D3E277C17CFkwatsenjunipernet_-- From nobody Tue Jul 21 07:56: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 72A0E1B2D81 for ; Tue, 21 Jul 2015 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 8E-2a17Of7rE for ; Tue, 21 Jul 2015 07:56:51 -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 3572E1A8943 for ; Tue, 21 Jul 2015 07:56:51 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-84-55ae5db17f09 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.36.25217.1BD5EA55; Tue, 21 Jul 2015 16:56:49 +0200 (CEST) Received: from [159.107.96.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Jul 2015 16:56:48 +0200 Message-ID: <55AE5DB0.6060202@ericsson.com> Date: Tue, 21 Jul 2015 16:56:48 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "netmod@ietf.org" Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvje7G2HWhBidvSVrMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujM+fZ7IXzOCsOPjWrIGxi72LkZNDQsBE4tK3DVC2mMSFe+vZ uhi5OIQEjjJKrFt1hhHCWc0ocfzOBjaQKl4BbYnPB2ewgtgsAqoSCw6+YQGx2QSMJKb2nwez RQWiJKY+XscCUS8ocXLmEzBbREBdYubO9WBzhAVUJF4u/wYWZxbQkGidM5cdwpaX2P52DjOI LQQUf3jhL+sERr5ZSEbNQtIyC0nLAkbmVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBIXVw y2+rHYwHnzseYhTgYFTi4V2wfG2oEGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwrt6bZ39wisSmE1knnrvLl77gMN/88/qseDnnUMuXT2L/8bv+SVJoP2Op Gqd4LPVDhq+16dx0pkauqHepb7cUqlw2FPM/a7jujE3qmkfHXQtUGJ6tDfF4YcHhtXfTykuf 271ufnx5VTVPO+LUT677Gi9Pm561+mE25U21ytJoxhNTTy5WkgtRU2Ipzkg01GIuKk4EAO5a QnEKAgAA Archived-At: Subject: [netmod] Dual mode validators needed 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: Tue, 21 Jul 2015 14:56:57 -0000 Hello,
It must be possible to chose for validator tools whether I want to validate according to Y1.0 or Y1.1.
regards Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Tue Jul 21 08:27:19 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 675AE1A8954 for ; Tue, 21 Jul 2015 08:27:17 -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 7hjFxx6usUHb for ; Tue, 21 Jul 2015 08:27:15 -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 88A9F1A8A06 for ; Tue, 21 Jul 2015 08:26:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5116714B6; Tue, 21 Jul 2015 17:26:15 +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 va9GzXnD1m_n; Tue, 21 Jul 2015 17:26: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; Tue, 21 Jul 2015 17:26:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EE8420039; Tue, 21 Jul 2015 17:26:16 +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 1vvCPwXUHgoI; Tue, 21 Jul 2015 17:26:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43FD120036; Tue, 21 Jul 2015 17:26:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 111333545FC9; Tue, 21 Jul 2015 17:26:13 +0200 (CEST) Date: Tue, 21 Jul 2015 17:26:13 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20150721152613.GA19865@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <55AE5DB0.6060202@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AE5DB0.6060202@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Dual mode validators needed 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: Tue, 21 Jul 2015 15:27:17 -0000 On Tue, Jul 21, 2015 at 04:56:48PM +0200, Balazs Lengyel wrote: > Hello, > It must be possible to chose for validator tools whether I want to > validate according to Y1.0 or Y1.1. Why? A data model that says version 1.1 should be validated according to YANG 1.1 rules and a data model that says version 1 (or does not declare a version at all) will be validated according to YANG 1.0 rules. /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 Jul 22 09:29:44 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 9EA571ACE69 for ; Wed, 22 Jul 2015 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 FspNIBtAcKeF for ; Wed, 22 Jul 2015 09:29:35 -0700 (PDT) Received: from smtpdb7.aruba.it (smtpdb7.aruba.it [62.149.158.249]) by ietfa.amsl.com (Postfix) with ESMTP id 13F271B2A0E for ; Wed, 22 Jul 2015 09:27:58 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd03.ad.aruba.it with bizsmtp id vUTx1q01n2NEPrz01UTyJZ; Wed, 22 Jul 2015 18:27:58 +0200 Date: Wed, 22 Jul 2015 18:27:59 +0200 (CEST) From: Meetecho Team To: netmod@ietf.org Message-ID: <2105530421.9.1437582479339.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8_1397963743.1437582479334" Archived-At: Subject: [netmod] Meetecho recordings of NETMOD WG session 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, 22 Jul 2015 16:29:36 -0000 ------=_Part_8_1397963743.1437582479334 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the NETMOD WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#NETMOD In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_8_1397963743.1437582479334-- From nobody Wed Jul 22 09:41: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 B511B1A9026 for ; Wed, 22 Jul 2015 09:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 IzfafPV8Qdh1 for ; Wed, 22 Jul 2015 09:41:40 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 39CC11B2AA7 for ; Wed, 22 Jul 2015 09:41:06 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUh41q00R2NEPrz01Uh572; Wed, 22 Jul 2015 18:41:05 +0200 Date: Wed, 22 Jul 2015 18:41:05 +0200 (CEST) From: Meetecho Team To: netmod@ietf.org Message-ID: <1315968767.1.1437583265910.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_1756201167.1437583265871" Archived-At: Subject: [netmod] Meetecho recordings of NETMOD 2nd WG session 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, 22 Jul 2015 16:41:41 -0000 ------=_Part_0_1756201167.1437583265871 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the NETMOD 2nd WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#NETMOD_II In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_0_1756201167.1437583265871-- From nobody Thu Jul 23 02:06: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 F2F7B1A8992; Thu, 23 Jul 2015 02:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rB3eV1qC3tTS; Thu, 23 Jul 2015 02:05:57 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BF51A886D; Thu, 23 Jul 2015 02:05:57 -0700 (PDT) Received: from dhcp-b33f.meeting.ietf.org ([31.133.179.63]) by smtp-cloud6.xs4all.net with ESMTP id vl5s1q00Q1NTpLX01l5v92; Thu, 23 Jul 2015 11:05:56 +0200 Message-ID: <55B0AE71.8050203@bwijnen.net> Date: Thu, 23 Jul 2015 11:05:53 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: NETMOD Working Group , Netconf References: <55AF8FBB.1080607@bwijnen.net> <55AF90FD.1010305@bwijnen.net> In-Reply-To: <55AF90FD.1010305@bwijnen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Correction: bar-bof meeting on IBNEMO Thursday 20:00 in Budapest (LOBBY level) 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, 23 Jul 2015 09:05:59 -0000 My apologies, the Budapest room is NOT at the Mezzanine level, but at the LOBBY level. Bert On 22/07/15 14:47, Bert Wijnen (IETF) wrote: > A second side-bar (bar-bof) meeting of IBNEMO (Intent Based NEtwork MOdeling) meeting > will occur at 8pm (20:00) in the Budapest meeting room (mezzanine level). > > It also has discussions about the use of YANG, NETCONF and RESTCONF, > so I figure it is relevant to these WGs. > > If you can attend, please do. > > There is a mailing list at ibnemo@ietf.org > > Bert > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Sat Jul 25 01:25:18 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 672811AC3D4 for ; Sat, 25 Jul 2015 01:25: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 RBoKzO-o59el for ; Sat, 25 Jul 2015 01:25: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 228781A90EE for ; Sat, 25 Jul 2015 01:25:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1E23C170E for ; Sat, 25 Jul 2015 10: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 EFxXooKIwz4W for ; Sat, 25 Jul 2015 10:25: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 for ; Sat, 25 Jul 2015 10:25:06 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC4EC2003C for ; Sat, 25 Jul 2015 10:25:11 +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 PsylaC2XM8X0; Sat, 25 Jul 2015 10:25: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 1D68A20039; Sat, 25 Jul 2015 10:25:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B051B35DFBB4; Sat, 25 Jul 2015 10:25:08 +0200 (CEST) Date: Sat, 25 Jul 2015 10:25:07 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150725082507.GA14481@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] YANG 1.1 Y60 IETF 93 discussion summary and action items 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: Sat, 25 Jul 2015 08:25:16 -0000 This is the summary of the discussion of YANG 1.1 issue Y60 at the IETF 93 meeting in Prague: - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which will of course be interpreted according to the YANG 1.0 rules). - The YANG 1.1 RFC will not obsolete RFC 6020. (RFC 6020 may be retired when all published YANG 1.0 data models have been converted to YANG 1.1.) - The title should be made less NETCONF specific (and the same applies to the Abstract and the Introduction). This will not affect the NETCONF specific examples that are used throughout the text. - The IANA considerations text copied from RFC 6020 will be removed from the YANG 1.1 specification. - The IETF will not run a transition process to retire YANG 1.0; it is assumed that this will happen naturally anyway eventually. - The NETMOD WG recommends that the IETF will publish only YANG 1.1 modules as RFCs once the YANG 1.1 RFC has been published. Action items: - AB to check whether there are any loopholes. - JS to schedule virtual interim meetings to handle review comments. /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 Sat Jul 25 15:15:51 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 C698A1A1B15 for ; Sat, 25 Jul 2015 15:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 q1f_KPuWY4vb for ; Sat, 25 Jul 2015 15:15:47 -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 28D5B1A1B13 for ; Sat, 25 Jul 2015 15:15:47 -0700 (PDT) Received: by lagw2 with SMTP id w2so30903942lag.3 for ; Sat, 25 Jul 2015 15:15:45 -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=BhmgRv0GEe/ysh/aNPlIICr+RjCzRxvL/JM6wFjboJk=; b=fm7AgESmI+Ca/Rt8wqCj2uoaww8Yu8cn2/dN7Nuzo2hTmxAcgwqJkzzb3g3fwI3ljf RUCaXpMF71pmDk1l0allmpgbX1UBHXrtqWwP/wN+GWLZzmESHEHF5kKYkhWEp3FPiQwN ztxbPiHnDzaK2h35D3D6YoZAIF7SlhPdYNHTaQkw5CnLuiVLL+T/fBOMHCkaAHGW1FxV 4VAEIN/hSCZCgtjshe1urw9QMitI2Zj0l+hPu4g5gGJYOeZG2fXfqfuQUblrYVF27pOK N3+R6G8x9ZgzyftarIOBnvw0r6VrahAUtUaFDrcJLr3QgSsGZpP3lWrD1VNX/IoQJBkh b+nw== X-Gm-Message-State: ALoCoQmraq3LeoCV+Q9SH2BJQP4sEzwMP2FKjr82Dw59VFCbpNh7/SGoPVTk9ko30obaefbfj4AA MIME-Version: 1.0 X-Received: by 10.152.116.39 with SMTP id jt7mr19755607lab.82.1437862545479; Sat, 25 Jul 2015 15:15:45 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 25 Jul 2015 15:15:45 -0700 (PDT) In-Reply-To: <20150725082507.GA14481@elstar.local> References: <20150725082507.GA14481@elstar.local> Date: Sat, 25 Jul 2015 15:15:45 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36592427183051bba761b Archived-At: Subject: Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items 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: Sat, 25 Jul 2015 22:15:50 -0000 --001a11c36592427183051bba761b Content-Type: text/plain; charset=UTF-8 On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > This is the summary of the discussion of YANG 1.1 issue Y60 at the > IETF 93 meeting in Prague: > > - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which > will of course be interpreted according to the YANG 1.0 rules). > > I am not convinced this will be a good idea. Obviously the compiler has to restrict 1.0 modules to 1.0 syntax, but the corner-case semantics that have been clarified in 1.1 SHOULD be followed if a 1.1 module imports 1.0, even for augment. > - The YANG 1.1 RFC will not obsolete RFC 6020. (RFC 6020 may be > retired when all published YANG 1.0 data models have been > converted to YANG 1.1.) > > - The title should be made less NETCONF specific (and the same > applies to the Abstract and the Introduction). This will not > affect the NETCONF specific examples that are used throughout > the text. > If this is the case then I think the "restconf-media-type" hack should be a real YANG statement. The reason it is an extension is because YANG is NETCONF-only. A real statement could support augments and deviations. Just removing a sentence from the abstract is not going to fix all NETCONF-specific details in YANG. (Just ask Lada ;-) It is not going to make YANG correct for RESTCONF. YANG will need to be modified for I2RS anyway. YANG 1.1 took too long, and now I2RS is ready. I strongly object to the idea of starting on 1.2 while 1.1 is still unpublished. > - The IANA considerations text copied from RFC 6020 will be removed > from the YANG 1.1 specification. > Does this mean that YANG 1.1 will have a normative reference to RFC 6020? Or are the references to the IANA registries? > > - The IETF will not run a transition process to retire YANG 1.0; it > is assumed that this will happen naturally anyway eventually. > If import-without-revision is used in a 1.0 module, and both 1.0 and 1.1 revisions exist of the imported module, a compiler (and server) have to make sure the default revision a YANG 1.0 revision. > - The NETMOD WG recommends that the IETF will publish only YANG 1.1 > modules as RFCs once the YANG 1.1 RFC has been published. > > Action items: > > - AB to check whether there are any loopholes. > - JS to schedule virtual interim meetings to handle review comments. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c36592427183051bba761b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
This is the summary of the discussion of YANG 1.1 is= sue Y60 at the
IETF 93 meeting in Prague:

=C2=A0- It is OK for a YANG 1.1 module to import a YANG 1.0 module (which =C2=A0 =C2=A0will of course be interpreted according to the YANG 1.0 rules)= .



I am not convinced this= will be a good idea.
Obviously the compiler has to restrict 1.0 = modules to 1.0 syntax,
but the corner-case semantics that have be= en clarified in 1.1
SHOULD be followed if a 1.1 module imports 1.= 0, even for augment.


=C2=A0
=C2=A0- The YANG 1.1 RFC will not obsolete RFC 6020. (RFC 6020 may be
=C2=A0 =C2=A0retired when all published YANG 1.0 data models have been
=C2=A0 =C2=A0converted to YANG 1.1.)

=C2=A0- The title should be made less NETCONF specific (and the same
=C2=A0 =C2=A0applies to the Abstract and the Introduction). This will not =C2=A0 =C2=A0affect the NETCONF specific examples that are used throughout<= br> =C2=A0 =C2=A0the text.


I= f this is the case then I think the "restconf-media-type" hack
should be a real YANG statement.=C2=A0 The reason it is an extensio= n
is because YANG is NETCONF-only.=C2=A0 A real statement
could support augments and deviations.

Just rem= oving a sentence from the abstract is not going to fix all
NETCON= F-specific details in YANG. =C2=A0(Just ask Lada ;-) =C2=A0It is
= not going to make YANG correct for RESTCONF.

YANG = will need to be modified for I2RS anyway.=C2=A0 YANG 1.1 took
too= long, and now I2RS is ready.=C2=A0 I strongly object to the idea
of starting on 1.2 while 1.1 is still unpublished.




=C2=A0- The IANA considerations text copied from RFC 6020 will be removed =C2=A0 =C2=A0from the YANG 1.1 specification.


Does this mean that YANG 1.1 will have a normative re= ference to RFC 6020?
Or are the references to the IANA registries= ?


=C2=A0

=C2=A0- The IETF will not run a transition process to retire YANG 1.0; it =C2=A0 =C2=A0is assumed that this will happen naturally anyway eventually.<= br>


If import-without-revisi= on is used in a 1.0 module, and both 1.0 and 1.1
revisions exist = of the imported module, a compiler (and server)
have to make sure= the default revision a YANG 1.0 revision.



=C2=A0- The NETMOD WG recommends that the IETF will publish only YANG 1.1 =C2=A0 =C2=A0modules as RFCs once the YANG 1.1 RFC has been published.

Action items:

=C2=A0- AB to check whether there are any loopholes.
=C2=A0- JS to schedule virtual interim meetings to handle review comments.<= br>
/js


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

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

--001a11c36592427183051bba761b-- From nobody Sat Jul 25 17:17:16 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 547AE1A8AC7 for ; Sat, 25 Jul 2015 17:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Gh8pr2VI4uRT for ; Sat, 25 Jul 2015 17:17:13 -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 069D61A8AC5 for ; Sat, 25 Jul 2015 17:17:13 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so33827745lbb.3 for ; Sat, 25 Jul 2015 17:17: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:date:message-id:subject:from:to :content-type; bh=e1jPXLCMD1Qbx6f8n+4XePA+ar1j/UE6dctCEtCJ9ck=; b=FgBDJ78tS3XRQYtRQY/4OuQi9jOl5CXnDjlrEWywUHZ0y3U9/cQFNh0+0BKS476byg xmaME7++2xEAd32qKGfbt73Zi057HaUoA7B7JMoNl1bNjVK+PKO49IieE1RVlIExfVox blT203c6RiOPmvwBzdoUnI5gMU85JmGriS5ywHmUCQDrYj3Qg0hQZx+UfhL/f9+XlSP1 Z1z7wn5ABBtEB5VmrquBI3oe63xceYFlT3bOxBtNqVBFhmnozzdPN+Y2RmGp8nWwtQbg h6NaQcTX81y/ApXPjOa+KL+ieEa2Z8ktc8AbIVQtO3usVLGSFwPYvx+LLU0iNZZ81Fuk 7CPg== X-Gm-Message-State: ALoCoQlLYXBItkqKMEtr8Jo4eVObu1g2yT7jYkST8Evzrh+r00b9rHPOmc7IkY+CdbSSghbAc2Qk MIME-Version: 1.0 X-Received: by 10.112.155.164 with SMTP id vx4mr20242429lbb.38.1437869831218; Sat, 25 Jul 2015 17:17:11 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 25 Jul 2015 17:17:11 -0700 (PDT) Date: Sat, 25 Jul 2015 17:17:11 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e01228a9285fdc9051bbc282b Archived-At: Subject: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 00:17:14 -0000 --089e01228a9285fdc9051bbc282b Content-Type: text/plain; charset=UTF-8 Hi, I would like to open another issue for YANG 1.1, because I don't want to have 1.1 and then 1.2 right away. The NETMOD WG should evaluate the different ways to support ephemeral state, based on Jeff's draft. Andy --089e01228a9285fdc9051bbc282b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I would like to open another issue = for YANG 1.1,
because I don't want to have 1.1 and then 1.2 r= ight away.
The NETMOD WG should evaluate the different ways to
support ephemeral state, based on Jeff's draft.

<= /div>

Andy

--089e01228a9285fdc9051bbc282b-- From nobody Sat Jul 25 17:26:20 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 EFBB41A8AF5 for ; Sat, 25 Jul 2015 17:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GdNW-bfKc1IH for ; Sat, 25 Jul 2015 17:26:18 -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 A471A1A8AEC for ; Sat, 25 Jul 2015 17:26:17 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so33974415lbb.0 for ; Sat, 25 Jul 2015 17:26:16 -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:date:message-id:subject:from:to :content-type; bh=sJTDgO614Vduauml/y2b8b5zPtW5X70PJTnvXjzRb2Q=; b=S8lRdPhpHI4GBucnz1nDGf0rDS4JGqGqln7yI2ZSdDvuW+wbJF1M1Ax4x71FlfKg4A UGWG1ELCfm2naModxvIgyWY+GksbnVM0WGmVvYhqYeF+5387ZS/eKEB3zqltTwBjy0PM /DA+tv6YVr7kw6c3bfHFoIrvaUCkHinZUw+9Q/hULLjDsiNLL0qRGqLiFcFoh4KMgvhf /x7PqKFJXTz9TY3/P2opRZtWzYQIAxk7JN0jZ7UlswhEMDGGsniSloI2CwuQ28H4xQfM GIb2Uiw06lZnjZrv64rBVTk1Jo6JybfD5u92XsIP3ypNOHNTfXhWDcIBcg6C9ZOCr0nV k0vg== X-Gm-Message-State: ALoCoQnG9jZRi5eVhDn3XtYhIkQNFDoWMqc5fteFFEqI8iaekacvYINETKXzdElNFyCNRfqDTCRr MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr20388564lbl.123.1437870376202; Sat, 25 Jul 2015 17:26:16 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 25 Jul 2015 17:26:16 -0700 (PDT) Date: Sat, 25 Jul 2015 17:26:16 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11346d9c01ca39051bbc49db Archived-At: Subject: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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: Sun, 26 Jul 2015 00:26:19 -0000 --001a11346d9c01ca39051bbc49db Content-Type: text/plain; charset=UTF-8 Hi, The WG should decide what it means for YANG to not be NETCONF-specific. Why does YANG define extensions to NETCONF operations (like insert)? IMO the normative text about NETCONF should not be in the YANG RFC. Andy --001a11346d9c01ca39051bbc49db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The WG should decide what it means = for YANG to not
be NETCONF-specific.=C2=A0 Why does YANG define e= xtensions
to NETCONF operations (like insert)? IMO the normative = text
about NETCONF should not be in the YANG RFC.

<= /div>

Andy



<= /div>

--001a11346d9c01ca39051bbc49db-- From nobody Sun Jul 26 00:09:28 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 F26AA1ABB19 for ; Sun, 26 Jul 2015 00:09: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 ELG5crdL7nCz for ; Sun, 26 Jul 2015 00:09: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 C7E6D1A001C for ; Sun, 26 Jul 2015 00:09: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 04D3113E0; Sun, 26 Jul 2015 09:09: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 P3UTCvZtdxTZ; Sun, 26 Jul 2015 09:09: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; Sun, 26 Jul 2015 09:09:17 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9524A20039; Sun, 26 Jul 2015 09:09:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GoLb7CPlbShf; Sun, 26 Jul 2015 09:09: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 646012003A; Sun, 26 Jul 2015 09:09:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E0FA735DFF67; Sun, 26 Jul 2015 09:09:20 +0200 (CEST) Date: Sun, 26 Jul 2015 09:09:19 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150726070919.GA16276@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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: Sun, 26 Jul 2015 07:09:28 -0000 On Sat, Jul 25, 2015 at 05:26:16PM -0700, Andy Bierman wrote: > Hi, > > The WG should decide what it means for YANG to not > be NETCONF-specific. Why does YANG define extensions > to NETCONF operations (like insert)? IMO the normative text > about NETCONF should not be in the YANG RFC. > So what is your proposal? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 00:16:29 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 57D901ACD36 for ; Sun, 26 Jul 2015 00:16:28 -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 0xcF28bmjELZ for ; Sun, 26 Jul 2015 00:16: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 ED6D11ACD10 for ; Sun, 26 Jul 2015 00:16: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 7342A13F9; Sun, 26 Jul 2015 09:16:19 +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 p0vonpBosGhI; Sun, 26 Jul 2015 09:16: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; Sun, 26 Jul 2015 09:16:18 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D7F72003A; Sun, 26 Jul 2015 09:16:24 +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 ve2KrWWonJEt; Sun, 26 Jul 2015 09:16: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 3320520039; Sun, 26 Jul 2015 09:16:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2016B35DFFB3; Sun, 26 Jul 2015 09:16:23 +0200 (CEST) Date: Sun, 26 Jul 2015 09:16:23 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150726071623.GB16276@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 07:16:28 -0000 On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > Hi, > > I would like to open another issue for YANG 1.1, > because I don't want to have 1.1 and then 1.2 right away. > The NETMOD WG should evaluate the different ways to > support ephemeral state, based on Jeff's draft. > The NETMOD WG did spent almost a full day face-to-face interim meeting time in September 2014 on this and now we have a requirements I-D plus a solution proposal that does not directly match what was discussed back then. It is my understanding that the solution discussed in September 2014 does not require changes to YANG 1.1. I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG 1.1 is gating other specifications and I am not interested to hold everything off (including RESTCONF) because of I2RS. There are many other customers of YANG 1.1 beyond I2RS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 00:22:20 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 A62631ACDE1 for ; Sun, 26 Jul 2015 00:22:18 -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 iMsvB1czsnoj for ; Sun, 26 Jul 2015 00:22:17 -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 EE51E1ACDD8 for ; Sun, 26 Jul 2015 00:22:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75F3E12E0; Sun, 26 Jul 2015 09:22:09 +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 E0FKeUbU6ahU; Sun, 26 Jul 2015 09:22: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; Sun, 26 Jul 2015 09:22:08 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 595C82003A; Sun, 26 Jul 2015 09:22:14 +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 wAk5bK-ieye9; Sun, 26 Jul 2015 09:22:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91A6D20039; Sun, 26 Jul 2015 09:22:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 97DCD35E0031; Sun, 26 Jul 2015 09:22:10 +0200 (CEST) Date: Sun, 26 Jul 2015 09:22:10 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150726072210.GC16276@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150725082507.GA14481@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items 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: Sun, 26 Jul 2015 07:22:18 -0000 On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bierman wrote: > On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > This is the summary of the discussion of YANG 1.1 issue Y60 at the > > IETF 93 meeting in Prague: > > > > - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which > > will of course be interpreted according to the YANG 1.0 rules). > > I am not convinced this will be a good idea. > Obviously the compiler has to restrict 1.0 modules to 1.0 syntax, > but the corner-case semantics that have been clarified in 1.1 > SHOULD be followed if a 1.1 module imports 1.0, even for augment. > Please provide concrete examples what breaks if we allow to import YANG 1.0 modules (using 1.0 semantics). > If this is the case then I think the "restconf-media-type" hack > should be a real YANG statement. The reason it is an extension > is because YANG is NETCONF-only. A real statement > could support augments and deviations. > > Just removing a sentence from the abstract is not going to fix all > NETCONF-specific details in YANG. (Just ask Lada ;-) It is > not going to make YANG correct for RESTCONF. Please provide concrete examples where YANG is incorrect for RESTCONF. > YANG will need to be modified for I2RS anyway. YANG 1.1 took > too long, and now I2RS is ready. I strongly object to the idea > of starting on 1.2 while 1.1 is still unpublished. Nobody proposed to work on YANG 1.2. > > - The IANA considerations text copied from RFC 6020 will be removed > > from the YANG 1.1 specification. > > Does this mean that YANG 1.1 will have a normative reference to RFC 6020? > Or are the references to the IANA registries? Joel (AD) said this will all be OK. I had my doubts but he said it is no problem since the registry now exists and won't go away anyway even if RFC 6020 goes historic. Please check the recording. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 03:46:26 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 3D16D1B2AEA for ; Sun, 26 Jul 2015 03:46: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 KeVk0EYl1yqV for ; Sun, 26 Jul 2015 03:46:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACC61B2AED for ; Sun, 26 Jul 2015 03:46:23 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id A4304181524; Sun, 26 Jul 2015 12:46:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437907581; bh=Ut8ZlcwxuQX9L32F+/Xtmt3Vxsk0GnqbyOHRCq6WYmM=; h=From:Date:To; b=sHrFB7DcB5MHbnxgmfACHsT1btGKVFI3et96exvDOFKr5KpF0eaZ1lOUcTt9QuPjh li6bBzKis5uPYSewnJKoE2dMgWuV6w3BLYlHor9q/hdoThI1UDzfO8OpRLXIyzHA3J PFsDQolzWA2dDThtS1gpLPxxVUyltBfB/1WawTYQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 26 Jul 2015 12:46:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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: Sun, 26 Jul 2015 10:46:25 -0000 > On 26 Jul 2015, at 02:26, Andy Bierman wrote: >=20 > Hi, >=20 > The WG should decide what it means for YANG to not > be NETCONF-specific. Why does YANG define extensions > to NETCONF operations (like insert)? IMO the normative text > about NETCONF should not be in the YANG RFC. >=20 This is essentially what I proposed in Berlin (IETF 87): http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod (first item in Open mike section). Another thing that I realized only recently is that some properties that = are inherent to the conceptual data tree are defined in =E2=80=9CXML = Mapping=E2=80=9D sections. I think most YANG concepts and statements can be defined in terms of = data tree properties. Separate documents would then define different = encodings, and =E2=80=9Cprofiles=E2=80=9D for management protocols. It would need massive changes in 6020bis text though. Lada >=20 > Andy >=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 Sun Jul 26 03:53: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 936681B2AFE for ; Sun, 26 Jul 2015 03:53:44 -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 MMChFh1afM_G for ; Sun, 26 Jul 2015 03:53:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08D71B2AF9 for ; Sun, 26 Jul 2015 03:53:42 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 9518C1813CD; Sun, 26 Jul 2015 12:53:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437908021; bh=bUUdEyQbUbaIy7zwOr3829lW+9eN/JtEJvKp/19BI4E=; h=From:Date:To; b=j9t7OYke48B39ez8NGhN1TOY9Ojn0bt5TYprveSOoMINJI23LUgyKvgjMvr6oiFD4 72/nqQXOOS4cvpdhdU1hJZdyD9EDsBv62GWjDPrej/eM3t41OGCNo+2sEXaAfLBoGJ aUWQAjvxctCe6B4hpPtYHbt4/7XXmMHN3KZh8xSk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 26 Jul 2015 12:53:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62C65CD0-4901-43C6-8796-74AEC8BFAE89@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 10:53:44 -0000 > On 26 Jul 2015, at 02:17, Andy Bierman wrote: >=20 > Hi, >=20 > I would like to open another issue for YANG 1.1, > because I don't want to have 1.1 and then 1.2 right away. > The NETMOD WG should evaluate the different ways to > support ephemeral state, based on Jeff's draft. Rather than implementing ephemeral data, I=E2=80=99d actually prefer to = consider it a subproblem of making YANG less NETCONF-specific: YANG = would deal only with data trees, and it would be up to each management = protocol profile to define what trees the protocol uses and what is = their semantics. What might be a new task for YANG is to define general syntax for = identifying different trees and inter-tree references. Lada=20 >=20 >=20 > Andy >=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 Sun Jul 26 03:55:26 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 69FB11B2ADC for ; Sun, 26 Jul 2015 03:55:24 -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 uQ7XAO1m1YMm for ; Sun, 26 Jul 2015 03:55: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 9CA3F1A9029 for ; Sun, 26 Jul 2015 03:55: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 F37B9FE6; Sun, 26 Jul 2015 12:55:13 +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 Df77stRHo6pH; Sun, 26 Jul 2015 12:55:13 +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 Jul 2015 12:55:13 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D8532003A; Sun, 26 Jul 2015 12:55:19 +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 YviHBkCf0ONn; Sun, 26 Jul 2015 12:55:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 068A520039; Sun, 26 Jul 2015 12:55:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5834535E0413; Sun, 26 Jul 2015 12:55:16 +0200 (CEST) Date: Sun, 26 Jul 2015 12:55:15 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150726105515.GA16978@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <7864CE12-9C25-4681-A76E-E3B24062A42F@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: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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: Sun, 26 Jul 2015 10:55:24 -0000 Any are concrete actionable proposals? /js On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: > > > On 26 Jul 2015, at 02:26, Andy Bierman wrote: > > > > Hi, > > > > The WG should decide what it means for YANG to not > > be NETCONF-specific. Why does YANG define extensions > > to NETCONF operations (like insert)? IMO the normative text > > about NETCONF should not be in the YANG RFC. > > > > This is essentially what I proposed in Berlin (IETF 87): > > http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod > > (first item in Open mike section). > > Another thing that I realized only recently is that some properties that are inherent to the conceptual data tree are defined in “XML Mapping” sections. > > I think most YANG concepts and statements can be defined in terms of data tree properties. Separate documents would then define different encodings, and “profiles” for management protocols. > > It would need massive changes in 6020bis text though. > > Lada > > > > > Andy > > > > > > > > > > _______________________________________________ > > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 03:56:23 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 E93281B2B00 for ; Sun, 26 Jul 2015 03:56:21 -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 PHPQpZQSAoOm for ; Sun, 26 Jul 2015 03:56: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 B54421B2ADC for ; Sun, 26 Jul 2015 03:56: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 120E48E6; Sun, 26 Jul 2015 12:56:13 +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 lwpP23z39dXV; Sun, 26 Jul 2015 12: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; Sun, 26 Jul 2015 12:56:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9B512003A; Sun, 26 Jul 2015 12:56:18 +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 uYNePLCG1OCj; Sun, 26 Jul 2015 12:56:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A45B20039; Sun, 26 Jul 2015 12:56:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C529935E0446; Sun, 26 Jul 2015 12:56:16 +0200 (CEST) Date: Sun, 26 Jul 2015 12:56:16 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150726105616.GB16978@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <62C65CD0-4901-43C6-8796-74AEC8BFAE89@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62C65CD0-4901-43C6-8796-74AEC8BFAE89@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 10:56:22 -0000 On Sun, Jul 26, 2015 at 12:53:41PM +0200, Ladislav Lhotka wrote: > > What might be a new task for YANG is to define general syntax for identifying different trees and inter-tree references. > This is not the time to add new features to 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 Sun Jul 26 04:06:58 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 4D57A1B2B1B for ; Sun, 26 Jul 2015 04:06:57 -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 x4v6Trb-8PBV for ; Sun, 26 Jul 2015 04:06:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177151B2B00 for ; Sun, 26 Jul 2015 04:06:56 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:85de:cde6:4a51:37c5] (unknown [IPv6:2a01:5e0:29:ffff:85de:cde6:4a51:37c5]) by mail.nic.cz (Postfix) with ESMTPSA id AECA318146D; Sun, 26 Jul 2015 13:06:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1437908814; bh=QU0AmnA6vhp0Gt/zQ9AItcpIYT0be3TCPceI1I6HkVQ=; h=From:Date:To; b=wQ3DB+P2Qg7rpHvZVFmYOICob2PKLX3dBYcnwWYDHXZw6y+aEqv47in6yQYgAAQIj BmqkR85lgIzuUL+Ojd6LCDubKZxnnDu06VhyTyptvS+9yvRO6ZISoh2yX4ucdmvBn+ BIWUPhar/4DW8l27/9odojPqagCUV02IZ5wsnz+k= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150726105515.GA16978@elstar.local> Date: Sun, 26 Jul 2015 13:06:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D8E54C3-9CC1-4616-9D9D-3111ED0224FC@nic.cz> References: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> <20150726105515.GA16978@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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: Sun, 26 Jul 2015 11:06:57 -0000 > On 26 Jul 2015, at 12:55, Juergen Schoenwaelder = wrote: >=20 > Any are concrete actionable proposals? Start rewriting 6020bis, but only if we decide to go that way - it is a = difficult decision. I will be slightly in favor of doing so. Lada >=20 > /js >=20 > On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 26 Jul 2015, at 02:26, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>> The WG should decide what it means for YANG to not >>> be NETCONF-specific. Why does YANG define extensions >>> to NETCONF operations (like insert)? IMO the normative text >>> about NETCONF should not be in the YANG RFC. >>>=20 >>=20 >> This is essentially what I proposed in Berlin (IETF 87): >>=20 >> http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod >>=20 >> (first item in Open mike section). >>=20 >> Another thing that I realized only recently is that some properties = that are inherent to the conceptual data tree are defined in =E2=80=9CXML = Mapping=E2=80=9D sections. >>=20 >> I think most YANG concepts and statements can be defined in terms of = data tree properties. Separate documents would then define different = encodings, and =E2=80=9Cprofiles=E2=80=9D for management protocols. >>=20 >> It would need massive changes in 6020bis text though. >>=20 >> Lada >>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Jul 26 04:17:32 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 14E5C1B2B2C for ; Sun, 26 Jul 2015 04:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 XsYWkOtsupJo for ; Sun, 26 Jul 2015 04:17:29 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 6B64B1B2B2E for ; Sun, 26 Jul 2015 04:17:28 -0700 (PDT) Received: by lblf12 with SMTP id f12so37907478lbl.2 for ; Sun, 26 Jul 2015 04:17:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=slVVj8K97msT86r+ZtMoRTuv56cc+OBJk98uU9obn7Q=; b=HNnx5/Sx5mGuZAwwMfy0EEAZo3JFuBs4L7VHDCkWEUiFQr8Cn7TDOV19zrjLTzBnbZ MITi1VzTmdC9EumcbD54Mi7lrHTt+e8zYlrWPbO8nM9uEO2Z3Wu/yR3MbeV06ECmwVZa eY0NXlp6JGUdrQMlnxqf5gwd9Uk6d4/A2TG6E3OAZhCJkoROmKiallsmsxFQpiQ8WOOF xG7yX62cNDIRVQmd5Hp6ve3NEB7r047aUODLR1vBc8rUji0eBCm5JbXyqwohUGG1lJxB KSevTRH0xu21WoJiS0BRTOR9zRc6KcrI584U7ZPEkOsRzkE3PwKzK+dTGa+D7SzVrkZ1 k18w== X-Gm-Message-State: ALoCoQmj4XZyViTVsIo4YUXIgGn1pkca0l13etNFMoASlmbp6Z+msuBkfeIjUzl4ru/LE0N6NbIE MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr21953321lab.38.1437909446720; Sun, 26 Jul 2015 04:17:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 04:17:26 -0700 (PDT) In-Reply-To: <20150726071623.GB16276@elstar.local> References: <20150726071623.GB16276@elstar.local> Date: Sun, 26 Jul 2015 04:17:26 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e01176905ca9754051bc56142 Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 11:17:31 -0000 --089e01176905ca9754051bc56142 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > Hi, > > > > I would like to open another issue for YANG 1.1, > > because I don't want to have 1.1 and then 1.2 right away. > > The NETMOD WG should evaluate the different ways to > > support ephemeral state, based on Jeff's draft. > > > > The NETMOD WG did spent almost a full day face-to-face interim meeting > time in September 2014 on this and now we have a requirements I-D plus > a solution proposal that does not directly match what was discussed > back then. It is my understanding that the solution discussed in > September 2014 does not require changes to YANG 1.1. > > I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG > 1.1 is gating other specifications and I am not interested to hold > everything off (including RESTCONF) because of I2RS. There are many > other customers of YANG 1.1 beyond I2RS. > > Yeah, it's too bad so many drafts are waiting on YANG. Support for I2RS got started but never finished. I care more about the costs of deploying tools and the extra complexity on readers, who need to know all the versions of YANG. The proposed solution changes one of the most important statments in YANG. Harding something to do as an afterthought. It should not take that long because the NETCONF WG (same people) have been spending almost all f2f and virtual interim time on I2RS. The YANG doctors concluded that ephemeral state was a general feature and not NETCONF specific. The problem with using YANG extensions for important protocol features is that the YANG spec says these statements MAY be completely skipped by a tool implementation. This is not acceptable for ephemeral state (or operational state either). /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e01176905ca9754051bc56142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bier= man wrote:
> Hi,
>
> I would like to open another issue for YANG 1.1,
> because I don't want to have 1.1 and then 1.2 right away.
> The NETMOD WG should evaluate the different ways to
> support ephemeral state, based on Jeff's draft.
>

The NETMOD WG did spent almost a full day face-to-face interim meeting
time in September 2014 on this and now we have a requirements I-D plus
a solution proposal that does not directly match what was discussed
back then. It is my understanding that the solution discussed in
September 2014 does not require changes to YANG 1.1.

I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG
1.1 is gating other specifications and I am not interested to hold
everything off (including RESTCONF) because of I2RS. There are many
other customers of YANG 1.1 beyond I2RS.



Yeah, it's too bad so many drafts= are waiting on YANG.
Support for I2RS got started but never fini= shed.
I care more about the costs of deploying tools and the extr= a complexity
on readers, who need to know all the versions of YAN= G.
The proposed solution changes one of the most important statme= nts
in YANG.=C2=A0 Harding something to do as an afterthought.

It should not take that long because the NETCONF WG = (same people)
have been spending almost all f2f and virtual inter= im time on I2RS.
The YANG doctors concluded that ephemeral state<= /div>
was a general feature and not NETCONF specific.

The problem with using YANG extensions for important protocol featu= res
is that the YANG spec says these statements MAY be completely= skipped
by a tool implementation.=C2=A0 This is not acceptable f= or ephemeral state
(or operational state either).

<= /div>

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



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

--089e01176905ca9754051bc56142-- From nobody Sun Jul 26 04:47:25 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 F3DAE1B2B72 for ; Sun, 26 Jul 2015 04:47: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 z6MV2mLIsbYc for ; Sun, 26 Jul 2015 04:47: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 BF6A81B2B6F for ; Sun, 26 Jul 2015 04:47: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 1A8A1124A; Sun, 26 Jul 2015 13:47:14 +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 FXZw5AtoQLh8; Sun, 26 Jul 2015 13:47: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; Sun, 26 Jul 2015 13:47:12 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 186012003A; Sun, 26 Jul 2015 13:47:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eFtyCuuxsTMj; Sun, 26 Jul 2015 13:47:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B69A20039; Sun, 26 Jul 2015 13:47:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 56E0B35E0491; Sun, 26 Jul 2015 13:47:16 +0200 (CEST) Date: Sun, 26 Jul 2015 13:47:15 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150726114715.GA17078@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150726071623.GB16276@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 11:47:24 -0000 On Sun, Jul 26, 2015 at 04:17:26AM -0700, Andy Bierman wrote: > On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I would like to open another issue for YANG 1.1, > > > because I don't want to have 1.1 and then 1.2 right away. > > > The NETMOD WG should evaluate the different ways to > > > support ephemeral state, based on Jeff's draft. > > > > > > > The NETMOD WG did spent almost a full day face-to-face interim meeting > > time in September 2014 on this and now we have a requirements I-D plus > > a solution proposal that does not directly match what was discussed > > back then. It is my understanding that the solution discussed in > > September 2014 does not require changes to YANG 1.1. > > > > I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG > > 1.1 is gating other specifications and I am not interested to hold > > everything off (including RESTCONF) because of I2RS. There are many > > other customers of YANG 1.1 beyond I2RS. > > Yeah, it's too bad so many drafts are waiting on YANG. > Support for I2RS got started but never finished. > I care more about the costs of deploying tools and the extra complexity > on readers, who need to know all the versions of YANG. > The proposed solution changes one of the most important statments > in YANG. Harding something to do as an afterthought. I do not think there is agreement on any solution yet. I heard also about vendors implementing ephemeral state solutions that do not require any changes to YANG (and that seem to be more inline with what was discussed in September 2014). > It should not take that long because the NETCONF WG (same people) > have been spending almost all f2f and virtual interim time on I2RS. > The YANG doctors concluded that ephemeral state > was a general feature and not NETCONF specific. > > The problem with using YANG extensions for important protocol features > is that the YANG spec says these statements MAY be completely skipped > by a tool implementation. This is not acceptable for ephemeral state > (or operational state either). I do not know what is to be addressed for operational state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 04:49: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 9FA381B2B72 for ; Sun, 26 Jul 2015 04:49: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 7yvvZcH76TNZ for ; Sun, 26 Jul 2015 04:49: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 C1A581B2B7F for ; Sun, 26 Jul 2015 04:49: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 1C7D51483; Sun, 26 Jul 2015 13:49:35 +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 jzJyh4w9kvCN; Sun, 26 Jul 2015 13:49:33 +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 Jul 2015 13:49:33 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 202C92003A; Sun, 26 Jul 2015 13:49:40 +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 wFcfSzl0J3qT; Sun, 26 Jul 2015 13:49: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 E2B6320039; Sun, 26 Jul 2015 13:49:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DD88935E04F3; Sun, 26 Jul 2015 13:49:37 +0200 (CEST) Date: Sun, 26 Jul 2015 13:49:37 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150726114937.GB17078@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> <20150726105515.GA16978@elstar.local> <0D8E54C3-9CC1-4616-9D9D-3111ED0224FC@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: <0D8E54C3-9CC1-4616-9D9D-3111ED0224FC@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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: Sun, 26 Jul 2015 11:49:44 -0000 Lada, there won't be any decision as long as there is not a concrete actionable proposal to be discussed. Such a proposal does not have to be 'complete rewrite' but it needs to be a detailed list of what would have to change so that it is possible to assess such a proposal. /js On Sun, Jul 26, 2015 at 01:06:54PM +0200, Ladislav Lhotka wrote: > > > On 26 Jul 2015, at 12:55, Juergen Schoenwaelder wrote: > > > > Any are concrete actionable proposals? > > Start rewriting 6020bis, but only if we decide to go that way - it is a difficult decision. I will be slightly in favor of doing so. > > Lada > > > > > /js > > > > On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: > >> > >>> On 26 Jul 2015, at 02:26, Andy Bierman wrote: > >>> > >>> Hi, > >>> > >>> The WG should decide what it means for YANG to not > >>> be NETCONF-specific. Why does YANG define extensions > >>> to NETCONF operations (like insert)? IMO the normative text > >>> about NETCONF should not be in the YANG RFC. > >>> > >> > >> This is essentially what I proposed in Berlin (IETF 87): > >> > >> http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod > >> > >> (first item in Open mike section). > >> > >> Another thing that I realized only recently is that some properties that are inherent to the conceptual data tree are defined in “XML Mapping” sections. > >> > >> I think most YANG concepts and statements can be defined in terms of data tree properties. Separate documents would then define different encodings, and “profiles” for management protocols. > >> > >> It would need massive changes in 6020bis text though. > >> > >> Lada > >> > >>> > >>> Andy > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jul 26 10:12: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 582EB1AC3FE for ; Sun, 26 Jul 2015 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 MebA06-VKPC9 for ; Sun, 26 Jul 2015 10:12:03 -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 A89CF1AC3F2 for ; Sun, 26 Jul 2015 10:12:02 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so40465007lbb.0 for ; Sun, 26 Jul 2015 10:12: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:content-type; bh=bTBGOxpiNFDEn90P3EjtJO6QhjMND0ziapCBZscsJz8=; b=M1tBxXeHrYtqc21IkwNBpE+gT6dwtPqaHrWpBo7fRJcceXh2cPThGc9LHqkKz9lTSX EjxiY+Vf0gCkYh6DjXRR+7q6CWsv013aQ07kFaBrO87c82gy/2WJMKzJVFPXZeOhAobz MX1oikBbE7WESjWW8ywAAPJF4JPjoFcD2Sq9ynLDi4NAVXenwFJ/pdehmDtiAAMePPd+ 2DXszev2zC6bcyA9J0bJUKlJTmcHR6QWfhCdPc2GLk3FZHCWEPAFayKFY+SZxVX3odoq 8mpvVa2ryF50O2EdaPRQNUYYwz6i4TuSKGV+styHmkUHWGphKk2w61xLhOyW1g5FoEX6 2s1w== X-Gm-Message-State: ALoCoQk8H6K2oR4gIHkeDIECtNxqOLT31ZqJUe5TDzuCbk/hxfxyNJax02o2/sQ4jabSoceH04mV MIME-Version: 1.0 X-Received: by 10.152.87.205 with SMTP id ba13mr22449044lab.37.1437930721188; Sun, 26 Jul 2015 10:12:01 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 10:12:01 -0700 (PDT) In-Reply-To: <20150726072210.GC16276@elstar.local> References: <20150725082507.GA14481@elstar.local> <20150726072210.GC16276@elstar.local> Date: Sun, 26 Jul 2015 10:12:01 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3539ad935d6051bca551a Archived-At: Subject: Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items 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: Sun, 26 Jul 2015 17:12:05 -0000 --001a11c3539ad935d6051bca551a Content-Type: text/plain; charset=UTF-8 On Sun, Jul 26, 2015 at 12:22 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bierman wrote: > > On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > This is the summary of the discussion of YANG 1.1 issue Y60 at the > > > IETF 93 meeting in Prague: > > > > > > - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which > > > will of course be interpreted according to the YANG 1.0 rules). > > > > I am not convinced this will be a good idea. > > Obviously the compiler has to restrict 1.0 modules to 1.0 syntax, > > but the corner-case semantics that have been clarified in 1.1 > > SHOULD be followed if a 1.1 module imports 1.0, even for augment. > > > > Please provide concrete examples what breaks if we allow to import > YANG 1.0 modules (using 1.0 semantics). > I have not reviewed the YANG 1.1 draft. I am waiting for WGLC. But from memory -- -- the handling of default prefixes in XPath in groupings was clarified -- the handling of ".." wrt/ top-level nodes in XPath in groupings was clarified -- I think auto-numbering of enum/bit was clarified I guess there is no new text to add here. If this is unspecified in 1.0 then handling it the same as 1.1 is OK > > If this is the case then I think the "restconf-media-type" hack > > should be a real YANG statement. The reason it is an extension > > is because YANG is NETCONF-only. A real statement > > could support augments and deviations. > > > > Just removing a sentence from the abstract is not going to fix all > > NETCONF-specific details in YANG. (Just ask Lada ;-) It is > > not going to make YANG correct for RESTCONF. > > Please provide concrete examples where YANG is incorrect for RESTCONF. > The XPath context for operations are not correct. They are not mentioned in RESTCONF at all. YANG 1.1 should define the XPath contexts in a reusable way, instead of in terms of NETCONF messages. NETCONF, RESTCONF, and CoMI can all map these reusable contexts to their specific protocol messages. Lada has been saying this for a long time. > > > YANG will need to be modified for I2RS anyway. YANG 1.1 took > > too long, and now I2RS is ready. I strongly object to the idea > > of starting on 1.2 while 1.1 is still unpublished. > > Nobody proposed to work on YANG 1.2. > A new statement would require the yang-version string to be changed again. I do not think YANG extensions should be used for ephemeral state because they are not extensible and (literally) not part of YANG. > > > > - The IANA considerations text copied from RFC 6020 will be removed > > > from the YANG 1.1 specification. > > > > Does this mean that YANG 1.1 will have a normative reference to RFC 6020? > > Or are the references to the IANA registries? > > Joel (AD) said this will all be OK. I had my doubts but he said it is > no problem since the registry now exists and won't go away anyway even > if RFC 6020 goes historic. Please check the recording. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c3539ad935d6051bca551a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 26, 2015 at 12:22 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bier= man wrote:
> On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > This is the summary of the discussion of YANG 1.1 issue Y60 at th= e
> > IETF 93 meeting in Prague:
> >
> >=C2=A0 - It is OK for a YANG 1.1 module to import a YANG 1.0 modul= e (which
> >=C2=A0 =C2=A0 will of course be interpreted according to the YANG = 1.0 rules).
>
> I am not convinced this will be a good idea.
> Obviously the compiler has to restrict 1.0 modules to 1.0 syntax,
> but the corner-case semantics that have been clarified in 1.1
> SHOULD be followed if a 1.1 module imports 1.0, even for augment.
>

Please provide concrete examples what breaks if we allow to import
YANG 1.0 modules (using 1.0 semantics).


I have not reviewed the YANG 1.1 draft. I am waiting for WG= LC.
But from memory --


= =C2=A0 =C2=A0-- the handling of default prefixes in XPath in groupings was = clarified
=C2=A0 =C2=A0-- the handling of ".." wrt/ top= -level nodes in XPath in groupings
=C2=A0 =C2=A0 =C2=A0 was clari= fied
=C2=A0 -- I think auto-numbering of enum/bit was clarified

I guess there is no new text to add here.
If this is unspecified in 1.0 then handling it the same as 1.1 is OK
=



> If this is the case then I think the "restconf-media-type" h= ack
> should be a real YANG statement.=C2=A0 The reason it is an extension > is because YANG is NETCONF-only.=C2=A0 A real statement
> could support augments and deviations.
>
> Just removing a sentence from the abstract is not going to fix all
> NETCONF-specific details in YANG.=C2=A0 (Just ask Lada ;-)=C2=A0 It is=
> not going to make YANG correct for RESTCONF.

Please provide concrete examples where YANG is incorrect for RESTCONF.
<= /blockquote>


The XPath context for operat= ions are not correct.
They are not mentioned in RESTCONF at all.<= /div>

YANG 1.1 should define the XPath contexts in a reu= sable way,
instead of in terms of NETCONF messages.=C2=A0 NETCONF= , RESTCONF,
and CoMI can all map these reusable contexts to their= specific protocol messages.
Lada has been saying this for a long= time.

=C2=A0

> YANG will need to be modified for I2RS anyway.=C2=A0 YANG 1.1 took
> too long, and now I2RS is ready.=C2=A0 I strongly object to the idea > of starting on 1.2 while 1.1 is still unpublished.

Nobody proposed to work on YANG 1.2.

A new statement would require the yang-version string to be ch= anged again.
I do not think YANG extensions should be used for ep= hemeral state because
they are not extensible and (literally) not= part of YANG.

=C2=A0

> >=C2=A0 - The IANA considerations text copied from RFC 6020 will be= removed
> >=C2=A0 =C2=A0 from the YANG 1.1 specification.
>
> Does this mean that YANG 1.1 will have a normative reference to RFC 60= 20?
> Or are the references to the IANA registries?

Joel (AD) said this will all be OK. I had my doubts but he said it is
no problem since the registry now exists and won't go away anyway even<= br> if RFC 6020 goes historic. Please check the recording.

/js


Andy

=C2=A0

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

--001a11c3539ad935d6051bca551a-- From nobody Sun Jul 26 10:49: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 D8FAC1ACCE1 for ; Sun, 26 Jul 2015 10:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 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_210=0.6, 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 RfokXOqALcZ3 for ; Sun, 26 Jul 2015 10:49:20 -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 38BD61ACCDF for ; Sun, 26 Jul 2015 10:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13500; q=dns/txt; s=iport; t=1437932960; x=1439142560; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/Mj+LnDdVfcr5oKhPBNVbJKOuPdezxWqKA/7fXN0r3o=; b=DJhV0kZM7fItSTlrrAAK04RbF/LXT3m6OUG30osBDRt9Ht9o0qYu41Gb yF4Y2Jgm/yCU7V+lo4aau0Hc3IH8fOIx3SecuRwaURsIZ0bfoGK/Xu1t3 RQ1C5evw1RS+CDSYenRVYmVtoGri9Pe1HoXFkvRxwvUvfGDn9JgUnP9h8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7BQAgHbVV/4wNJK1YA4MVVGkGgx24boFtCoUvSgIcgRA6EgEBAQEBAQGBCoQkAQEEAQEBIBE6Cw4CAgEIDgIIAgImAgICGQwLFRACBAENBRuIEw25RpVNAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSBHooshDwYGAsQBxKCV4FDBYcXhS6IJAGMQIFFhB2PYoNiJoIOHIFTb4FIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,547,1432598400"; d="scan'208";a="172661753" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2015 17:49:18 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6QHnI6Y010543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jul 2015 17:49:18 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Sun, 26 Jul 2015 12:49:18 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , "Ladislav Lhotka" Thread-Topic: [netmod] Y34 Thread-Index: AQHQwun4N/mOpIK+o0+8Bax//aiDw53koqAAgAAB9wCAAAOxAIAAH1sAgAAl1QCAAAOsgIAAA9aAgAA3SgCABy78gA== Date: Sun, 26 Jul 2015 17:49:17 +0000 Message-ID: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> In-Reply-To: <20150720210041.GA17614@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.203] Content-Type: text/plain; charset="utf-8" Content-ID: <3C4986505CF9CA47A07A05E9350F7956@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Sun, 26 Jul 2015 17:49:23 -0000 SSB0aGluayBiZWluZyBhYmxlIHRvIHBsYWNlIGEgZ2l2ZW4gbW9kZWwgYW55d2hlcmUgaW4gdGhl IGRldmljZSB0cmVlDQp3b3VsZCBiZSB1c2VmdWwgYW5kIHRoaXMgd291bGQgYWxsb3cgYSBtb2Rl bCB0byBiZSByb290ZWQgaW4gZGlmZmVyZW50DQpsb2NhdGlvbnMgb24gZGlmZmVyZW50IGRldmlj ZXMuIFNpbWlsYXJseSwgd2XigJlkIG5lZWQgdGhlIGFiaWxpdHkgdG8gcHJlZml4DQpYUEFUSCBy ZWZlcmVuY2VzIHRvIGRhdGEgbm9kZXMgaW4gdGhlIG1vZGVsIHdpdGggdGhlIHJvb3QuDQpUaGFu a3MsDQpBY2VlIA0KDQpPbiA3LzIwLzE1LCAxMTowMCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg SnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZg0Kai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPkxh ZGEsDQo+DQo+WTM0IGlzIGNsb3NlZCBhbmQgSSBoYXZlIG5vdCBzZWVuIGFueSBuZXcgYXJndW1l bnQgaGVyZSB0aGF0IGluZGljYXRlcw0KPndlIG1hZGUgYSBtYWpvciBtaXN0YWtlIHdpdGggdGhl IHJlc29sdXRpb24gb2YgWTM0LiBBcyBzdWNoLCBZMzQNCj5yZW1haW5zIGNsb3NlZC4NCj4NCj5J ZiB5b3Ugd2FudCB0byBkaXNjdXNzIG5ldyBpZGVhcyB0byByZWxvY2F0ZSBvciAic3ltbGluayIg ZGF0YSBtb2RlbHMsDQo+cGxlYXNlIGRvIHNvIGluIGEgc2VwYXJhdGUgdGhyZWFkLiAoQW5kIG5v LCB3ZSBkbyBub3QgYWNjZXB0IG5ldw0KPmlzc3VlcyBmb3IgWUFORyAxLjEgZWl0aGVyIGF0IHRo aXMgcG9pbnQgaW4gdGltZS4pDQo+DQo+L2pzDQo+DQo+T24gTW9uLCBKdWwgMjAsIDIwMTUgYXQg MDc6NDI6NDlQTSArMDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPj4gDQo+PiA+IE9uIDIw IEp1bCAyMDE1LCBhdCAxOToyOSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdy b3RlOg0KPj4gPiANCj4+ID4gDQo+PiA+IA0KPj4gPiBPbiBNb24sIEp1bCAyMCwgMjAxNSBhdCAx MDoxNSBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6Pg0KPj53cm90ZToNCj4+ID4g DQo+PiA+ID4gT24gMjAgSnVsIDIwMTUsIGF0IDE3OjAwLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt YXdvcmtzLmNvbT4gd3JvdGU6DQo+PiA+ID4NCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4gT24gTW9u LCBKdWwgMjAsIDIwMTUgYXQgNjowOCBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6 Pg0KPj53cm90ZToNCj4+ID4gPg0KPj4gPiA+ID4gT24gMjAgSnVsIDIwMTUsIGF0IDE0OjU1LCBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+PiA+ID4gPg0KPj4gPiA+ ID4gSGksDQo+PiA+ID4gPg0KPj4gPiA+ID4gQ2FuIHlvdSBleHBsYWluIHdoeSB3ZSBuZWVkIDIg YnJva2VuIGFueXhtbHM/DQo+PiA+ID4gPiAoVGhlIG9yaWdpbmFsIGFuZCBhIHN5bm9ueW0/KSAg VGhlIHdob2xlIHBvaW50IG9mDQo+PiA+ID4gPiBhbnlkYXRhIGlzIHRoYXQgaXQgZG9lcyBub3Qg aGF2ZSBYTUwgY3J1ZnQgaW4gaXQuDQo+PiA+ID4NCj4+ID4gPiBZZXMsIEkgdW5kZXJzdGFuZCB0 aGlzIHdhcyB5b3VyIG1haW4gcHJpb3JpdHkuIEZvciBpbXBsZW1lbnRvcnMNCj4+dXNpbmcgb2Zm LXRoZS1zaGVsZiBYTUwgcGFyc2VycyBhbmQgdG9vbHMgdGhlIFhNTCBjcnVmdCBpcyBub3QgYW4g aXNzdWUNCj4+YXQgYWxsLg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPiB5ZXMgaXQgaXMgYW4gaXNz dWUuDQo+PiA+ID4gV2UgbmVlZCBzb21ldGhpbmcgdG8gbW9kZWwgYSBjb250YWluZXIgZnVsbCBv ZiBhcmJpdHJhcnkgWUFORyBkYXRhDQo+Pm5vZGVzLg0KPj4gPiA+IFRoaXMgaXMgc29tZXRoaW5n IHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIGNvbnRlbnRzIG9mIGENCj4+ZGF0YXN0b3JlLg0K Pj4gPiANCj4+ID4gYW55eG1sIGNhbiBkbyB0aGF0LCB0b28uDQo+PiA+IA0KPj4gPiANCj4+ID4g dGhlIFdHIGFscmVhZHkgZGVjaWRlZCBpdCBjYW4ndC4NCj4+ID4gVGhlIGV4dHJhIFhNTCBQSXMs IGV0Yy4gYXJlIG5vdCBhY2NlcHRlZCBieSBhbGwgc2VydmVycywgcmVtZW1iZXI/DQo+PiA+IFRo ZXJlIGlzIG5vIHVzZSBmb3IgdGhlIGV4dHJhIHN0dWZmIGluIHRoZSBkYXRhc3RvcmUuDQo+PiA+ ICBJIGRvbid0IHNlZSB3aHkgd2UgbmVlZCAyIGFueXhtbCBjb25zdHJ1Y3RzIHRoYXQgYXJlIG5v dA0KPj4gPiBzdXBwb3J0ZWQgYnkgdGhlIGluZHVzdHJ5LiAgT25lIGlzIGFscmVhZHkgdG9vIG1h bnkuDQo+PiANCj4+IEkgYWdyZWUsIGJ1dCB0aGlzIGlzIHdoYXQgd2UgYXJlIGdvaW5nIHRvIGhh dmUuIE15IHByb3Bvc2FsIHdhcyB0byBoYXZlDQo+Pmp1c3Qgb25lIHdpdGggdHdvIGRpZmZlcmVu dCBuYW1lcy4NCj4+IA0KPj4gPiANCj4+ID4gDQo+PiA+ID4NCj4+ID4gPg0KPj4gPiA+IEFueXdh eSwgSSBiZWxpZXZlIHRoZXJlIGFyZSB1c2UgY2FzZXMgZm9yIGFyYml0cmFyeSBYTUwvSlNPTi9D Qk9SL+KApg0KPj53aXRoIG5vIChZQU5HKSBzY2hlbWEgYXZhaWxhYmxlLiBNeSBvbmx5IGNvbXBs YWludCB0byDigJxhbnl4bWzigJ0gaGFzDQo+PmFsd2F5cyBiZWVuIHRoYXQgaXQgaXMgYSBtaXNu b21lciBmb3IgZW5jb2RpbmdzIG90aGVyIHRoYW4gWE1MLg0KPj4gPiA+DQo+PiA+ID4gVGhlIG1l c3NhZ2UgZW5jb2Rpbmcgb24gdGhlIHdpcmUgaXMgbm90IHRoZSBzYW1lIGlzc3VlDQo+PiA+ID4g YXMgdGhlIGNvbnRlbnRzIG9mIGEgZGF0YXN0b3JlLiAgT3VyIHNlcnZlciBzdG9yZXMgaXRzIG93 bg0KPj4gPiA+IGludGVybmFsIGRhdGEgc3RydWN0dXJlcy4gIFhNTCwgSlNPTiwgQ0JPUiBhcmUg anVzdCBtZXNzYWdlDQo+PiA+ID4gZW5jb2RpbmcgZm9ybWF0cyBiZXR3ZWVuIGNsaWVudCBhbmQg c2VydmVyLiAgVGhlIGRhdGFzdG9yZQ0KPj4gPiA+IGlzIG5vdCBlbmNvZGVkIGluIGFueSBvZiB0 aGVzZSBmb3JtYXRzLg0KPj4gPiANCj4+ID4gVGhlIHBheWxvYWQgb2YgYW55eG1sIG5lZWRu4oCZ dCBkaXJlY3RseSBtYXAgdG8gYSBkYXRhIHN1YnRyZWUgaW4gdGhlDQo+PnVzdWFsIHNlbnNlLg0K Pj4gPiANCj4+ID4gdGhhdCdzIHByZWNpc2VseSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGFueXht bCBhbmQgYW55ZGF0YS4NCj4+ID4gVGhlIGFueWRhdGEgbm9kZSBNVVNUIG1hcCBkaXJlY3RseSBp bnRvIGRhdGEgc3VidHJlZXMuDQo+PiANCj4+IElmIHRoZSBzZXJ2ZXIgZG9lc27igJl0IGtub3cg dGhlIFlBTkcgZGF0YSBtb2RlbCBhdCBydW4gdGltZSAod2hpY2ggaXMNCj4+cG9zc2libGUpIHRo ZW4gaXQgY2Fubm90IGRvIGl0IC0gZm9yIGluc3RhbmNlLCBpdCBjYW5ub3QgcHJvcGVybHkgbWFw DQo+Pm1vZHVsZSBuYW1lcyB0byBuYW1lc3BhY2UgVVJJIG9yIGhhbmRsZSBsaXN0cy4NCj4+IA0K Pj4gPiANCj4+ID4gIA0KPj4gPiANCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPg0KPj4g PiA+DQo+PiA+ID4gPg0KPj4gPiA+ID4gSSBhbHNvIGRvbid0IGdldCB0aGUgdmFsdWUgb2YgYSBz aW5nbGUgdG9wLWxldmVsIG5vZGUgY2FsbGVkDQo+PidkZXZpY2UnDQo+PiA+ID4gPiB0aGF0IGV2 ZXJ5IFlBTkcgbW9kZWwgb24gdGhlIHBsYW5ldCBpcyBzdXBwb3NlZCB0byBhdWdtZW50Lg0KPj4g PiA+ID4gQ2FuIHlvdSBleHBsYWluIHdoeSBhIHByb3RvY29sIG9wZXJhdGlvbiB0byByZXRyaWV2 ZSB0aGUNCj4+ID4gPiA+IGRvY3VtZW50IHJvb3QgKC8pIGlzIG5vdCBzdWZmaWNpZW50IGZvciB0 aGUgdG9wLWxldmVsIG5vZGU/DQo+PiA+ID4NCj4+ID4gPiBJIGRvbuKAmXQgaW50ZW5kIHRvIGRl ZmVuZCB0aGVpciBtb2RlbCwgdGhlIG1vcmUgc2VyaW91cyBwcm9ibGVtIElNTw0KPj5pcyB0aGF0 IGEgbW9kZWwgZm9yIGEgc2luZ2xlIGRldmljZS9mdW5jdGlvbiBtYXkgYmUgbmVlZGVkIGluIGFu b3RoZXINCj4+ZGV2aWNlIHRoYXQgaG9zdHMgbWFueSB2aXJ0dWFsaXNlZCBkZXZpY2VzL2Z1bmN0 aW9ucyBvZiB0aGUgZm9ybWVyIHR5cGUuDQo+PldlIGRvbuKAmXQgaGF2ZSBhIGdvb2Qgc29sdXRp b24gZm9yIHRoaXMgcmF0aGVyIHR5cGljYWwgc2l0dWF0aW9uLg0KPj4gPiA+DQo+PiA+ID4gQnV0 IGEgc2luZ2xlIGNvbnRhaW5lciBjYWxsZWQgIndoYXRldmVyIiBwcm92aWRlcyBubyBzdWNoDQo+ PmFnZ3JlZ2F0aW9uLg0KPj4gPiA+IFlvdSB3b3VsZCBuZWVkIGEgbGlzdCBmb3IgdGhhdC4gQW5k IHRoZSBOTVMgbWlnaHQgaGF2ZSBtdWx0aXBsZQ0KPj4gPiA+IGxheWVycyBvZiBoaWVyYXJjaHkg dG8gcmVwcmVzZW50IHZhcmlvdXMgYWdncmVnYXRpb25zLiAgVGhlIE5QDQo+PiA+ID4gY29udGFp bmVyIGNhbGxlZCAiZGV2aWNlIiBpcyBub3QgaGVscGZ1bCBmb3IgYWdncmVnYXRpb24uDQo+PiA+ IA0KPj4gPiBUaGUgcGFyZW50IG5vZGUgY2FuIGJlIGEgbGlzdCBhcyB3ZWxsLiBUaGUg4oCccm9v dOKAnSBub2RlIHdvdWxkIGJlIGxpa2UNCj4+YSBtb3VudCBwb2ludCBpbiBhIFVuaXggZmlsZXN5 c3RlbS4NCj4+ID4gDQo+PiA+IA0KPj4gPiBBcmUgeW91IHNheWluZyBhbGwgZGF0YSBvbiBhIGRl dmljZSBuZWVkcyB0byBiZSBpbiBhIHRvcC1sZXZlbCBsaXN0DQo+PmNhbGxlZCAnZGV2aWNlJw0K Pj4gPiBiZWNhdXNlIGFuIE5NUyBtaWdodCBleGlzdCB0aGF0ICB3YW50cyB0byBoYXZlIHRoZSBk YXRhc3RvcmVzIGZyb20NCj4+bG90cyBvZiBkZXZpY2VzPw0KPj4gPiBBcyBNYXJ0aW4gcG9pbnRl ZCBvdXQgc2V2ZXJhbCB0aW1lcywgdGhlIE5NUyBjYW4gbWFrZSBpdHMgb3duDQo+PmNvbnRhaW5l ciBvcg0KPj4gPiBsaXN0cy4gIEl0IGRvZXMgbm90IG5lZWQgdGhlIGRldmljZSB0byBtaXJyb3Ig aXRzIG93biBzdHJ1Y3R1cmUuDQo+PiANCj4+IEFzIEkgc2FpZCwgSSBkb27igJl0IGNhcmUgdGhh dCBtdWNoIGFib3V0IHRoZSDigJxkZXZpY2XigJ0gY29udGFpbmVyLiBXaGF0DQo+PndvdWxkIGJl IHJlYWxseSB1c2VmdWwgaXMgdG8gaGF2ZSB0aGUgcG9zc2liaWxpdHkgdG8gZG8gZS5nLiB0aGlz Og0KPj4gDQo+PiB2aXJ0dWFsLW5vZGUqIFtuYW1lXQ0KPj4gICAgIG5hbWUNCj4+ICAgICBpZjpp bnRlcmZhY2VzDQo+PiAgICAgICAgIC4uLg0KPj4gDQo+PiB0byBzdXBwb3J0IHRoZSB1c2UgY2Fz ZSB3aGVyZSBhbGwgdmlydHVhbCBub2RlcyBhcmUgbWFuYWdlZCBieSB0aGUgc2FtZQ0KPj5ORVRD T05GL1JFU1RDT05GIHNlcnZlci4NCj4+IA0KPj4gTGFkYQ0KPj4gDQo+PiA+ICANCj4+ID4gDQo+ PiA+IA0KPj4gPiBMYWRhDQo+PiA+IA0KPj4gPiBBbmR5DQo+PiA+ICANCj4+ID4gDQo+PiA+ID4N Cj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4gTGFkYQ0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPiBBbmR5 DQo+PiA+ID4NCj4+ID4gPg0KPj4gPiA+ID4NCj4+ID4gPiA+IEFuZHkNCj4+ID4gPiA+DQo+PiA+ ID4gPg0KPj4gPiA+ID4NCj4+ID4gPiA+IE9uIE1vbiwgSnVsIDIwLCAyMDE1IGF0IDU6NDggQU0s IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4NCj4+d3JvdGU6DQo+PiA+ID4gPg0KPj4g PiA+ID4gPiBPbiAyMCBKdWwgMjAxNSwgYXQgMTQ6NDUsIExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej4gd3JvdGU6DQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+IEhpLA0KPj4gPiA+ID4gPg0K Pj4gPiA+ID4gPiBhZnRlciBsaXN0ZW5pbmcgdG8gdGhlIHByZXNlbnRhdGlvbiBvZg0KPj4gPiA+ ID4gPiBkcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsLTAwIGF0IFJUR1dHIHNlc3Np b24sIEkgYW0NCj4+d29uZGVyaW5nDQo+PiA+ID4gPiA+IHdoZXRoZXIgdGhlIHNvbHV0aW9uIGNo b3NlbiBmb3IgWTM0IGlzIHJlYWxseSB1c2VmdWwuDQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+IFRo ZSBkcmFmdCBzdGF0ZXMgdGhleSB3YW50IHRvIHJldXNlIGlldGYtaW50ZXJmYWNlcyBidXQgdGhl aXINCj4+dHJlZSBpbg0KPj4gPiA+ID4gPiBmYWN0IGlzDQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+ ICAgKy0tcncgZGV2aWNlDQo+PiA+ID4gPiA+ICAgICAgICAgICstLXJ3IGluZm8NCj4+ID4gPiA+ ID4gICAgICAgICAgfCAgKy0tcncgZGV2aWNlLXR5cGU/ICAgZW51bWVyYXRpb24NCj4+ID4gPiA+ ID4gICAgICAgICAgKy0tcncgaGFyZHdhcmUNCj4+ID4gPiA+ID4gICAgICAgICAgKy0tcncgaW50 ZXJmYWNlcw0KPj4gPiA+ID4gPiAgICAgICAgICB8ICArLS1ydyBpbnRlcmZhY2UqIFtuYW1lXQ0K Pj4gPiA+ID4gPiAgICAgICAgICB8ICAgICAuLi4NCj4+ID4gPiA+ID4gICAgICAgICAgKy0tcncg cW9zDQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+IFNvIHRoZSAiaW50ZXJmYWNlcyIgY29udGFpbmVy IGlzIG5vIG1vcmUgYSB0b3AtbGV2ZWwgbm9kZS4NCj4+VGhlcmUgYXJlDQo+PiA+ID4gPiA+IHRo cmVlIHBvc3NpYmxlIG9wdGlvbnM6DQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+IDEuIENoYW5nZSB0 aGUgaWV0Zi1pbnRlcmZhY2VzIG1vZHVsZS4NCj4+ID4gPiA+ID4gMi4gUmVwbGljYXRlIGl0cyBj b250ZW50cyBpbiBhbm90aGVyIG1vZHVsZS4NCj4+ID4gPiA+ID4gMy4gRXh0ZW5kIFlBTkcgc28g dGhhdCBhICpzcGVjaWZpYyogc2NoZW1hIHRyZWUgY2FuIGJlIGdyYWZ0ZWQNCj4+YXQgYQ0KPj4g PiA+ID4gPiAgIGdpdmVuIGRhdGEgbm9kZS4NCj4+ID4gPiA+ID4NCj4+ID4gPiA+ID4gSU1PICMx ICYgIzIgYXJlIHJlYWxseSBiYWQuIEkgdGhvdWdodCBZMzQtMDQgd2FzIGVzc2VudGlhbGx5ICMz DQo+PmJ1dCBpdA0KPj4gPiA+ID4gPiBzZWVtcyBpdCBpcyBub3Qgc28gYmVjYXVzZSBpdCBkb2Vz bid0IHNwZWNpZnkgYSBjb25jcmV0ZSBkYXRhDQo+Pm1vZGVsDQo+PiA+ID4gPiA+IHRoYXQncyBh bGxvd2VkIGF0IGEgZ2l2ZW4gbG9jYXRpb24uDQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+IE9uIHRo ZSBvdGhlciBoYW5kLCB0aGUgb25seSByZWFsIGNvbnRyaWJ1dGlvbiBvZiAiYW55ZGF0YSIgb3Zl cg0KPj4iYW55eG1sIg0KPj4gPiA+ID4gPiBpcyB0aGF0IGlzIGRvZXNuJ3QgcGVybWl0IG1peGVk IGNvbnRlbnQgaW4gWE1MLCB3aGljaCBpcyBJTU8NCj4+bm90IG11Y2guDQo+PiA+ID4gPiA+DQo+ PiA+ID4gPiA+IEkga25vdyBZMzQgd2FzIGFscmVhZHkgY2xvc2VkIGJ1dCBJIHRoaW5rIGl0IGlz IG1vcmUgaW1wb3J0YW50DQo+PnRvIGRvDQo+PiA+ID4gPiA+IHRoaW5ncyByaWdodCBiZWZvcmUg WUFORyAxLjEgYmVjb21lcyBhbiBSRkMuDQo+PiA+ID4gPiA+DQo+PiA+ID4gPiA+IFdoYXQgSSB3 YW50IHRvIHByb3Bvc2UgaXMgdGhpczoNCj4+ID4gPiA+ID4NCj4+ID4gPiA+ID4gLSBSZW5hbWUg ImFueWRhdGEiIGFzIGEgc3lub255bSB0byAiYW55eG1sIiwgYW5kIGRlcHJlY2F0ZQ0KPj4iYW55 eG1sIiAoYnV0DQo+PiA+ID4gPiA+ICBrZWVwIGl0IGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 KS4NCj4+ID4gPiA+DQo+PiA+ID4gPiBzL1JlbmFtZS9JbnRyb2R1Y2UvDQo+PiA+ID4gPg0KPj4g PiA+ID4gPg0KPj4gPiA+ID4gPiAtIEludHJvZHVjZSBhIG5ldyBzdGF0ZW1lbnQgYW5kIGRhdGEg bm9kZSB0eXBlLCBlLmcuICJyb290IiwNCj4+dGhhdCB3aWxsDQo+PiA+ID4gPiA+ICBleHRlbmQg dGhlIHNjaGVtYSB0cmVlIHN0YXJ0aW5nIGZyb20gdGhhdCBkYXRhIG5vZGUgd2l0aCBhDQo+PnBy ZWNpc2VseQ0KPj4gPiA+ID4gPiAgc3BlY2lmaWVkIGRhdGEgbW9kZWwuIFRoZSBzcGVjaWZpY2F0 aW9uIGNhbiBiZSBzYW1lIG9yIHNpbWlsYXINCj4+YXMNCj4+ID4gPiA+ID4gIGluIHlhbmctbGli cmFyeS4NCj4+ID4gPiA+ID4NCj4+ID4gPiA+ID4gSSBiZWxpZXZlIHRoZXJlIGFyZSBvdGhlciB1 c2UgY2FzZXMgaW4gdGhlIGV4aXN0aW5nIG1vZHVsZXMuIEZvcg0KPj4gPiA+ID4gPiBleGFtcGxl LCB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBjb3VsZCBzaW1wbHkgZGVmaW5lIHRoZSBkYXRhDQo+ Pm1vZGVsIGZvcg0KPj4gPiA+ID4gPiBhIHNpbmdsZSByb3V0aW5nIGluc3RhbmNlIChpLmUuIHdp dGhvdXQgInJvdXRpbmctaW5zdGFuY2UiIGxpc3QNCj4+YXQgdGhlDQo+PiA+ID4gPiA+IHRvcCks IGFuZCBpdCBjYW4gYmUgdGhlbiB1c2VkIHdpdGhvdXQgY2hhbmdlcyBvbiBzaW1wbGUNCj4+ZGV2 aWNlcywgYW5kDQo+PiA+ID4gPiA+IG1vcmUgY29tcGxleCByb3V0ZXIgaW1wbGVtZW50YXRpb25z IGNhbiBncmFmdCBpdCBhcyBhIHN1YnRyZWUNCj4+dW5kZXINCj4+ID4gPiA+ID4gInJvdXRpbmct aW5zdGFuY2UiLCAibmV0d29ya2luZy1pbnN0YW5jZSIgb3Igd2hhdGV2ZXIuDQo+PiA+ID4gPiA+ DQo+PiA+ID4gPiA+IExhZGENCj4+ID4gPiA+ID4NCj4+ID4gPiA+ID4gLS0NCj4+ID4gPiA+ID4g TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4gPiA+ID4gPiBQR1AgS2V5IElEOiBFNzRF OEMwQw0KPj4gPiA+ID4gPg0KPj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gPiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiA+ ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gPiA+ID4NCj4+ID4gPiA+IC0tDQo+PiA+ID4gPiBM YWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+PiA+ID4gPiBQR1AgS2V5IElEOiBFNzRFOEMw Qw0KPj4gPiA+ID4NCj4+ID4gPiA+DQo+PiA+ID4gPg0KPj4gPiA+ID4NCj4+ID4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ID4gPiBuZXRt b2QgbWFpbGluZyBsaXN0DQo+PiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4+ID4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiA+ID4gPg0KPj4gPiA+ DQo+PiA+ID4gLS0NCj4+ID4gPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+PiA+ID4g UEdQIEtleSBJRDogRTc0RThDMEMNCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPg0KPj4g PiA+DQo+PiA+IA0KPj4gPiAtLQ0KPj4gPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+ PiA+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+PiA+IA0KPj4gPiANCj4+ID4gDQo+PiA+IA0KPj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+PiA+IG5ldG1vZEBpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gDQo+PiAtLQ0KPj4gTGFkaXNs YXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+IA0KPj4g DQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCj4tLSANCj5KdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5 IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K DQo= From nobody Sun Jul 26 11:17:25 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 793B91ACD19 for ; Sun, 26 Jul 2015 11:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=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 dXikVNkjv6KV for ; Sun, 26 Jul 2015 11:17:21 -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 14C581A1B6B for ; Sun, 26 Jul 2015 11:17:21 -0700 (PDT) Received: by lahh5 with SMTP id h5so37284899lah.2 for ; Sun, 26 Jul 2015 11:17:19 -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=VGFEAGJO9giwfajFInx7iY8OvAGyk/HX6VcoJVD84EM=; b=B1Qsu4IEHXTIt5SEISan7E3XUS9Rt6BydcO20rqKxhSYnNOimXXZi8VRK/EGXgzr2R +ED0NDEpPEHXrD2Xdm6iq+pV0DAEr9m2mdBFernGrjitwrQ3miTeJMxKEySU9A4UEEcT 2NTLom8/o9QrirmULv5zRdVEtdciSrIQ8DmgXsnoDaJxLzOluyofq26tacQCM9JsO2+3 6n8xQYdjbVSUL+qsRatnbVP/dutiOg+81w4yJKhgnAh84Uy1YCJW15rqjbTjIcQPmfJU FTr1LVo3zxzoKqNtFS4CEl3ueOiPLn63sWuCJFd5gzOzzHduyhnIrPaiHH39EIx8fbkx SOjA== X-Gm-Message-State: ALoCoQl3P5BXUasiYOHT3J5zfsyjisDw+C9WemZj1UOoUvLnIc1TEdgiuEmvPv1c08JDIpWC/HlZ MIME-Version: 1.0 X-Received: by 10.112.24.71 with SMTP id s7mr22653483lbf.37.1437934639450; Sun, 26 Jul 2015 11:17:19 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 11:17:19 -0700 (PDT) In-Reply-To: <20150726114715.GA17078@elstar.local> References: <20150726071623.GB16276@elstar.local> <20150726114715.GA17078@elstar.local> Date: Sun, 26 Jul 2015 11:17:19 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11343832654ca8051bcb3f1f Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Sun, 26 Jul 2015 18:17:23 -0000 --001a11343832654ca8051bcb3f1f Content-Type: text/plain; charset=UTF-8 Hi, I agree it should be a WG (maybe IESG) decision whether YANG 1.1 should be published ASAP and a new version started right away to update it. The RFC publication process is not that hard to solve. The tool and user confusion caused by all these versions is another matter. more inline... On Sun, Jul 26, 2015 at 4:47 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Jul 26, 2015 at 04:17:26AM -0700, Andy Bierman wrote: > > On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > > Hi, > > > > > > > > I would like to open another issue for YANG 1.1, > > > > because I don't want to have 1.1 and then 1.2 right away. > > > > The NETMOD WG should evaluate the different ways to > > > > support ephemeral state, based on Jeff's draft. > > > > > > > > > > The NETMOD WG did spent almost a full day face-to-face interim meeting > > > time in September 2014 on this and now we have a requirements I-D plus > > > a solution proposal that does not directly match what was discussed > > > back then. It is my understanding that the solution discussed in > > > September 2014 does not require changes to YANG 1.1. > > > > > > I2RS was aware of the YANG 1.1 timeline from the very beginning. YANG > > > 1.1 is gating other specifications and I am not interested to hold > > > everything off (including RESTCONF) because of I2RS. There are many > > > other customers of YANG 1.1 beyond I2RS. > > > > Yeah, it's too bad so many drafts are waiting on YANG. > > Support for I2RS got started but never finished. > > I care more about the costs of deploying tools and the extra complexity > > on readers, who need to know all the versions of YANG. > > The proposed solution changes one of the most important statments > > in YANG. Harding something to do as an afterthought. > > I do not think there is agreement on any solution yet. I heard also > about vendors implementing ephemeral state solutions that do not > require any changes to YANG (and that seem to be more inline with what > was discussed in September 2014). > I know there is not agreement on the solution yet. That is why it is an open issue. I2RS does not have to present NETMOD WG with a solution (even though they did present an acceptable solution). In order for I2RS to have the YANG validation rules that meet its use-cases, new text is needed. This text needs to be associated with data-nodes. I like the proposed solution of config=true,ephemeral,false because I know none of the existing text inadvertently applies to ephemeral nodes. I do not think YANG is fully specified wrt/ datastores because operational state and ephemeral nodes are not separated. An ephemeral datastore (and perhaps operational datastore) are needed to solve this problem. > > It should not take that long because the NETCONF WG (same people) > > have been spending almost all f2f and virtual interim time on I2RS. > > The YANG doctors concluded that ephemeral state > > was a general feature and not NETCONF specific. > > > > The problem with using YANG extensions for important protocol features > > is that the YANG spec says these statements MAY be completely skipped > > by a tool implementation. This is not acceptable for ephemeral state > > (or operational state either). > > I do not know what is to be addressed for operational state. > Then openconfig issues for starters. That does not have to be solved at the same time as ephemeral data. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11343832654ca8051bcb3f1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I agree it should be a WG (maybe IE= SG) decision whether YANG 1.1
should be published ASAP and a new = version started right away to update it.
The RFC publication proc= ess is not that hard to solve. The tool and user
confusion caused= by all these versions is another matter.

more inl= ine...




On Sun, Jul 26, 2015 at 4:47 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Sun, Jul 26, 2015 a= t 04:17:26AM -0700, Andy Bierman wrote:
> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > I would like to open another issue for YANG 1.1,
> > > because I don't want to have 1.1 and then 1.2 right away= .
> > > The NETMOD WG should evaluate the different ways to
> > > support ephemeral state, based on Jeff's draft.
> > >
> >
> > The NETMOD WG did spent almost a full day face-to-face interim me= eting
> > time in September 2014 on this and now we have a requirements I-D= plus
> > a solution proposal that does not directly match what was discuss= ed
> > back then. It is my understanding that the solution discussed in<= br> > > September 2014 does not require changes to YANG 1.1.
> >
> > I2RS was aware of the YANG 1.1 timeline from the very beginning. = YANG
> > 1.1 is gating other specifications and I am not interested to hol= d
> > everything off (including RESTCONF) because of I2RS. There are ma= ny
> > other customers of YANG 1.1 beyond I2RS.
>
> Yeah, it's too bad so many drafts are waiting on YANG.
> Support for I2RS got started but never finished.
> I care more about the costs of deploying tools and the extra complexit= y
> on readers, who need to know all the versions of YANG.
> The proposed solution changes one of the most important statments
> in YANG.=C2=A0 Harding something to do as an afterthought.

I do not think there is agreement on any solution yet. I heard also
about vendors implementing ephemeral state solutions that do not
require any changes to YANG (and that seem to be more inline with what
was discussed in September 2014).


<= /div>
I know there is not agreement on the solution yet.
That= is why it is an open issue. I2RS does not have to present NETMOD WG
<= div>with a solution (even though they did present an acceptable solution).<= /div>

In order for I2RS to have the YANG validation rule= s that meet its
use-cases, new text is needed. This text needs to= be associated
with data-nodes.

I li= ke the proposed solution of config=3Dtrue,ephemeral,false
because= I know none of the existing text inadvertently applies
to epheme= ral nodes.

I do not think YANG is fully specified = wrt/ datastores because
operational state and ephemeral nodes are= not separated.
An ephemeral datastore (and perhaps operational d= atastore)
are needed to solve this problem.

<= div>

> It should not take that long because the NETCONF WG (same people)
> have been spending almost all f2f and virtual interim time on I2RS. > The YANG doctors concluded that ephemeral state
> was a general feature and not NETCONF specific.
>
> The problem with using YANG extensions for important protocol features=
> is that the YANG spec says these statements MAY be completely skipped<= br> > by a tool implementation.=C2=A0 This is not acceptable for ephemeral s= tate
> (or operational state either).

I do not know what is to be addressed for operational state.

Then openconfig issues for starters.
That d= oes not have to be solved at the same time as ephemeral data.
=C2=A0

/js


Andy

=C2=A0

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

--001a11343832654ca8051bcb3f1f-- From nobody Sun Jul 26 12:48:49 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 E250E1A8880 for ; Sun, 26 Jul 2015 12:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 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_210=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 mZiMytpO2b8p for ; Sun, 26 Jul 2015 12:48:45 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 9F7111A8866 for ; Sun, 26 Jul 2015 12:48:45 -0700 (PDT) Received: (qmail 31799 invoked by uid 0); 26 Jul 2015 19:48:41 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 26 Jul 2015 19:48:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id xDUZ1q00E2SSUrH01DUcpu; Sun, 26 Jul 2015 19:28:41 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=iEhmfDb7q88A:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=Tm3B_xXddfIA:10 a=zOBTXjUuO1YA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=xskcdSivAAAA:8 a=j3Z76cjpAAAA:8 a=8gR-BrMjdX2m8hJOEskA:9 a=YBRLT6JxL3Q9K0Xn:21 a=OeOYAulNaYl37uFz:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=VnB8m5+L6gyZAJqbJYSmKdYCgha2PI82eJJW9IwqwGw=; b=NCA4Qnf+0YI0PPOrARhYp3lYVoqnImXFxKfTpFaRxTs8pLrjuIxFVl36zKclZzoVBpgSX0Mudvt+TwSit/tOrrtjWlL6zwUeq0XsLgB7Nj889YhPh4qpVrZPtDozz6nR; Received: from [172.56.6.72] (port=46213 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZJRb7-0007Aa-8v; Sun, 26 Jul 2015 13:28:34 -0600 From: Lou Berger To: "Acee Lindem (acee)" , Juergen Schoenwaelder , Ladislav Lhotka Date: Sun, 26 Jul 2015 15:28:31 -0400 Message-ID: <14ecbafd8c0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.6.72 authed with lberger@labn.net} Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Sun, 26 Jul 2015 19:48:48 -0000 I completely agree. We definitely will make use if this in the new models being developed in the routing area. Lou On July 26, 2015 1:50:00 PM "Acee Lindem (acee)" wrote: > I think being able to place a given model anywhere in the device tree > would be useful and this would allow a model to be rooted in different > locations on different devices. Similarly, we’d need the ability to prefix > XPATH references to data nodes in the model with the root. > Thanks, > Acee > > On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > j.schoenwaelder@jacobs-university.de> wrote: > > >Lada, > > > >Y34 is closed and I have not seen any new argument here that indicates > >we made a major mistake with the resolution of Y34. As such, Y34 > >remains closed. > > > >If you want to discuss new ideas to relocate or "symlink" data models, > >please do so in a separate thread. (And no, we do not accept new > >issues for YANG 1.1 either at this point in time.) > > > >/js > > > >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > >> > >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka > >>wrote: > >> > > >> > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka > >>wrote: > >> > > > >> > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > >> > > > > >> > > > Hi, > >> > > > > >> > > > Can you explain why we need 2 broken anyxmls? > >> > > > (The original and a synonym?) The whole point of > >> > > > anydata is that it does not have XML cruft in it. > >> > > > >> > > Yes, I understand this was your main priority. For implementors > >>using off-the-shelf XML parsers and tools the XML cruft is not an issue > >>at all. > >> > > > >> > > > >> > > yes it is an issue. > >> > > We need something to model a container full of arbitrary YANG data > >>nodes. > >> > > This is something that can be applied to the contents of a > >>datastore. > >> > > >> > anyxml can do that, too. > >> > > >> > > >> > the WG already decided it can't. > >> > The extra XML PIs, etc. are not accepted by all servers, remember? > >> > There is no use for the extra stuff in the datastore. > >> > I don't see why we need 2 anyxml constructs that are not > >> > supported by the industry. One is already too many. > >> > >> I agree, but this is what we are going to have. My proposal was to have > >>just one with two different names. > >> > >> > > >> > > >> > > > >> > > > >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… > >>with no (YANG) schema available. My only complaint to “anyxml” has > >>always been that it is a misnomer for encodings other than XML. > >> > > > >> > > The message encoding on the wire is not the same issue > >> > > as the contents of a datastore. Our server stores its own > >> > > internal data structures. XML, JSON, CBOR are just message > >> > > encoding formats between client and server. The datastore > >> > > is not encoded in any of these formats. > >> > > >> > The payload of anyxml needn’t directly map to a data subtree in the > >>usual sense. > >> > > >> > that's precisely the difference between anyxml and anydata. > >> > The anydata node MUST map directly into data subtrees. > >> > >> If the server doesn’t know the YANG data model at run time (which is > >>possible) then it cannot do it - for instance, it cannot properly map > >>module names to namespace URI or handle lists. > >> > >> > > >> > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > I also don't get the value of a single top-level node called > >>'device' > >> > > > that every YANG model on the planet is supposed to augment. > >> > > > Can you explain why a protocol operation to retrieve the > >> > > > document root (/) is not sufficient for the top-level node? > >> > > > >> > > I don’t intend to defend their model, the more serious problem IMO > >>is that a model for a single device/function may be needed in another > >>device that hosts many virtualised devices/functions of the former type. > >>We don’t have a good solution for this rather typical situation. > >> > > > >> > > But a single container called "whatever" provides no such > >>aggregation. > >> > > You would need a list for that. And the NMS might have multiple > >> > > layers of hierarchy to represent various aggregations. The NP > >> > > container called "device" is not helpful for aggregation. > >> > > >> > The parent node can be a list as well. The “root” node would be like > >>a mount point in a Unix filesystem. > >> > > >> > > >> > Are you saying all data on a device needs to be in a top-level list > >>called 'device' > >> > because an NMS might exist that wants to have the datastores from > >>lots of devices? > >> > As Martin pointed out several times, the NMS can make its own > >>container or > >> > lists. It does not need the device to mirror its own structure. > >> > >> As I said, I don’t care that much about the “device” container. What > >>would be really useful is to have the possibility to do e.g. this: > >> > >> virtual-node* [name] > >> name > >> if:interfaces > >> ... > >> > >> to support the use case where all virtual nodes are managed by the same > >>NETCONF/RESTCONF server. > >> > >> Lada > >> > >> > > >> > > >> > > >> > Lada > >> > > >> > Andy > >> > > >> > > >> > > > >> > > > >> > > > >> > > Lada > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > > > >> > > > Andy > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > >>wrote: > >> > > > > >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > >> > > > > > >> > > > > Hi, > >> > > > > > >> > > > > after listening to the presentation of > >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > >>wondering > >> > > > > whether the solution chosen for Y34 is really useful. > >> > > > > > >> > > > > The draft states they want to reuse ietf-interfaces but their > >>tree in > >> > > > > fact is > >> > > > > > >> > > > > +--rw device > >> > > > > +--rw info > >> > > > > | +--rw device-type? enumeration > >> > > > > +--rw hardware > >> > > > > +--rw interfaces > >> > > > > | +--rw interface* [name] > >> > > > > | ... > >> > > > > +--rw qos > >> > > > > > >> > > > > So the "interfaces" container is no more a top-level node. > >>There are > >> > > > > three possible options: > >> > > > > > >> > > > > 1. Change the ietf-interfaces module. > >> > > > > 2. Replicate its contents in another module. > >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted > >>at a > >> > > > > given data node. > >> > > > > > >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 > >>but it > >> > > > > seems it is not so because it doesn't specify a concrete data > >>model > >> > > > > that's allowed at a given location. > >> > > > > > >> > > > > On the other hand, the only real contribution of "anydata" over > >>"anyxml" > >> > > > > is that is doesn't permit mixed content in XML, which is IMO > >>not much. > >> > > > > > >> > > > > I know Y34 was already closed but I think it is more important > >>to do > >> > > > > things right before YANG 1.1 becomes an RFC. > >> > > > > > >> > > > > What I want to propose is this: > >> > > > > > >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate > >>"anyxml" (but > >> > > > > keep it for backward compatibility). > >> > > > > >> > > > s/Rename/Introduce/ > >> > > > > >> > > > > > >> > > > > - Introduce a new statement and data node type, e.g. "root", > >>that will > >> > > > > extend the schema tree starting from that data node with a > >>precisely > >> > > > > specified data model. The specification can be same or similar > >>as > >> > > > > in yang-library. > >> > > > > > >> > > > > I believe there are other use cases in the existing modules. For > >> > > > > example, the ietf-routing module could simply define the data > >>model for > >> > > > > a single routing instance (i.e. without "routing-instance" list > >>at the > >> > > > > top), and it can be then used without changes on simple > >>devices, and > >> > > > > more complex router implementations can graft it as a subtree > >>under > >> > > > > "routing-instance", "networking-instance" or whatever. > >> > > > > > >> > > > > Lada > >> > > > > > >> > > > > -- > >> > > > > 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 > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > 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 > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Jul 26 13:41: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 C5DF81A00A1 for ; Sun, 26 Jul 2015 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_210=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 GytPFlt6hPYY for ; Sun, 26 Jul 2015 13:40:56 -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 7D7311A0078 for ; Sun, 26 Jul 2015 13:40:55 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so41761936lbb.3 for ; Sun, 26 Jul 2015 13:40: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=KBiWe6KPXB7A4g8U7IobIpt1WkW5pZMFsb0nA6csx/8=; b=RW+JQFJKSTRRvW1S6fmesDeuteISnnV/nCLLfUHkIBes7WVFwXBaLQfwJ894FQNhH9 2TuWs4P/fhJ4huFTlPj8RPHPJ8FXcs1iqiEKQugXgZ+qQc56SbOp+0g566mLS9gpM/eC pUiqX5+bhttUzjbF5z0Frla07SG6TrVkovBvIa/zbfsbBbxCgYJSeFUAn3fFUZV4U5tG KybMdTeFEt2c2SwiJBvEJzxjW9TZ99WLWMqI7fmwVxP+MYzOTWksNhyjQuVYMQeC9f8m S9GbpNBXVCp8OWvv9aBIe+/bphm/JeEYPc6TWenjYGK/0JJ6XTIHT866gKXEvGWEy+Su jaFA== X-Gm-Message-State: ALoCoQlsTbWQ3xSMC4T3wGaQ9IhURFvx5CS2Mh/mh21G4V1waH4TQG1mBFknmHlyzWt2Jo/QAryJ MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr23680481lab.38.1437943253997; Sun, 26 Jul 2015 13:40:53 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 13:40:53 -0700 (PDT) In-Reply-To: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> Date: Sun, 26 Jul 2015 13:40:53 -0700 Message-ID: From: Andy Bierman To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=089e01176905dcb6b3051bcd407b Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Sun, 26 Jul 2015 20:40:59 -0000 --089e01176905dcb6b3051bcd407b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Acee, I agree that "Relocatable YANG" would be very useful, and have been thinking about the problem for awhile. I think the key is to precisely define a protocol-independent document root for each of the various YANG XPath contexts. In most cases the expression can be automatically relocated to an ancestor root. For the rest, a YANG mechanism is needed to tell the compiler to force evaluation on the old docroot (not the new docroot ancestor). Andy On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) wrote= : > I think being able to place a given model anywhere in the device tree > would be useful and this would allow a model to be rooted in different > locations on different devices. Similarly, we=E2=80=99d need the ability = to prefix > XPATH references to data nodes in the model with the root. > Thanks, > Acee > > On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > j.schoenwaelder@jacobs-university.de> wrote: > > >Lada, > > > >Y34 is closed and I have not seen any new argument here that indicates > >we made a major mistake with the resolution of Y34. As such, Y34 > >remains closed. > > > >If you want to discuss new ideas to relocate or "symlink" data models, > >please do so in a separate thread. (And no, we do not accept new > >issues for YANG 1.1 either at this point in time.) > > > >/js > > > >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > >> > >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka > >>wrote: > >> > > >> > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka > >>wrote: > >> > > > >> > > > On 20 Jul 2015, at 14:55, Andy Bierman > wrote: > >> > > > > >> > > > Hi, > >> > > > > >> > > > Can you explain why we need 2 broken anyxmls? > >> > > > (The original and a synonym?) The whole point of > >> > > > anydata is that it does not have XML cruft in it. > >> > > > >> > > Yes, I understand this was your main priority. For implementors > >>using off-the-shelf XML parsers and tools the XML cruft is not an issue > >>at all. > >> > > > >> > > > >> > > yes it is an issue. > >> > > We need something to model a container full of arbitrary YANG data > >>nodes. > >> > > This is something that can be applied to the contents of a > >>datastore. > >> > > >> > anyxml can do that, too. > >> > > >> > > >> > the WG already decided it can't. > >> > The extra XML PIs, etc. are not accepted by all servers, remember? > >> > There is no use for the extra stuff in the datastore. > >> > I don't see why we need 2 anyxml constructs that are not > >> > supported by the industry. One is already too many. > >> > >> I agree, but this is what we are going to have. My proposal was to hav= e > >>just one with two different names. > >> > >> > > >> > > >> > > > >> > > > >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/= =E2=80=A6 > >>with no (YANG) schema available. My only complaint to =E2=80=9Canyxml= =E2=80=9D has > >>always been that it is a misnomer for encodings other than XML. > >> > > > >> > > The message encoding on the wire is not the same issue > >> > > as the contents of a datastore. Our server stores its own > >> > > internal data structures. XML, JSON, CBOR are just message > >> > > encoding formats between client and server. The datastore > >> > > is not encoded in any of these formats. > >> > > >> > The payload of anyxml needn=E2=80=99t directly map to a data subtree= in the > >>usual sense. > >> > > >> > that's precisely the difference between anyxml and anydata. > >> > The anydata node MUST map directly into data subtrees. > >> > >> If the server doesn=E2=80=99t know the YANG data model at run time (wh= ich is > >>possible) then it cannot do it - for instance, it cannot properly map > >>module names to namespace URI or handle lists. > >> > >> > > >> > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > I also don't get the value of a single top-level node called > >>'device' > >> > > > that every YANG model on the planet is supposed to augment. > >> > > > Can you explain why a protocol operation to retrieve the > >> > > > document root (/) is not sufficient for the top-level node? > >> > > > >> > > I don=E2=80=99t intend to defend their model, the more serious pro= blem IMO > >>is that a model for a single device/function may be needed in another > >>device that hosts many virtualised devices/functions of the former type= . > >>We don=E2=80=99t have a good solution for this rather typical situation= . > >> > > > >> > > But a single container called "whatever" provides no such > >>aggregation. > >> > > You would need a list for that. And the NMS might have multiple > >> > > layers of hierarchy to represent various aggregations. The NP > >> > > container called "device" is not helpful for aggregation. > >> > > >> > The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D no= de would be like > >>a mount point in a Unix filesystem. > >> > > >> > > >> > Are you saying all data on a device needs to be in a top-level list > >>called 'device' > >> > because an NMS might exist that wants to have the datastores from > >>lots of devices? > >> > As Martin pointed out several times, the NMS can make its own > >>container or > >> > lists. It does not need the device to mirror its own structure. > >> > >> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevice=E2= =80=9D container. What > >>would be really useful is to have the possibility to do e.g. this: > >> > >> virtual-node* [name] > >> name > >> if:interfaces > >> ... > >> > >> to support the use case where all virtual nodes are managed by the sam= e > >>NETCONF/RESTCONF server. > >> > >> Lada > >> > >> > > >> > > >> > > >> > Lada > >> > > >> > Andy > >> > > >> > > >> > > > >> > > > >> > > > >> > > Lada > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > > > >> > > > Andy > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > >>wrote: > >> > > > > >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka > wrote: > >> > > > > > >> > > > > Hi, > >> > > > > > >> > > > > after listening to the presentation of > >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > >>wondering > >> > > > > whether the solution chosen for Y34 is really useful. > >> > > > > > >> > > > > The draft states they want to reuse ietf-interfaces but their > >>tree in > >> > > > > fact is > >> > > > > > >> > > > > +--rw device > >> > > > > +--rw info > >> > > > > | +--rw device-type? enumeration > >> > > > > +--rw hardware > >> > > > > +--rw interfaces > >> > > > > | +--rw interface* [name] > >> > > > > | ... > >> > > > > +--rw qos > >> > > > > > >> > > > > So the "interfaces" container is no more a top-level node. > >>There are > >> > > > > three possible options: > >> > > > > > >> > > > > 1. Change the ietf-interfaces module. > >> > > > > 2. Replicate its contents in another module. > >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted > >>at a > >> > > > > given data node. > >> > > > > > >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #= 3 > >>but it > >> > > > > seems it is not so because it doesn't specify a concrete data > >>model > >> > > > > that's allowed at a given location. > >> > > > > > >> > > > > On the other hand, the only real contribution of "anydata" ove= r > >>"anyxml" > >> > > > > is that is doesn't permit mixed content in XML, which is IMO > >>not much. > >> > > > > > >> > > > > I know Y34 was already closed but I think it is more important > >>to do > >> > > > > things right before YANG 1.1 becomes an RFC. > >> > > > > > >> > > > > What I want to propose is this: > >> > > > > > >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate > >>"anyxml" (but > >> > > > > keep it for backward compatibility). > >> > > > > >> > > > s/Rename/Introduce/ > >> > > > > >> > > > > > >> > > > > - Introduce a new statement and data node type, e.g. "root", > >>that will > >> > > > > extend the schema tree starting from that data node with a > >>precisely > >> > > > > specified data model. The specification can be same or simila= r > >>as > >> > > > > in yang-library. > >> > > > > > >> > > > > I believe there are other use cases in the existing modules. F= or > >> > > > > example, the ietf-routing module could simply define the data > >>model for > >> > > > > a single routing instance (i.e. without "routing-instance" lis= t > >>at the > >> > > > > top), and it can be then used without changes on simple > >>devices, and > >> > > > > more complex router implementations can graft it as a subtree > >>under > >> > > > > "routing-instance", "networking-instance" or whatever. > >> > > > > > >> > > > > Lada > >> > > > > > >> > > > > -- > >> > > > > 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 > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > 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 > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e01176905dcb6b3051bcd407b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Acee,

I agree that "Relocatable= YANG" would be very useful, and have been
thinking about th= e problem for awhile.=C2=A0 I think the key is to precisely
defin= e a protocol-independent document root for each of the various
YA= NG XPath contexts.=C2=A0 In most cases the expression can be
auto= matically relocated to an ancestor root.=C2=A0 For the rest, a
YA= NG mechanism is needed to tell the compiler to force evaluation
o= n the old docroot (not the new docroot ancestor).

=
Andy

On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (= acee) <acee@cisco.com> wrote:
I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we=E2=80=99d need the ability to= prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"=
<netmod-bounces@ietf.org = on behalf of
j.schoenwaelder@jac= obs-university.de> wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates<= br> >we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" dat= a models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>
>> > On 20 Jul 2015, at 19:29, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> >
>> > > On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)=C2=A0 The whole point= of
>> > > > anydata is that it does not have XML cruft in it. >> > >
>> > > Yes, I understand this was your main priority. For imple= mentors
>>using off-the-shelf XML parsers and tools the XML cruft is not an i= ssue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary= YANG data
>>nodes.
>> > > This is something that can be applied to the contents of= a
>>datastore.
>> >
>> > anyxml can do that, too.
>> >
>> >
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, reme= mber?
>> > There is no use for the extra stuff in the datastore.
>> >=C2=A0 I don't see why we need 2 anyxml constructs that ar= e not
>> > supported by the industry.=C2=A0 One is already too many.
>>
>> I agree, but this is what we are going to have. My proposal was to= have
>>just one with two different names.
>>
>> >
>> >
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/= JSON/CBOR/=E2=80=A6
>>with no (YANG) schema available. My only complaint to =E2=80=9Canyx= ml=E2=80=9D has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue >> > > as the contents of a datastore.=C2=A0 Our server stores = its own
>> > > internal data structures.=C2=A0 XML, JSON, CBOR are just= message
>> > > encoding formats between client and server.=C2=A0 The da= tastore
>> > > is not encoded in any of these formats.
>> >
>> > The payload of anyxml needn=E2=80=99t directly map to a data = subtree in the
>>usual sense.
>> >
>> > that's precisely the difference between anyxml and anydat= a.
>> > The anydata node MUST map directly into data subtrees.
>>
>> If the server doesn=E2=80=99t know the YANG data model at run time= (which is
>>possible) then it cannot do it - for instance, it cannot properly m= ap
>>module names to namespace URI or handle lists.
>>
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-leve= l node called
>>'device'
>> > > > that every YANG model on the planet is supposed to = augment.
>> > > > Can you explain why a protocol operation to retriev= e the
>> > > > document root (/) is not sufficient for the top-lev= el node?
>> > >
>> > > I don=E2=80=99t intend to defend their model, the more s= erious problem IMO
>>is that a model for a single device/function may be needed in anoth= er
>>device that hosts many virtualised devices/functions of the former = type.
>>We don=E2=80=99t have a good solution for this rather typical situa= tion.
>> > >
>> > > But a single container called "whatever" provi= des no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have m= ultiple
>> > > layers of hierarchy to represent various aggregations.= =C2=A0 The NP
>> > > container called "device" is not helpful for a= ggregation.
>> >
>> > The parent node can be a list as well. The =E2=80=9Croot=E2= =80=9D node would be like
>>a mount point in a Unix filesystem.
>> >
>> >
>> > Are you saying all data on a device needs to be in a top-leve= l list
>>called 'device'
>> > because an NMS might exist that=C2=A0 wants to have the datas= tores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own=
>>container or
>> > lists.=C2=A0 It does not need the device to mirror its own st= ructure.
>>
>> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevic= e=E2=80=9D container. What
>>would be really useful is to have the possibility to do e.g. this:<= br> >>
>> virtual-node* [name]
>>=C2=A0 =C2=A0 =C2=A0name
>>=C2=A0 =C2=A0 =C2=A0if:interfaces
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>
>> to support the use case where all virtual nodes are managed by the= same
>>NETCONF/RESTCONF server.
>>
>> Lada
>>
>> >
>> >
>> >
>> > Lada
>> >
>> > Andy
>> >
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > Andy
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka &l= t;lhotka@nic.cz>
>>wrote:
>> > > >
>> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <= lhotka@nic.cz> wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > after listening to the presentation of
>> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG= session, I am
>>wondering
>> > > > > whether the solution chosen for Y34 is really = useful.
>> > > > >
>> > > > > The draft states they want to reuse ietf-inter= faces but their
>>tree in
>> > > > > fact is
>> > > > >
>> > > > >=C2=A0 =C2=A0+--rw device
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--r= w device-type?=C2=A0 =C2=A0enumeration
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardwa= re
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interf= aces
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--r= w interface* [name]
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0...
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos >> > > > >
>> > > > > So the "interfaces" container is no = more a top-level node.
>>There are
>> > > > > three possible options:
>> > > > >
>> > > > > 1. Change the ietf-interfaces module.
>> > > > > 2. Replicate its contents in another module. >> > > > > 3. Extend YANG so that a *specific* schema tre= e can be grafted
>>at a
>> > > > >=C2=A0 =C2=A0given data node.
>> > > > >
>> > > > > IMO #1 & #2 are really bad. I thought Y34-= 04 was essentially #3
>>but it
>> > > > > seems it is not so because it doesn't spec= ify a concrete data
>>model
>> > > > > that's allowed at a given location.
>> > > > >
>> > > > > On the other hand, the only real contribution = of "anydata" over
>>"anyxml"
>> > > > > is that is doesn't permit mixed content in= XML, which is IMO
>>not much.
>> > > > >
>> > > > > I know Y34 was already closed but I think it i= s more important
>>to do
>> > > > > things right before YANG 1.1 becomes an RFC. >> > > > >
>> > > > > What I want to propose is this:
>> > > > >
>> > > > > - Rename "anydata" as a synonym to &= quot;anyxml", and deprecate
>>"anyxml" (but
>> > > > >=C2=A0 keep it for backward compatibility).
>> > > >
>> > > > s/Rename/Introduce/
>> > > >
>> > > > >
>> > > > > - Introduce a new statement and data node type= , e.g. "root",
>>that will
>> > > > >=C2=A0 extend the schema tree starting from tha= t data node with a
>>precisely
>> > > > >=C2=A0 specified data model. The specification = can be same or similar
>>as
>> > > > >=C2=A0 in yang-library.
>> > > > >
>> > > > > I believe there are other use cases in the exi= sting modules. For
>> > > > > example, the ietf-routing module could simply = define the data
>>model for
>> > > > > a single routing instance (i.e. without "= routing-instance" list
>>at the
>> > > > > top), and it can be then used without changes = on simple
>>devices, and
>> > > > > more complex router implementations can graft = it as a subtree
>>under
>> > > > > "routing-instance", "networking= -instance" or whatever.
>> > > > >
>> > > > > Lada
>> > > > >
>> > > > > --
>> > > > > Ladislav Lhotka, CZ.NIC Labs
>> > > > > PGP Key ID: E74E8C0C
>> > > > >
>> > > > > ______________________________________________= _
>> > > > > netmod mailing list
>> > > > > netmod@ietf= .org
>> > > > > https://www.ietf.org/mailma= n/listinfo/netmod
>> > > >
>> > > > --
>> > > > Ladislav Lhotka, CZ.NIC Labs
>> > > > PGP Key ID: E74E8C0C
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > netmod mailing list
>> > > > netmod@ietf.org<= /a>
>> > > > https://www.ietf.org/mailman/lis= tinfo/netmod
>> > > >
>> > >
>> > > --
>> > > Ladislav Lhotka, CZ.NIC Labs
>> > > PGP Key ID: E74E8C0C
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/net= mod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Un= iversity Bremen gGmbH
>Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 = | 28759 Bremen | Germany
>Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

--089e01176905dcb6b3051bcd407b-- From nobody Sun Jul 26 17:51:18 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 CE60E1A8AC8 for ; Sun, 26 Jul 2015 17:51:16 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 ziY_DeA1yA7D for ; Sun, 26 Jul 2015 17:51:13 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id E55031A8AE3 for ; Sun, 26 Jul 2015 17:51:12 -0700 (PDT) Received: (qmail 21666 invoked by uid 0); 27 Jul 2015 00:51:10 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 27 Jul 2015 00:51:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id xJX21q00R2SSUrH01JX5Xe; Mon, 27 Jul 2015 00:31:10 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=iEhmfDb7q88A:10 a=-NfooI8aBGcA:10 a=vQEP83iCr2YA:10 a=zOBTXjUuO1YA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=xskcdSivAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=Yx1QUpVTdxQn7yjD8d4A:9 a=r2jBWgr86mXuoFFh:21 a=Fd06OBNT_8VVjzpo:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=6k9Ilfv6AqDcV5tVJLAA:9 a=ycAKzIVwgTpvFgKL:21 a=btN7zV2LdX08VH87:21 a=a4aXaKcMd8q79A7V:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=izpoXznO5Kirv/tsgmHVdv6i5YvOuLCR6yeNOYryTRg=; b=YbmjggY0xMQT7P5etRqBQgb4048NYqwpVPGRDvovSe0ll7JpjBAKyPi7IBSifiOXjbOe5L0lePZ1QE07zD7JM2frzaI3llk1iCo+kbTP54DZmEOO63l7Fm6f2fO8r2vc; Received: from [172.56.37.4] (port=26572 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZJWJq-0000NM-MN; Sun, 26 Jul 2015 18:31:03 -0600 From: Lou Berger To: Andy Bierman , "Acee Lindem (acee)" Date: Sun, 26 Jul 2015 20:31:01 -0400 Message-ID: <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14ecceb7beb5e16281843597be8" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.37.4 authed with lberger@labn.net} Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 27 Jul 2015 00:51:17 -0000 This is a multi-part message in MIME format. ------------14ecceb7beb5e16281843597be8 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Andy, Have you thought through implications / possibilities for existing models, e.g., interfaces? Thanks, Lou On July 26, 2015 4:41:32 PM Andy Bierman wrote: > Hi Acee, > > I agree that "Relocatable YANG" would be very useful, and have been > thinking about the problem for awhile. I think the key is to precisely > define a protocol-independent document root for each of the various > YANG XPath contexts. In most cases the expression can be > automatically relocated to an ancestor root. For the rest, a > YANG mechanism is needed to tell the compiler to force evaluation > on the old docroot (not the new docroot ancestor). > > > Andy > > > On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) wrote: > > > I think being able to place a given model anywhere in the device tree > > would be useful and this would allow a model to be rooted in different > > locations on different devices. Similarly, we’d need the ability to prefix > > XPATH references to data nodes in the model with the root. > > Thanks, > > Acee > > > > On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > >Lada, > > > > > >Y34 is closed and I have not seen any new argument here that indicates > > >we made a major mistake with the resolution of Y34. As such, Y34 > > >remains closed. > > > > > >If you want to discuss new ideas to relocate or "symlink" data models, > > >please do so in a separate thread. (And no, we do not accept new > > >issues for YANG 1.1 either at this point in time.) > > > > > >/js > > > > > >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > > >> > > >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: > > >> > > > >> > > > >> > > > >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka > > >>wrote: > > >> > > > >> > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka > > >>wrote: > > >> > > > > >> > > > On 20 Jul 2015, at 14:55, Andy Bierman > > wrote: > > >> > > > > > >> > > > Hi, > > >> > > > > > >> > > > Can you explain why we need 2 broken anyxmls? > > >> > > > (The original and a synonym?) The whole point of > > >> > > > anydata is that it does not have XML cruft in it. > > >> > > > > >> > > Yes, I understand this was your main priority. For implementors > > >>using off-the-shelf XML parsers and tools the XML cruft is not an issue > > >>at all. > > >> > > > > >> > > > > >> > > yes it is an issue. > > >> > > We need something to model a container full of arbitrary YANG data > > >>nodes. > > >> > > This is something that can be applied to the contents of a > > >>datastore. > > >> > > > >> > anyxml can do that, too. > > >> > > > >> > > > >> > the WG already decided it can't. > > >> > The extra XML PIs, etc. are not accepted by all servers, remember? > > >> > There is no use for the extra stuff in the datastore. > > >> > I don't see why we need 2 anyxml constructs that are not > > >> > supported by the industry. One is already too many. > > >> > > >> I agree, but this is what we are going to have. My proposal was to have > > >>just one with two different names. > > >> > > >> > > > >> > > > >> > > > > >> > > > > >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… > > >>with no (YANG) schema available. My only complaint to “anyxml” has > > >>always been that it is a misnomer for encodings other than XML. > > >> > > > > >> > > The message encoding on the wire is not the same issue > > >> > > as the contents of a datastore. Our server stores its own > > >> > > internal data structures. XML, JSON, CBOR are just message > > >> > > encoding formats between client and server. The datastore > > >> > > is not encoded in any of these formats. > > >> > > > >> > The payload of anyxml needn’t directly map to a data subtree in the > > >>usual sense. > > >> > > > >> > that's precisely the difference between anyxml and anydata. > > >> > The anydata node MUST map directly into data subtrees. > > >> > > >> If the server doesn’t know the YANG data model at run time (which is > > >>possible) then it cannot do it - for instance, it cannot properly map > > >>module names to namespace URI or handle lists. > > >> > > >> > > > >> > > > >> > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > >> > > > I also don't get the value of a single top-level node called > > >>'device' > > >> > > > that every YANG model on the planet is supposed to augment. > > >> > > > Can you explain why a protocol operation to retrieve the > > >> > > > document root (/) is not sufficient for the top-level node? > > >> > > > > >> > > I don’t intend to defend their model, the more serious problem IMO > > >>is that a model for a single device/function may be needed in another > > >>device that hosts many virtualised devices/functions of the former type. > > >>We don’t have a good solution for this rather typical situation. > > >> > > > > >> > > But a single container called "whatever" provides no such > > >>aggregation. > > >> > > You would need a list for that. And the NMS might have multiple > > >> > > layers of hierarchy to represent various aggregations. The NP > > >> > > container called "device" is not helpful for aggregation. > > >> > > > >> > The parent node can be a list as well. The “root” node would be like > > >>a mount point in a Unix filesystem. > > >> > > > >> > > > >> > Are you saying all data on a device needs to be in a top-level list > > >>called 'device' > > >> > because an NMS might exist that wants to have the datastores from > > >>lots of devices? > > >> > As Martin pointed out several times, the NMS can make its own > > >>container or > > >> > lists. It does not need the device to mirror its own structure. > > >> > > >> As I said, I don’t care that much about the “device” container. What > > >>would be really useful is to have the possibility to do e.g. this: > > >> > > >> virtual-node* [name] > > >> name > > >> if:interfaces > > >> ... > > >> > > >> to support the use case where all virtual nodes are managed by the same > > >>NETCONF/RESTCONF server. > > >> > > >> Lada > > >> > > >> > > > >> > > > >> > > > >> > Lada > > >> > > > >> > Andy > > >> > > > >> > > > >> > > > > >> > > > > >> > > > > >> > > Lada > > >> > > > > >> > > > > >> > > Andy > > >> > > > > >> > > > > >> > > > > > >> > > > Andy > > >> > > > > > >> > > > > > >> > > > > > >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > > >>wrote: > > >> > > > > > >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka > > wrote: > > >> > > > > > > >> > > > > Hi, > > >> > > > > > > >> > > > > after listening to the presentation of > > >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > > >>wondering > > >> > > > > whether the solution chosen for Y34 is really useful. > > >> > > > > > > >> > > > > The draft states they want to reuse ietf-interfaces but their > > >>tree in > > >> > > > > fact is > > >> > > > > > > >> > > > > +--rw device > > >> > > > > +--rw info > > >> > > > > | +--rw device-type? enumeration > > >> > > > > +--rw hardware > > >> > > > > +--rw interfaces > > >> > > > > | +--rw interface* [name] > > >> > > > > | ... > > >> > > > > +--rw qos > > >> > > > > > > >> > > > > So the "interfaces" container is no more a top-level node. > > >>There are > > >> > > > > three possible options: > > >> > > > > > > >> > > > > 1. Change the ietf-interfaces module. > > >> > > > > 2. Replicate its contents in another module. > > >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted > > >>at a > > >> > > > > given data node. > > >> > > > > > > >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 > > >>but it > > >> > > > > seems it is not so because it doesn't specify a concrete data > > >>model > > >> > > > > that's allowed at a given location. > > >> > > > > > > >> > > > > On the other hand, the only real contribution of "anydata" over > > >>"anyxml" > > >> > > > > is that is doesn't permit mixed content in XML, which is IMO > > >>not much. > > >> > > > > > > >> > > > > I know Y34 was already closed but I think it is more important > > >>to do > > >> > > > > things right before YANG 1.1 becomes an RFC. > > >> > > > > > > >> > > > > What I want to propose is this: > > >> > > > > > > >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate > > >>"anyxml" (but > > >> > > > > keep it for backward compatibility). > > >> > > > > > >> > > > s/Rename/Introduce/ > > >> > > > > > >> > > > > > > >> > > > > - Introduce a new statement and data node type, e.g. "root", > > >>that will > > >> > > > > extend the schema tree starting from that data node with a > > >>precisely > > >> > > > > specified data model. The specification can be same or similar > > >>as > > >> > > > > in yang-library. > > >> > > > > > > >> > > > > I believe there are other use cases in the existing modules. For > > >> > > > > example, the ietf-routing module could simply define the data > > >>model for > > >> > > > > a single routing instance (i.e. without "routing-instance" list > > >>at the > > >> > > > > top), and it can be then used without changes on simple > > >>devices, and > > >> > > > > more complex router implementations can graft it as a subtree > > >>under > > >> > > > > "routing-instance", "networking-instance" or whatever. > > >> > > > > > > >> > > > > Lada > > >> > > > > > > >> > > > > -- > > >> > > > > 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 > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > _______________________________________________ > > >> > > > 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 > > >> > > > >> > > > >> > > > >> > > > >> > _______________________________________________ > > >> > 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 > > > > > >-- > > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > >Fax: +49 421 200 3103 > > > > > >_______________________________________________ > > >netmod mailing list > > >netmod@ietf.org > > >https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > ---------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------14ecceb7beb5e16281843597be8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Andy,

Have you thought through implications / possibilities for existing models,  e.g., interfaces?

Thanks,
Lou

On July 26, 2015 4:41:32 PM Andy Bierman <andy@yumaworks.com> wrote:

Hi Acee,

I agree that "Relocatable YANG" would be very useful, and have been
thinking about the problem for awhile.  I think the key is to precisely
define a protocol-independent document root for each of the various
YANG XPath contexts.  In most cases the expression can be
automatically relocated to an ancestor root.  For the rest, a
YANG mechanism is needed to tell the compiler to force evaluation
on the old docroot (not the new docroot ancestor).


Andy


On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we’d need the ability to prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
<netmod-bounces@ietf.org on behalf of
j.schoenwaelder@jacobs-university.de> wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates
>we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>
>> > On 20 Jul 2015, at 19:29, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> >
>> > > On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)  The whole point of
>> > > > anydata is that it does not have XML cruft in it.
>> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> >
>> > anyxml can do that, too.
>> >
>> >
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >  I don't see why we need 2 anyxml constructs that are not
>> > supported by the industry.  One is already too many.
>>
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>>
>> >
>> >
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
>>with no (YANG) schema available. My only complaint to “anyxml” has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue
>> > > as the contents of a datastore.  Our server stores its own
>> > > internal data structures.  XML, JSON, CBOR are just message
>> > > encoding formats between client and server.  The datastore
>> > > is not encoded in any of these formats.
>> >
>> > The payload of anyxml needn’t directly map to a data subtree in the
>>usual sense.
>> >
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>>
>> If the server doesn’t know the YANG data model at run time (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>>
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don’t intend to defend their model, the more serious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don’t have a good solution for this rather typical situation.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.  The NP
>> > > container called "device" is not helpful for aggregation.
>> >
>> > The parent node can be a list as well. The “root” node would be like
>>a mount point in a Unix filesystem.
>> >
>> >
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that  wants to have the datastores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own
>>container or
>> > lists.  It does not need the device to mirror its own structure.
>>
>> As I said, I don’t care that much about the “device” container. What
>>would be really useful is to have the possibility to do e.g. this:
>>
>> virtual-node* [name]
>>     name
>>     if:interfaces
>>         ...
>>
>> to support the use case where all virtual nodes are managed by the same
>>NETCONF/RESTCONF server.
>>
>> Lada
>>
>> >
>> >
>> >
>> > Lada
>> >
>> > Andy
>> >
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > Andy
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > > >
>> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > after listening to the presentation of
>> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am
>>wondering
>> > > > > whether the solution chosen for Y34 is really useful.
>> > > > >
>> > > > > The draft states they want to reuse ietf-interfaces but their
>>tree in
>> > > > > fact is
>> > > > >
>> > > > >   +--rw device
>> > > > >          +--rw info
>> > > > >          |  +--rw device-type?   enumeration
>> > > > >          +--rw hardware
>> > > > >          +--rw interfaces
>> > > > >          |  +--rw interface* [name]
>> > > > >          |     ...
>> > > > >          +--rw qos
>> > > > >
>> > > > > So the "interfaces" container is no more a top-level node.
>>There are
>> > > > > three possible options:
>> > > > >
>> > > > > 1. Change the ietf-interfaces module.
>> > > > > 2. Replicate its contents in another module.
>> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted
>>at a
>> > > > >   given data node.
>> > > > >
>> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3
>>but it
>> > > > > seems it is not so because it doesn't specify a concrete data
>>model
>> > > > > that's allowed at a given location.
>> > > > >
>> > > > > On the other hand, the only real contribution of "anydata" over
>>"anyxml"
>> > > > > is that is doesn't permit mixed content in XML, which is IMO
>>not much.
>> > > > >
>> > > > > I know Y34 was already closed but I think it is more important
>>to do
>> > > > > things right before YANG 1.1 becomes an RFC.
>> > > > >
>> > > > > What I want to propose is this:
>> > > > >
>> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate
>>"anyxml" (but
>> > > > >  keep it for backward compatibility).
>> > > >
>> > > > s/Rename/Introduce/
>> > > >
>> > > > >
>> > > > > - Introduce a new statement and data node type, e.g. "root",
>>that will
>> > > > >  extend the schema tree starting from that data node with a
>>precisely
>> > > > >  specified data model. The specification can be same or similar
>>as
>> > > > >  in yang-library.
>> > > > >
>> > > > > I believe there are other use cases in the existing modules. For
>> > > > > example, the ietf-routing module could simply define the data
>>model for
>> > > > > a single routing instance (i.e. without "routing-instance" list
>>at the
>> > > > > top), and it can be then used without changes on simple
>>devices, and
>> > > > > more complex router implementations can graft it as a subtree
>>under
>> > > > > "routing-instance", "networking-instance" or whatever.
>> > > > >
>> > > > > Lada
>> > > > >
>> > > > > --
>> > > > > 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
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > 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
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

------------14ecceb7beb5e16281843597be8-- From nobody Sun Jul 26 23:18:48 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 993CA1A8A5E for ; Sun, 26 Jul 2015 23:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_210=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 LxKHfkV_vVR2 for ; Sun, 26 Jul 2015 23:18:41 -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 971BC1A8A59 for ; Sun, 26 Jul 2015 23:18:40 -0700 (PDT) Received: by lafd3 with SMTP id d3so32282588laf.1 for ; Sun, 26 Jul 2015 23:18:38 -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=7/FFs/OGaDcC9cN0adjHovEOVKk4W/oXLDTO1Pe9Mr0=; b=VWekNz9/aqv6itC3yuLNr4c3ZzduiYiv4Mq7Gp4W1bvMixtmGMkcmdWNSKJVTTRlOJ Mw7vbpO597XlEugDTDFHbF9QlZodoIJQJGXwKaFTdqrcBO8N3wNKgw5UfVCe05bxrxw4 y3q+xwZKY+LeBuTRO6TMCo9nLuP/vGkI+vbaZCbYWZi0z7JLCnF4QOGqMCAyQx+g+2xk VIX+6A6+Ee0HTxtp2MZnSVstoZxwDspNWtwIwkmXoejV4/OvbNxbs0DsdtbDgbUs+idR 7Csx7dCNVhi1mzGGrjuSs4qf2pf63VCTHPq05GvdQ/MhQno92/mK2X9ROmGQFLEJsxG+ HQyg== X-Gm-Message-State: ALoCoQlEIqGLDbwY3YOLSW8YgJnQfZDQTsRlLec7Wqk7ZswjFx1x73ipM3dDGKc2Y7DmhYG5hKu6 MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr25538623laa.33.1437977918786; Sun, 26 Jul 2015 23:18:38 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Jul 2015 23:18:38 -0700 (PDT) In-Reply-To: <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Sun, 26 Jul 2015 23:18:38 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c27cf00b69c0051bd55388 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 27 Jul 2015 06:18:45 -0000 --001a11c27cf00b69c0051bd55388 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger wrote: > Andy, > > Have you thought through implications / possibilities for existing > models, e.g., interfaces? > First we have to define various forms of relocation. (1) Aggregation of datastores The simplest form is aggregation. It is possible to define a YANG container that is a conceptual document root, such that the set of child nodes matches the set of top-level YANG data nodes supported by the server. A YANG extension can mark a YANG container or anyxml as a docroot. Yuma-based code has been doing this for years with a YANG extension called "root" http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html (See Y34-04) The node below is a document root: container servers { list server { key addr; leaf addr { type inet:ip-address; } anydata config { ncx:root; } } } XPath evaluation requires certain inputs, including a context node and a document root. The 'root' extension tells the tool to use the node with the 'root' tag as the document root, when processing XPath within its descendant nodes. Without the tag, the XPath parser would use 'servers' as the document root, which is incorrect for the relocated YANG nodes within 'config'. (2) Move a subtree within the datastore This is the hardest (of course) because it involves moving the context node not the document root. It is possible for tools to get fooled about the intent of the XPath writer. Basically the tool has to remember the original context node, and do some complicated data manipulation, processing [4] Step in XPath 1.0. Multiple relocated subtrees gets even more complicated. It may be possible to come up with some guidelines on XPath to avoid. Basically any Xpath that selects nodes by specific names can be relocated automatically. Nodes selected by function, wildcard, axis, etc. will not be so easy. > Thanks, > Lou > Andy > On July 26, 2015 4:41:32 PM Andy Bierman wrote: > >> Hi Acee, >> >> I agree that "Relocatable YANG" would be very useful, and have been >> thinking about the problem for awhile. I think the key is to precisely >> define a protocol-independent document root for each of the various >> YANG XPath contexts. In most cases the expression can be >> automatically relocated to an ancestor root. For the rest, a >> YANG mechanism is needed to tell the compiler to force evaluation >> on the old docroot (not the new docroot ancestor). >> >> >> Andy >> >> >> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) >> wrote: >> >>> I think being able to place a given model anywhere in the device tree >>> would be useful and this would allow a model to be rooted in different >>> locations on different devices. Similarly, we=E2=80=99d need the abilit= y to >>> prefix >>> XPATH references to data nodes in the model with the root. >>> Thanks, >>> Acee >>> >>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" >>> >> j.schoenwaelder@jacobs-university.de> wrote: >>> >>> >Lada, >>> > >>> >Y34 is closed and I have not seen any new argument here that indicates >>> >we made a major mistake with the resolution of Y34. As such, Y34 >>> >remains closed. >>> > >>> >If you want to discuss new ideas to relocate or "symlink" data models, >>> >please do so in a separate thread. (And no, we do not accept new >>> >issues for YANG 1.1 either at this point in time.) >>> > >>> >/js >>> > >>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: >>> >> >>> >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka >>> >>wrote: >>> >> > >>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman >>> wrote: >>> >> > > >>> >> > > >>> >> > > >>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka >>> >>wrote: >>> >> > > >>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman >>> wrote: >>> >> > > > >>> >> > > > Hi, >>> >> > > > >>> >> > > > Can you explain why we need 2 broken anyxmls? >>> >> > > > (The original and a synonym?) The whole point of >>> >> > > > anydata is that it does not have XML cruft in it. >>> >> > > >>> >> > > Yes, I understand this was your main priority. For implementors >>> >>using off-the-shelf XML parsers and tools the XML cruft is not an iss= ue >>> >>at all. >>> >> > > >>> >> > > >>> >> > > yes it is an issue. >>> >> > > We need something to model a container full of arbitrary YANG da= ta >>> >>nodes. >>> >> > > This is something that can be applied to the contents of a >>> >>datastore. >>> >> > >>> >> > anyxml can do that, too. >>> >> > >>> >> > >>> >> > the WG already decided it can't. >>> >> > The extra XML PIs, etc. are not accepted by all servers, remember? >>> >> > There is no use for the extra stuff in the datastore. >>> >> > I don't see why we need 2 anyxml constructs that are not >>> >> > supported by the industry. One is already too many. >>> >> >>> >> I agree, but this is what we are going to have. My proposal was to >>> have >>> >>just one with two different names. >>> >> >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > Anyway, I believe there are use cases for arbitrary >>> XML/JSON/CBOR/=E2=80=A6 >>> >>with no (YANG) schema available. My only complaint to =E2=80=9Canyxml= =E2=80=9D has >>> >>always been that it is a misnomer for encodings other than XML. >>> >> > > >>> >> > > The message encoding on the wire is not the same issue >>> >> > > as the contents of a datastore. Our server stores its own >>> >> > > internal data structures. XML, JSON, CBOR are just message >>> >> > > encoding formats between client and server. The datastore >>> >> > > is not encoded in any of these formats. >>> >> > >>> >> > The payload of anyxml needn=E2=80=99t directly map to a data subtr= ee in the >>> >>usual sense. >>> >> > >>> >> > that's precisely the difference between anyxml and anydata. >>> >> > The anydata node MUST map directly into data subtrees. >>> >> >>> >> If the server doesn=E2=80=99t know the YANG data model at run time (= which is >>> >>possible) then it cannot do it - for instance, it cannot properly map >>> >>module names to namespace URI or handle lists. >>> >> >>> >> > >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > I also don't get the value of a single top-level node called >>> >>'device' >>> >> > > > that every YANG model on the planet is supposed to augment. >>> >> > > > Can you explain why a protocol operation to retrieve the >>> >> > > > document root (/) is not sufficient for the top-level node? >>> >> > > >>> >> > > I don=E2=80=99t intend to defend their model, the more serious p= roblem IMO >>> >>is that a model for a single device/function may be needed in another >>> >>device that hosts many virtualised devices/functions of the former >>> type. >>> >>We don=E2=80=99t have a good solution for this rather typical situati= on. >>> >> > > >>> >> > > But a single container called "whatever" provides no such >>> >>aggregation. >>> >> > > You would need a list for that. And the NMS might have multiple >>> >> > > layers of hierarchy to represent various aggregations. The NP >>> >> > > container called "device" is not helpful for aggregation. >>> >> > >>> >> > The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D = node would be like >>> >>a mount point in a Unix filesystem. >>> >> > >>> >> > >>> >> > Are you saying all data on a device needs to be in a top-level lis= t >>> >>called 'device' >>> >> > because an NMS might exist that wants to have the datastores from >>> >>lots of devices? >>> >> > As Martin pointed out several times, the NMS can make its own >>> >>container or >>> >> > lists. It does not need the device to mirror its own structure. >>> >> >>> >> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevice= =E2=80=9D container. What >>> >>would be really useful is to have the possibility to do e.g. this: >>> >> >>> >> virtual-node* [name] >>> >> name >>> >> if:interfaces >>> >> ... >>> >> >>> >> to support the use case where all virtual nodes are managed by the >>> same >>> >>NETCONF/RESTCONF server. >>> >> >>> >> Lada >>> >> >>> >> > >>> >> > >>> >> > >>> >> > Lada >>> >> > >>> >> > Andy >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > Lada >>> >> > > >>> >> > > >>> >> > > Andy >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > Andy >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka >> > >>> >>wrote: >>> >> > > > >>> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka >>> wrote: >>> >> > > > > >>> >> > > > > Hi, >>> >> > > > > >>> >> > > > > after listening to the presentation of >>> >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am >>> >>wondering >>> >> > > > > whether the solution chosen for Y34 is really useful. >>> >> > > > > >>> >> > > > > The draft states they want to reuse ietf-interfaces but thei= r >>> >>tree in >>> >> > > > > fact is >>> >> > > > > >>> >> > > > > +--rw device >>> >> > > > > +--rw info >>> >> > > > > | +--rw device-type? enumeration >>> >> > > > > +--rw hardware >>> >> > > > > +--rw interfaces >>> >> > > > > | +--rw interface* [name] >>> >> > > > > | ... >>> >> > > > > +--rw qos >>> >> > > > > >>> >> > > > > So the "interfaces" container is no more a top-level node. >>> >>There are >>> >> > > > > three possible options: >>> >> > > > > >>> >> > > > > 1. Change the ietf-interfaces module. >>> >> > > > > 2. Replicate its contents in another module. >>> >> > > > > 3. Extend YANG so that a *specific* schema tree can be graft= ed >>> >>at a >>> >> > > > > given data node. >>> >> > > > > >>> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially >>> #3 >>> >>but it >>> >> > > > > seems it is not so because it doesn't specify a concrete dat= a >>> >>model >>> >> > > > > that's allowed at a given location. >>> >> > > > > >>> >> > > > > On the other hand, the only real contribution of "anydata" >>> over >>> >>"anyxml" >>> >> > > > > is that is doesn't permit mixed content in XML, which is IMO >>> >>not much. >>> >> > > > > >>> >> > > > > I know Y34 was already closed but I think it is more importa= nt >>> >>to do >>> >> > > > > things right before YANG 1.1 becomes an RFC. >>> >> > > > > >>> >> > > > > What I want to propose is this: >>> >> > > > > >>> >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate >>> >>"anyxml" (but >>> >> > > > > keep it for backward compatibility). >>> >> > > > >>> >> > > > s/Rename/Introduce/ >>> >> > > > >>> >> > > > > >>> >> > > > > - Introduce a new statement and data node type, e.g. "root", >>> >>that will >>> >> > > > > extend the schema tree starting from that data node with a >>> >>precisely >>> >> > > > > specified data model. The specification can be same or >>> similar >>> >>as >>> >> > > > > in yang-library. >>> >> > > > > >>> >> > > > > I believe there are other use cases in the existing modules. >>> For >>> >> > > > > example, the ietf-routing module could simply define the dat= a >>> >>model for >>> >> > > > > a single routing instance (i.e. without "routing-instance" >>> list >>> >>at the >>> >> > > > > top), and it can be then used without changes on simple >>> >>devices, and >>> >> > > > > more complex router implementations can graft it as a subtre= e >>> >>under >>> >> > > > > "routing-instance", "networking-instance" or whatever. >>> >> > > > > >>> >> > > > > Lada >>> >> > > > > >>> >> > > > > -- >>> >> > > > > 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 >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > _______________________________________________ >>> >> > > > 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 >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > 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 >>> > >>> >-- >>> >Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> >Fax: +49 421 200 3103 >>> > >>> >_______________________________________________ >>> >netmod mailing list >>> >netmod@ietf.org >>> >https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> --001a11c27cf00b69c0051bd55388 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <lberger@labn.net> wrote:

Andy,

Have you thought through implications / possibilities for existing models,=C2=A0 e.g., interfaces?



First w= e have to define various forms of relocation.

(1) = Aggregation of datastores

The simplest form is agg= regation.
It is possible to define a YANG container that is a con= ceptual
document root, such that the set of child nodes matches t= he set
of top-level YANG data nodes supported by the server.

A YANG extension can mark a YANG container or anyxml a= s a docroot.
Yuma-based code has been doing this for years with a= YANG
extension called "root"


(See Y34-04)

The &l= t;config> node below is a document root:

contai= ner servers {
=C2=A0 list server {
=C2=A0 =C2=A0 =C2=A0= key addr;
=C2=A0 =C2=A0 =C2=A0 leaf addr { type inet:ip-address;= }
=C2=A0 =C2=A0 =C2=A0 anydata config {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ncx:root;
=C2=A0 =C2=A0 =C2=A0 }
= =C2=A0 }
}

XPath evaluation requires cer= tain inputs, including a context node
and a document root.=C2=A0 = The 'root' extension tells the tool to use
the node with = the 'root' tag as the document root, when processing
XPat= h within its descendant nodes. Without the tag, the XPath parser
= would use 'servers' as the document root, which is incorrect for
the relocated YANG nodes within 'config'.

(2) Move a subtree within the datastore

Th= is is the hardest (of course) because it involves moving the context node
not the document root. It is possible for tools to get fooled abou= t the intent
of the XPath writer.=C2=A0 Basically the tool has to= remember the original context node,
and do some complicated data= manipulation, processing [4] Step
in XPath 1.0.=C2=A0 Multiple r= elocated subtrees gets even more complicated.

It m= ay be possible to come up with some guidelines on XPath to avoid.
Basically any Xpath that selects nodes by specific names can be
= relocated automatically.=C2=A0 Nodes selected by function, wildcard, axis, = etc.
will not be so easy.
=C2=A0

=C2=A0

Thanks,
Lou



An= dy
=C2=A0

On July 26, 2015 4:41:32 PM Andy Bierman <andy@yumaworks.com> wrote:

Hi Ac= ee,

I agree that "Relocatable YANG" would be very useful, and have been
thinking about the problem for awhile.=C2=A0 I think the key is to precisely
define = a protocol-independent document root for each of the various
YANG XPath contexts.=C2=A0 In most cases the expression can be
automatically relocated to an ancestor root.=C2=A0 For the res= t, a
YANG mechanism is needed to tell the compiler to force evaluation
on the old docroot (not the new docroot ancestor).


Andy


On Sun, Jul= 26, 2015 at 10:49 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we=E2=80=99d need the ability to= prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"=
<netmod-bou= nces@ietf.org on behalf of
j= .schoenwaelder@jacobs-university.de> wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates<= br> >we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>
>> > On 20 Jul 2015, at 19:29, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> >
>> > > On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote= :
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com>= wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)=C2=A0 The whole point= of
>> > > > anydata is that it does not have XML cruft in it. >> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> >
>> > anyxml can do that, too.
>> >
>> >
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >=C2=A0 I don't see why we need 2 anyxml constructs that ar= e not
>> > supported by the industry.=C2=A0 One is already too many.
>>
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>>
>> >
>> >
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2=80=A6
>>with no (YANG) schema available. My only complaint to =E2=80=9Canyx= ml=E2=80=9D has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue >> > > as the contents of a datastore.=C2=A0 Our server stores = its own
>> > > internal data structures.=C2=A0 XML, JSON, CBOR are just message
>> > > encoding formats between client and server.=C2=A0 The datastore
>> > > is not encoded in any of these formats.
>> >
>> > The payload of anyxml needn=E2=80=99t directly map to a data = subtree in the
>>usual sense.
>> >
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>>
>> If the server doesn=E2=80=99t know the YANG data model at run time= (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>>
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don=E2=80=99t intend to defend their model, the more s= erious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don=E2=80=99t have a good solution for this rather typical situa= tion.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.= =C2=A0 The NP
>> > > container called "device" is not helpful for aggregation.
>> >
>> > The parent node can be a list as well. The =E2=80=9Croot=E2= =80=9D node would be like
>>a mount point in a Unix filesystem.
>> >
>> >
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that=C2=A0 wants to have the datas= tores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own=
>>container or
>> > lists.=C2=A0 It does not need the device to mirror its own structure.
>>
>> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevic= e=E2=80=9D container. What
>>would be really useful is to have the possibility to do e.g. this:<= br> >>
>> virtual-node* [name]
>>=C2=A0 =C2=A0 =C2=A0name
>>=C2=A0 =C2=A0 =C2=A0if:interfaces
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>
>> to support the use case where all virtual nodes are managed by the same
>>NETCONF/RESTCONF server.
>>
>> Lada
>>
>> >
>> >
>> >
>> > Lada
>> >
>> > Andy
>> >
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > Andy
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz>= ;
>>wrote:
>> > > >
>> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz>= ; wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > after listening to the presentation of
>> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am
>>wondering
>> > > > > whether the solution chosen for Y34 is really useful.
>> > > > >
>> > > > > The draft states they want to reuse ietf-interfaces but their
>>tree in
>> > > > > fact is
>> > > > >
>> > > > >=C2=A0 =C2=A0+--rw device
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--r= w device-type?=C2=A0 =C2=A0enumeration
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardwa= re
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interf= aces
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--r= w interface* [name]
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0...
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos >> > > > >
>> > > > > So the "interfaces" container is no more a top-level node.
>>There are
>> > > > > three possible options:
>> > > > >
>> > > > > 1. Change the ietf-interfaces module.
>> > > > > 2. Replicate its contents in another module. >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted
>>at a
>> > > > >=C2=A0 =C2=A0given data node.
>> > > > >
>> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3
>>but it
>> > > > > seems it is not so because it doesn't specify a concrete data
>>model
>> > > > > that's allowed at a given location.
>> > > > >
>> > > > > On the other hand, the only real contribution of "anydata" over
>>"anyxml"
>> > > > > is that is doesn't permit mixed content in XML, which is IMO
>>not much.
>> > > > >
>> > > > > I know Y34 was already closed but I think it is more important
>>to do
>> > > > > things right before YANG 1.1 becomes an RFC. >> > > > >
>> > > > > What I want to propose is this:
>> > > > >
>> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate
>>"anyxml" (but
>> > > > >=C2=A0 keep it for backward compatibility).
>> > > >
>> > > > s/Rename/Introduce/
>> > > >
>> > > > >
>> > > > > - Introduce a new statement and data node type, e.g. "root",
>>that will
>> > > > >=C2=A0 extend the schema tree starting from tha= t data node with a
>>precisely
>> > > > >=C2=A0 specified data model. The specification = can be same or similar
>>as
>> > > > >=C2=A0 in yang-library.
>> > > > >
>> > > > > I believe there are other use cases in the existing modules. For
>> > > > > example, the ietf-routing module could simply define the data
>>model for
>> > > > > a single routing instance (i.e. without "routing-instance" list
>>at the
>> > > > > top), and it can be then used without changes on simple
>>devices, and
>> > > > > more complex router implementations can graft it as a subtree
>>under
>> > > > > "routing-instance", "networking-instance" or whatever.
>> > > > >
>> > > > > Lada
>> > > > >
>> > > > > --
>> > > > > Ladislav Lhotka, CZ.NIC Labs
>> > > > > PGP Key ID: E74E8C0C
>> > > > >
>> > > > > _______________________________________________
>> > > > > netmod mailing list
>> > > > > netmod@ietf.org
>> > > > > https://www.ietf.org/mailma= n/listinfo/netmod
>> > > >
>> > > > --
>> > > > Ladislav Lhotka, CZ.NIC Labs
>> > > > PGP Key ID: E74E8C0C
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > netmod mailing list
>> > > > netmod@ietf.org
>> > > > https://www.ietf.org/mailman/lis= tinfo/netmod
>> > > >
>> > >
>> > > --
>> > > Ladislav Lhotka, CZ.NIC Labs
>> > > PGP Key ID: E74E8C0C
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/net= mod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Un= iversity Bremen gGmbH
>Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 = | 28759 Bremen | Germany
>Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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


--001a11c27cf00b69c0051bd55388-- From nobody Mon Jul 27 00:17: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 BBD801ACE41 for ; Mon, 27 Jul 2015 00:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, 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 hSNtyKXUF4r4 for ; Mon, 27 Jul 2015 00:17:32 -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 606A71ACE3D for ; Mon, 27 Jul 2015 00:17:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7320E1107; Mon, 27 Jul 2015 09:17:30 +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 48r6NLRYc7ad; Mon, 27 Jul 2015 09:17: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, 27 Jul 2015 09:17:29 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46E292003C; Mon, 27 Jul 2015 09:17:30 +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 AzCM7kDZRIz7; Mon, 27 Jul 2015 09:17:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7DE620039; Mon, 27 Jul 2015 09:17:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7D58735ED4ED; Mon, 27 Jul 2015 09:17:27 +0200 (CEST) Date: Mon, 27 Jul 2015 09:17:26 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150727071726.GA9579@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150726071623.GB16276@elstar.local> <20150726114715.GA17078@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Mon, 27 Jul 2015 07:17:34 -0000 On Sun, Jul 26, 2015 at 11:17:19AM -0700, Andy Bierman wrote: > > I know there is not agreement on the solution yet. Exactly. And hence talking about YANG 1.2 is simply confusing. > That is why it is an open issue. I2RS does not have to present NETMOD WG > with a solution (even though they did present an acceptable solution). If you mean duplication of data models and data model specific merge rules then I have trouble to believe this is desriable nor does it seem to reflect what other proprietary ephemeral datastore implementations do. > In order for I2RS to have the YANG validation rules that meet its > use-cases, new text is needed. This text needs to be associated > with data-nodes. > > I like the proposed solution of config=true,ephemeral,false > because I know none of the existing text inadvertently applies > to ephemeral nodes. I would prefer to have ephemeral datastore support as an extension; not all uses of YANG (perhaps even a big majority) require to describe ephemeral datastores. > I do not think YANG is fully specified wrt/ datastores because > operational state and ephemeral nodes are not separated. > An ephemeral datastore (and perhaps operational datastore) > are needed to solve this problem. But depending on the solution selected, this may not require any changes to 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 Mon Jul 27 07:54: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 84FB01B2E6A for ; Mon, 27 Jul 2015 07:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_210=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 d7DWMhJwJYP1 for ; Mon, 27 Jul 2015 07:53:59 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2918B1B2E54 for ; Mon, 27 Jul 2015 07:53:59 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 7A8CF1CC0730; Mon, 27 Jul 2015 16:53:55 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "Acee Lindem \(acee\)" In-Reply-To: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 27 Jul 2015 16:53:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 27 Jul 2015 14:54:02 -0000 Andy Bierman writes: > Hi Acee, > > I agree that "Relocatable YANG" would be very useful, and have been > thinking about the problem for awhile. I think the key is to precisely > define a protocol-independent document root for each of the various > YANG XPath contexts. In most cases the expression can be > automatically relocated to an ancestor root. For the rest, a > YANG mechanism is needed to tell the compiler to force evaluation > on the old docroot (not the new docroot ancestor). The authors of DSDL family of schema languages realized the utility of "compound documents" and designed NVDL language for their validation. It's nicely described here: http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compoun= d.html I think most of NVDL concepts could be applied to YANG, too, perhaps as a part of external conformance specification. As for XPath expressions, the specification could map each namespace to a root that has to be prepended to every absolute XPath that starts with a node from the given namespace. The existing modules could then continue to work unchanged. Actually, this is being done already now: when validating an XML document containing YANG-modelled data, an initial segment often needs to be prepended to all absolute XPaths, e.g. "/nc:rpc-reply/nc:data", depending on the type of the document. Lada > > > Andy > > > On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) wro= te: > >> I think being able to place a given model anywhere in the device tree >> would be useful and this would allow a model to be rooted in different >> locations on different devices. Similarly, we=E2=80=99d need the ability= to prefix >> XPATH references to data nodes in the model with the root. >> Thanks, >> Acee >> >> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" >> > j.schoenwaelder@jacobs-university.de> wrote: >> >> >Lada, >> > >> >Y34 is closed and I have not seen any new argument here that indicates >> >we made a major mistake with the resolution of Y34. As such, Y34 >> >remains closed. >> > >> >If you want to discuss new ideas to relocate or "symlink" data models, >> >please do so in a separate thread. (And no, we do not accept new >> >issues for YANG 1.1 either at this point in time.) >> > >> >/js >> > >> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: >> >> >> >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka >> >>wrote: >> >> > >> >> > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: >> >> > > >> >> > > >> >> > > >> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka >> >>wrote: >> >> > > >> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman >> wrote: >> >> > > > >> >> > > > Hi, >> >> > > > >> >> > > > Can you explain why we need 2 broken anyxmls? >> >> > > > (The original and a synonym?) The whole point of >> >> > > > anydata is that it does not have XML cruft in it. >> >> > > >> >> > > Yes, I understand this was your main priority. For implementors >> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue >> >>at all. >> >> > > >> >> > > >> >> > > yes it is an issue. >> >> > > We need something to model a container full of arbitrary YANG data >> >>nodes. >> >> > > This is something that can be applied to the contents of a >> >>datastore. >> >> > >> >> > anyxml can do that, too. >> >> > >> >> > >> >> > the WG already decided it can't. >> >> > The extra XML PIs, etc. are not accepted by all servers, remember? >> >> > There is no use for the extra stuff in the datastore. >> >> > I don't see why we need 2 anyxml constructs that are not >> >> > supported by the industry. One is already too many. >> >> >> >> I agree, but this is what we are going to have. My proposal was to ha= ve >> >>just one with two different names. >> >> >> >> > >> >> > >> >> > > >> >> > > >> >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR= /=E2=80=A6 >> >>with no (YANG) schema available. My only complaint to =E2=80=9Canyxml= =E2=80=9D has >> >>always been that it is a misnomer for encodings other than XML. >> >> > > >> >> > > The message encoding on the wire is not the same issue >> >> > > as the contents of a datastore. Our server stores its own >> >> > > internal data structures. XML, JSON, CBOR are just message >> >> > > encoding formats between client and server. The datastore >> >> > > is not encoded in any of these formats. >> >> > >> >> > The payload of anyxml needn=E2=80=99t directly map to a data subtre= e in the >> >>usual sense. >> >> > >> >> > that's precisely the difference between anyxml and anydata. >> >> > The anydata node MUST map directly into data subtrees. >> >> >> >> If the server doesn=E2=80=99t know the YANG data model at run time (w= hich is >> >>possible) then it cannot do it - for instance, it cannot properly map >> >>module names to namespace URI or handle lists. >> >> >> >> > >> >> > >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > > >> >> > > > I also don't get the value of a single top-level node called >> >>'device' >> >> > > > that every YANG model on the planet is supposed to augment. >> >> > > > Can you explain why a protocol operation to retrieve the >> >> > > > document root (/) is not sufficient for the top-level node? >> >> > > >> >> > > I don=E2=80=99t intend to defend their model, the more serious pr= oblem IMO >> >>is that a model for a single device/function may be needed in another >> >>device that hosts many virtualised devices/functions of the former typ= e. >> >>We don=E2=80=99t have a good solution for this rather typical situatio= n. >> >> > > >> >> > > But a single container called "whatever" provides no such >> >>aggregation. >> >> > > You would need a list for that. And the NMS might have multiple >> >> > > layers of hierarchy to represent various aggregations. The NP >> >> > > container called "device" is not helpful for aggregation. >> >> > >> >> > The parent node can be a list as well. The =E2=80=9Croot=E2=80=9D n= ode would be like >> >>a mount point in a Unix filesystem. >> >> > >> >> > >> >> > Are you saying all data on a device needs to be in a top-level list >> >>called 'device' >> >> > because an NMS might exist that wants to have the datastores from >> >>lots of devices? >> >> > As Martin pointed out several times, the NMS can make its own >> >>container or >> >> > lists. It does not need the device to mirror its own structure. >> >> >> >> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevice= =E2=80=9D container. What >> >>would be really useful is to have the possibility to do e.g. this: >> >> >> >> virtual-node* [name] >> >> name >> >> if:interfaces >> >> ... >> >> >> >> to support the use case where all virtual nodes are managed by the sa= me >> >>NETCONF/RESTCONF server. >> >> >> >> Lada >> >> >> >> > >> >> > >> >> > >> >> > Lada >> >> > >> >> > Andy >> >> > >> >> > >> >> > > >> >> > > >> >> > > >> >> > > Lada >> >> > > >> >> > > >> >> > > Andy >> >> > > >> >> > > >> >> > > > >> >> > > > Andy >> >> > > > >> >> > > > >> >> > > > >> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka >> >>wrote: >> >> > > > >> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka >> wrote: >> >> > > > > >> >> > > > > Hi, >> >> > > > > >> >> > > > > after listening to the presentation of >> >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am >> >>wondering >> >> > > > > whether the solution chosen for Y34 is really useful. >> >> > > > > >> >> > > > > The draft states they want to reuse ietf-interfaces but their >> >>tree in >> >> > > > > fact is >> >> > > > > >> >> > > > > +--rw device >> >> > > > > +--rw info >> >> > > > > | +--rw device-type? enumeration >> >> > > > > +--rw hardware >> >> > > > > +--rw interfaces >> >> > > > > | +--rw interface* [name] >> >> > > > > | ... >> >> > > > > +--rw qos >> >> > > > > >> >> > > > > So the "interfaces" container is no more a top-level node. >> >>There are >> >> > > > > three possible options: >> >> > > > > >> >> > > > > 1. Change the ietf-interfaces module. >> >> > > > > 2. Replicate its contents in another module. >> >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted >> >>at a >> >> > > > > given data node. >> >> > > > > >> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially = #3 >> >>but it >> >> > > > > seems it is not so because it doesn't specify a concrete data >> >>model >> >> > > > > that's allowed at a given location. >> >> > > > > >> >> > > > > On the other hand, the only real contribution of "anydata" ov= er >> >>"anyxml" >> >> > > > > is that is doesn't permit mixed content in XML, which is IMO >> >>not much. >> >> > > > > >> >> > > > > I know Y34 was already closed but I think it is more important >> >>to do >> >> > > > > things right before YANG 1.1 becomes an RFC. >> >> > > > > >> >> > > > > What I want to propose is this: >> >> > > > > >> >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate >> >>"anyxml" (but >> >> > > > > keep it for backward compatibility). >> >> > > > >> >> > > > s/Rename/Introduce/ >> >> > > > >> >> > > > > >> >> > > > > - Introduce a new statement and data node type, e.g. "root", >> >>that will >> >> > > > > extend the schema tree starting from that data node with a >> >>precisely >> >> > > > > specified data model. The specification can be same or simil= ar >> >>as >> >> > > > > in yang-library. >> >> > > > > >> >> > > > > I believe there are other use cases in the existing modules. = For >> >> > > > > example, the ietf-routing module could simply define the data >> >>model for >> >> > > > > a single routing instance (i.e. without "routing-instance" li= st >> >>at the >> >> > > > > top), and it can be then used without changes on simple >> >>devices, and >> >> > > > > more complex router implementations can graft it as a subtree >> >>under >> >> > > > > "routing-instance", "networking-instance" or whatever. >> >> > > > > >> >> > > > > Lada >> >> > > > > >> >> > > > > -- >> >> > > > > 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 >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > _______________________________________________ >> >> > > > 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 >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> > >> >-- >> >Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >Fax: +49 421 200 3103 >> > >> >_______________________________________________ >> >netmod mailing list >> >netmod@ietf.org >> >https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 27 08:10:09 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 D3CEB1B2E6A for ; Mon, 27 Jul 2015 08:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_210=0.6, 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 W3WFJgJw7zlT for ; Mon, 27 Jul 2015 08:10:04 -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 8B4CE1B2E77 for ; Mon, 27 Jul 2015 08:09:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C771114C; Mon, 27 Jul 2015 17:09: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 46-p55C3f13Q; Mon, 27 Jul 2015 17:09: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; Mon, 27 Jul 2015 17:09:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F1C32003A; Mon, 27 Jul 2015 17:09:53 +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 IAlaVpHEVCa5; Mon, 27 Jul 2015 17:09:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B7CB2003D; Mon, 27 Jul 2015 17:09:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1571A35F39F1; Mon, 27 Jul 2015 17:09:46 +0200 (CEST) Date: Mon, 27 Jul 2015 17:09:46 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20150727150946.GA9620@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Ladislav Lhotka , NETMOD Working Group References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@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 Working Group Subject: Re: [netmod] Y34 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: Mon, 27 Jul 2015 15:10:08 -0000 I do not think this is Y34. Relocating YANG models is not covered by any of the YANG 1.1 issues as far as I can tell and issue submission closed about a year ago. I suggest someone interested in such a feature writes an independent I-D. And as usual, the devil is in the details. /js On Sun, Jul 26, 2015 at 05:49:17PM +0000, Acee Lindem (acee) wrote: > I think being able to place a given model anywhere in the device tree > would be useful and this would allow a model to be rooted in different > locations on different devices. Similarly, we’d need the ability to prefix > XPATH references to data nodes in the model with the root. > Thanks, > Acee > > On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > j.schoenwaelder@jacobs-university.de> wrote: > > >Lada, > > > >Y34 is closed and I have not seen any new argument here that indicates > >we made a major mistake with the resolution of Y34. As such, Y34 > >remains closed. > > > >If you want to discuss new ideas to relocate or "symlink" data models, > >please do so in a separate thread. (And no, we do not accept new > >issues for YANG 1.1 either at this point in time.) > > > >/js > > > >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > >> > >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka > >>wrote: > >> > > >> > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka > >>wrote: > >> > > > >> > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > >> > > > > >> > > > Hi, > >> > > > > >> > > > Can you explain why we need 2 broken anyxmls? > >> > > > (The original and a synonym?) The whole point of > >> > > > anydata is that it does not have XML cruft in it. > >> > > > >> > > Yes, I understand this was your main priority. For implementors > >>using off-the-shelf XML parsers and tools the XML cruft is not an issue > >>at all. > >> > > > >> > > > >> > > yes it is an issue. > >> > > We need something to model a container full of arbitrary YANG data > >>nodes. > >> > > This is something that can be applied to the contents of a > >>datastore. > >> > > >> > anyxml can do that, too. > >> > > >> > > >> > the WG already decided it can't. > >> > The extra XML PIs, etc. are not accepted by all servers, remember? > >> > There is no use for the extra stuff in the datastore. > >> > I don't see why we need 2 anyxml constructs that are not > >> > supported by the industry. One is already too many. > >> > >> I agree, but this is what we are going to have. My proposal was to have > >>just one with two different names. > >> > >> > > >> > > >> > > > >> > > > >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… > >>with no (YANG) schema available. My only complaint to “anyxml” has > >>always been that it is a misnomer for encodings other than XML. > >> > > > >> > > The message encoding on the wire is not the same issue > >> > > as the contents of a datastore. Our server stores its own > >> > > internal data structures. XML, JSON, CBOR are just message > >> > > encoding formats between client and server. The datastore > >> > > is not encoded in any of these formats. > >> > > >> > The payload of anyxml needn’t directly map to a data subtree in the > >>usual sense. > >> > > >> > that's precisely the difference between anyxml and anydata. > >> > The anydata node MUST map directly into data subtrees. > >> > >> If the server doesn’t know the YANG data model at run time (which is > >>possible) then it cannot do it - for instance, it cannot properly map > >>module names to namespace URI or handle lists. > >> > >> > > >> > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > I also don't get the value of a single top-level node called > >>'device' > >> > > > that every YANG model on the planet is supposed to augment. > >> > > > Can you explain why a protocol operation to retrieve the > >> > > > document root (/) is not sufficient for the top-level node? > >> > > > >> > > I don’t intend to defend their model, the more serious problem IMO > >>is that a model for a single device/function may be needed in another > >>device that hosts many virtualised devices/functions of the former type. > >>We don’t have a good solution for this rather typical situation. > >> > > > >> > > But a single container called "whatever" provides no such > >>aggregation. > >> > > You would need a list for that. And the NMS might have multiple > >> > > layers of hierarchy to represent various aggregations. The NP > >> > > container called "device" is not helpful for aggregation. > >> > > >> > The parent node can be a list as well. The “root” node would be like > >>a mount point in a Unix filesystem. > >> > > >> > > >> > Are you saying all data on a device needs to be in a top-level list > >>called 'device' > >> > because an NMS might exist that wants to have the datastores from > >>lots of devices? > >> > As Martin pointed out several times, the NMS can make its own > >>container or > >> > lists. It does not need the device to mirror its own structure. > >> > >> As I said, I don’t care that much about the “device” container. What > >>would be really useful is to have the possibility to do e.g. this: > >> > >> virtual-node* [name] > >> name > >> if:interfaces > >> ... > >> > >> to support the use case where all virtual nodes are managed by the same > >>NETCONF/RESTCONF server. > >> > >> Lada > >> > >> > > >> > > >> > > >> > Lada > >> > > >> > Andy > >> > > >> > > >> > > > >> > > > >> > > > >> > > Lada > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > > > >> > > > Andy > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > >>wrote: > >> > > > > >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > >> > > > > > >> > > > > Hi, > >> > > > > > >> > > > > after listening to the presentation of > >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > >>wondering > >> > > > > whether the solution chosen for Y34 is really useful. > >> > > > > > >> > > > > The draft states they want to reuse ietf-interfaces but their > >>tree in > >> > > > > fact is > >> > > > > > >> > > > > +--rw device > >> > > > > +--rw info > >> > > > > | +--rw device-type? enumeration > >> > > > > +--rw hardware > >> > > > > +--rw interfaces > >> > > > > | +--rw interface* [name] > >> > > > > | ... > >> > > > > +--rw qos > >> > > > > > >> > > > > So the "interfaces" container is no more a top-level node. > >>There are > >> > > > > three possible options: > >> > > > > > >> > > > > 1. Change the ietf-interfaces module. > >> > > > > 2. Replicate its contents in another module. > >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted > >>at a > >> > > > > given data node. > >> > > > > > >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 > >>but it > >> > > > > seems it is not so because it doesn't specify a concrete data > >>model > >> > > > > that's allowed at a given location. > >> > > > > > >> > > > > On the other hand, the only real contribution of "anydata" over > >>"anyxml" > >> > > > > is that is doesn't permit mixed content in XML, which is IMO > >>not much. > >> > > > > > >> > > > > I know Y34 was already closed but I think it is more important > >>to do > >> > > > > things right before YANG 1.1 becomes an RFC. > >> > > > > > >> > > > > What I want to propose is this: > >> > > > > > >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate > >>"anyxml" (but > >> > > > > keep it for backward compatibility). > >> > > > > >> > > > s/Rename/Introduce/ > >> > > > > >> > > > > > >> > > > > - Introduce a new statement and data node type, e.g. "root", > >>that will > >> > > > > extend the schema tree starting from that data node with a > >>precisely > >> > > > > specified data model. The specification can be same or similar > >>as > >> > > > > in yang-library. > >> > > > > > >> > > > > I believe there are other use cases in the existing modules. For > >> > > > > example, the ietf-routing module could simply define the data > >>model for > >> > > > > a single routing instance (i.e. without "routing-instance" list > >>at the > >> > > > > top), and it can be then used without changes on simple > >>devices, and > >> > > > > more complex router implementations can graft it as a subtree > >>under > >> > > > > "routing-instance", "networking-instance" or whatever. > >> > > > > > >> > > > > Lada > >> > > > > > >> > > > > -- > >> > > > > 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 > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > 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 > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > >-- > >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 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 27 08:19:23 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 675EE1B2E68 for ; Mon, 27 Jul 2015 08:19: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 YGUKw4qTermk for ; Mon, 27 Jul 2015 08:19: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 758C31A88CB for ; Mon, 27 Jul 2015 08:19: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 851D912EB; Mon, 27 Jul 2015 17:19: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 n0k8-b_VMK3x; Mon, 27 Jul 2015 17:19: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; Mon, 27 Jul 2015 17:19:16 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5AA812003C; Mon, 27 Jul 2015 17:19:17 +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 4hrNb9T9sOAz; Mon, 27 Jul 2015 17:19: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 D8AE72003A; Mon, 27 Jul 2015 17:19:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B07935F3A3D; Mon, 27 Jul 2015 17:19:13 +0200 (CEST) Date: Mon, 27 Jul 2015 17:19:13 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150727151913.GB9620@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150725082507.GA14481@elstar.local> <20150726072210.GC16276@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items 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: Mon, 27 Jul 2015 15:19:22 -0000 On Sun, Jul 26, 2015 at 10:12:01AM -0700, Andy Bierman wrote: > On Sun, Jul 26, 2015 at 12:22 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bierman wrote: > > > On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > This is the summary of the discussion of YANG 1.1 issue Y60 at the > > > > IETF 93 meeting in Prague: > > > > > > > > - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which > > > > will of course be interpreted according to the YANG 1.0 rules). > > > > > > I am not convinced this will be a good idea. > > > Obviously the compiler has to restrict 1.0 modules to 1.0 syntax, > > > but the corner-case semantics that have been clarified in 1.1 > > > SHOULD be followed if a 1.1 module imports 1.0, even for augment. > > > > > > > Please provide concrete examples what breaks if we allow to import > > YANG 1.0 modules (using 1.0 semantics). > > I have not reviewed the YANG 1.1 draft. I am waiting for WGLC. > But from memory -- > > -- the handling of default prefixes in XPath in groupings was clarified > -- the handling of ".." wrt/ top-level nodes in XPath in groupings > was clarified > -- I think auto-numbering of enum/bit was clarified > > I guess there is no new text to add here. > If this is unspecified in 1.0 then handling it the same as 1.1 is OK > So are you saying there is no problem with importing a YANG 1.0 module? > > > If this is the case then I think the "restconf-media-type" hack > > > should be a real YANG statement. The reason it is an extension > > > is because YANG is NETCONF-only. A real statement > > > could support augments and deviations. > > > > > > Just removing a sentence from the abstract is not going to fix all > > > NETCONF-specific details in YANG. (Just ask Lada ;-) It is > > > not going to make YANG correct for RESTCONF. > > > > Please provide concrete examples where YANG is incorrect for RESTCONF. > > The XPath context for operations are not correct. > They are not mentioned in RESTCONF at all. > > YANG 1.1 should define the XPath contexts in a reusable way, > instead of in terms of NETCONF messages. NETCONF, RESTCONF, > and CoMI can all map these reusable contexts to their specific protocol > messages. > Lada has been saying this for a long time. > I assume you refer to section 6.4.1 in draft-ietf-netmod-rfc6020bis-06.txt. Can you or Lada rewrite it to be protocol agnostic? I guess the biggest challenge are the namespace declarations for protocols that do not use XML encoding. Anything else (except some wording changes)? > > > YANG will need to be modified for I2RS anyway. YANG 1.1 took > > > too long, and now I2RS is ready. I strongly object to the idea > > > of starting on 1.2 while 1.1 is still unpublished. > > > > Nobody proposed to work on YANG 1.2. > > A new statement would require the yang-version string to be changed again. > I do not think YANG extensions should be used for ephemeral state because > they are not extensible and (literally) not part of YANG. I can envision solutions that do not need YANG 1.1 changes or that could be done fine with extensions I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 27 09:08:56 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 731391B3019 for ; Mon, 27 Jul 2015 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 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, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_210=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, 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 ku93Aw6YI2BE for ; Mon, 27 Jul 2015 09:08:51 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id DB3531B3017 for ; Mon, 27 Jul 2015 09:08:50 -0700 (PDT) Received: (qmail 17404 invoked by uid 0); 27 Jul 2015 16:08:49 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 27 Jul 2015 16:08:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id xToe1q0022SSUrH01TohKv; Mon, 27 Jul 2015 09:48:41 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=iEhmfDb7q88A:10 a=-NfooI8aBGcA:10 a=xXAGOC3BesMA:10 a=zOBTXjUuO1YA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=xskcdSivAAAA:8 a=VvmPA7fAAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=j3Z76cjpAAAA:8 a=9c-Qbn3KMgTUvI6czwQA:9 a=uyK9UnAmj1RAeS0p:21 a=eckDGlSIZsuUW80D:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=utQ-ZuE7t14A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=6Vvf2oxolhLhYSQyWygA:9 a=5QZGiSW8Xgct2AEN:21 a=RxzQIy_FbMFo2OD6:21 a=SgXFyj_jPX00zX3_:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=BHqRInX3wrtT6x32QVFPSyclwOPaBF66r6F4G6UkdWM=; b=ZpKeOi2UN3X4MuvySKdoXEuogCHwl1GtvkNocHy0dXMKOunXuco0Qnr36Mfx/jjucPSPtPWj+Umkzbtj2BuZi0tDKRscDEl0pW++960YSkPtzq24dRPs56XXiJpiaZFI; Received: from [172.56.36.133] (port=46096 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZJkdq-0006gZ-9g; Mon, 27 Jul 2015 09:48:38 -0600 From: Lou Berger To: Andy Bierman Date: Mon, 27 Jul 2015 11:48:37 -0400 Message-ID: <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14ed033915d5e1628184306e730" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.36.133 authed with lberger@labn.net} Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 27 Jul 2015 16:08:55 -0000 This is a multi-part message in MIME format. ------------14ed033915d5e1628184306e730 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Andy, Thanks for the good information. (I'll followup off line a bit if that's okay.) Of course there's a small matter of getting something standardized. Lou On July 27, 2015 2:19:09 AM Andy Bierman wrote: > On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger wrote: > > > Andy, > > > > Have you thought through implications / possibilities for existing > > models, e.g., interfaces? > > > > > First we have to define various forms of relocation. > > (1) Aggregation of datastores > > The simplest form is aggregation. > It is possible to define a YANG container that is a conceptual > document root, such that the set of child nodes matches the set > of top-level YANG data nodes supported by the server. > > A YANG extension can mark a YANG container or anyxml as a docroot. > Yuma-based code has been doing this for years with a YANG > extension called "root" > > http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html > (See Y34-04) > > The node below is a document root: > > container servers { > list server { > key addr; > leaf addr { type inet:ip-address; } > anydata config { > ncx:root; > } > } > } > > XPath evaluation requires certain inputs, including a context node > and a document root. The 'root' extension tells the tool to use > the node with the 'root' tag as the document root, when processing > XPath within its descendant nodes. Without the tag, the XPath parser > would use 'servers' as the document root, which is incorrect for > the relocated YANG nodes within 'config'. > > (2) Move a subtree within the datastore > > This is the hardest (of course) because it involves moving the context node > not the document root. It is possible for tools to get fooled about the > intent > of the XPath writer. Basically the tool has to remember the original > context node, > and do some complicated data manipulation, processing [4] Step > in XPath 1.0. Multiple relocated subtrees gets even more complicated. > > It may be possible to come up with some guidelines on XPath to avoid. > Basically any Xpath that selects nodes by specific names can be > relocated automatically. Nodes selected by function, wildcard, axis, etc. > will not be so easy. > > > > > > Thanks, > > Lou > > > > > Andy > > > > On July 26, 2015 4:41:32 PM Andy Bierman wrote: > > > >> Hi Acee, > >> > >> I agree that "Relocatable YANG" would be very useful, and have been > >> thinking about the problem for awhile. I think the key is to precisely > >> define a protocol-independent document root for each of the various > >> YANG XPath contexts. In most cases the expression can be > >> automatically relocated to an ancestor root. For the rest, a > >> YANG mechanism is needed to tell the compiler to force evaluation > >> on the old docroot (not the new docroot ancestor). > >> > >> > >> Andy > >> > >> > >> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) > >> wrote: > >> > >>> I think being able to place a given model anywhere in the device tree > >>> would be useful and this would allow a model to be rooted in different > >>> locations on different devices. Similarly, we’d need the ability to > >>> prefix > >>> XPATH references to data nodes in the model with the root. > >>> Thanks, > >>> Acee > >>> > >>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > >>> >>> j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> >Lada, > >>> > > >>> >Y34 is closed and I have not seen any new argument here that indicates > >>> >we made a major mistake with the resolution of Y34. As such, Y34 > >>> >remains closed. > >>> > > >>> >If you want to discuss new ideas to relocate or "symlink" data models, > >>> >please do so in a separate thread. (And no, we do not accept new > >>> >issues for YANG 1.1 either at this point in time.) > >>> > > >>> >/js > >>> > > >>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: > >>> >> > >>> >> > On 20 Jul 2015, at 19:29, Andy Bierman wrote: > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka > >>> >>wrote: > >>> >> > > >>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman > >>> wrote: > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka > >>> >>wrote: > >>> >> > > > >>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman > >>> wrote: > >>> >> > > > > >>> >> > > > Hi, > >>> >> > > > > >>> >> > > > Can you explain why we need 2 broken anyxmls? > >>> >> > > > (The original and a synonym?) The whole point of > >>> >> > > > anydata is that it does not have XML cruft in it. > >>> >> > > > >>> >> > > Yes, I understand this was your main priority. For implementors > >>> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue > >>> >>at all. > >>> >> > > > >>> >> > > > >>> >> > > yes it is an issue. > >>> >> > > We need something to model a container full of arbitrary YANG data > >>> >>nodes. > >>> >> > > This is something that can be applied to the contents of a > >>> >>datastore. > >>> >> > > >>> >> > anyxml can do that, too. > >>> >> > > >>> >> > > >>> >> > the WG already decided it can't. > >>> >> > The extra XML PIs, etc. are not accepted by all servers, remember? > >>> >> > There is no use for the extra stuff in the datastore. > >>> >> > I don't see why we need 2 anyxml constructs that are not > >>> >> > supported by the industry. One is already too many. > >>> >> > >>> >> I agree, but this is what we are going to have. My proposal was to > >>> have > >>> >>just one with two different names. > >>> >> > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > >>> >> > > Anyway, I believe there are use cases for arbitrary > >>> XML/JSON/CBOR/… > >>> >>with no (YANG) schema available. My only complaint to “anyxml” has > >>> >>always been that it is a misnomer for encodings other than XML. > >>> >> > > > >>> >> > > The message encoding on the wire is not the same issue > >>> >> > > as the contents of a datastore. Our server stores its own > >>> >> > > internal data structures. XML, JSON, CBOR are just message > >>> >> > > encoding formats between client and server. The datastore > >>> >> > > is not encoded in any of these formats. > >>> >> > > >>> >> > The payload of anyxml needn’t directly map to a data subtree in the > >>> >>usual sense. > >>> >> > > >>> >> > that's precisely the difference between anyxml and anydata. > >>> >> > The anydata node MUST map directly into data subtrees. > >>> >> > >>> >> If the server doesn’t know the YANG data model at run time (which is > >>> >>possible) then it cannot do it - for instance, it cannot properly map > >>> >>module names to namespace URI or handle lists. > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > > >>> >> > > > I also don't get the value of a single top-level node called > >>> >>'device' > >>> >> > > > that every YANG model on the planet is supposed to augment. > >>> >> > > > Can you explain why a protocol operation to retrieve the > >>> >> > > > document root (/) is not sufficient for the top-level node? > >>> >> > > > >>> >> > > I don’t intend to defend their model, the more serious problem IMO > >>> >>is that a model for a single device/function may be needed in another > >>> >>device that hosts many virtualised devices/functions of the former > >>> type. > >>> >>We don’t have a good solution for this rather typical situation. > >>> >> > > > >>> >> > > But a single container called "whatever" provides no such > >>> >>aggregation. > >>> >> > > You would need a list for that. And the NMS might have multiple > >>> >> > > layers of hierarchy to represent various aggregations. The NP > >>> >> > > container called "device" is not helpful for aggregation. > >>> >> > > >>> >> > The parent node can be a list as well. The “root” node would be like > >>> >>a mount point in a Unix filesystem. > >>> >> > > >>> >> > > >>> >> > Are you saying all data on a device needs to be in a top-level list > >>> >>called 'device' > >>> >> > because an NMS might exist that wants to have the datastores from > >>> >>lots of devices? > >>> >> > As Martin pointed out several times, the NMS can make its own > >>> >>container or > >>> >> > lists. It does not need the device to mirror its own structure. > >>> >> > >>> >> As I said, I don’t care that much about the “device” container. What > >>> >>would be really useful is to have the possibility to do e.g. this: > >>> >> > >>> >> virtual-node* [name] > >>> >> name > >>> >> if:interfaces > >>> >> ... > >>> >> > >>> >> to support the use case where all virtual nodes are managed by the > >>> same > >>> >>NETCONF/RESTCONF server. > >>> >> > >>> >> Lada > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > Lada > >>> >> > > >>> >> > Andy > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > Lada > >>> >> > > > >>> >> > > > >>> >> > > Andy > >>> >> > > > >>> >> > > > >>> >> > > > > >>> >> > > > Andy > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka >>> > > >>> >>wrote: > >>> >> > > > > >>> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka > >>> wrote: > >>> >> > > > > > >>> >> > > > > Hi, > >>> >> > > > > > >>> >> > > > > after listening to the presentation of > >>> >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > >>> >>wondering > >>> >> > > > > whether the solution chosen for Y34 is really useful. > >>> >> > > > > > >>> >> > > > > The draft states they want to reuse ietf-interfaces but their > >>> >>tree in > >>> >> > > > > fact is > >>> >> > > > > > >>> >> > > > > +--rw device > >>> >> > > > > +--rw info > >>> >> > > > > | +--rw device-type? enumeration > >>> >> > > > > +--rw hardware > >>> >> > > > > +--rw interfaces > >>> >> > > > > | +--rw interface* [name] > >>> >> > > > > | ... > >>> >> > > > > +--rw qos > >>> >> > > > > > >>> >> > > > > So the "interfaces" container is no more a top-level node. > >>> >>There are > >>> >> > > > > three possible options: > >>> >> > > > > > >>> >> > > > > 1. Change the ietf-interfaces module. > >>> >> > > > > 2. Replicate its contents in another module. > >>> >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted > >>> >>at a > >>> >> > > > > given data node. > >>> >> > > > > > >>> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially > >>> #3 > >>> >>but it > >>> >> > > > > seems it is not so because it doesn't specify a concrete data > >>> >>model > >>> >> > > > > that's allowed at a given location. > >>> >> > > > > > >>> >> > > > > On the other hand, the only real contribution of "anydata" > >>> over > >>> >>"anyxml" > >>> >> > > > > is that is doesn't permit mixed content in XML, which is IMO > >>> >>not much. > >>> >> > > > > > >>> >> > > > > I know Y34 was already closed but I think it is more important > >>> >>to do > >>> >> > > > > things right before YANG 1.1 becomes an RFC. > >>> >> > > > > > >>> >> > > > > What I want to propose is this: > >>> >> > > > > > >>> >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate > >>> >>"anyxml" (but > >>> >> > > > > keep it for backward compatibility). > >>> >> > > > > >>> >> > > > s/Rename/Introduce/ > >>> >> > > > > >>> >> > > > > > >>> >> > > > > - Introduce a new statement and data node type, e.g. "root", > >>> >>that will > >>> >> > > > > extend the schema tree starting from that data node with a > >>> >>precisely > >>> >> > > > > specified data model. The specification can be same or > >>> similar > >>> >>as > >>> >> > > > > in yang-library. > >>> >> > > > > > >>> >> > > > > I believe there are other use cases in the existing modules. > >>> For > >>> >> > > > > example, the ietf-routing module could simply define the data > >>> >>model for > >>> >> > > > > a single routing instance (i.e. without "routing-instance" > >>> list > >>> >>at the > >>> >> > > > > top), and it can be then used without changes on simple > >>> >>devices, and > >>> >> > > > > more complex router implementations can graft it as a subtree > >>> >>under > >>> >> > > > > "routing-instance", "networking-instance" or whatever. > >>> >> > > > > > >>> >> > > > > Lada > >>> >> > > > > > >>> >> > > > > -- > >>> >> > > > > 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 > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > _______________________________________________ > >>> >> > > > 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 > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > _______________________________________________ > >>> >> > 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 > >>> > > >>> >-- > >>> >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> >Fax: +49 421 200 3103 > >>> > > >>> >_______________________________________________ > >>> >netmod mailing list > >>> >netmod@ietf.org > >>> >https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> ------------14ed033915d5e1628184306e730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Andy,

Thanks for the good information.  (I'll followup off line a bit if that's okay.) Of course there's a small matter of getting something standardized.

Lou

On July 27, 2015 2:19:09 AM Andy Bierman <andy@yumaworks.com> wrote:



On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <lberger@labn.net> wrote:

Andy,

Have you thought through implications / possibilities for existing models,  e.g., interfaces?



First we have to define various forms of relocation.

(1) Aggregation of datastores

The simplest form is aggregation.
It is possible to define a YANG container that is a conceptual
document root, such that the set of child nodes matches the set
of top-level YANG data nodes supported by the server.

A YANG extension can mark a YANG container or anyxml as a docroot.
Yuma-based code has been doing this for years with a YANG
extension called "root"


(See Y34-04)

The <config> node below is a document root:

container servers {
  list server {
      key addr;
      leaf addr { type inet:ip-address; }
      anydata config {
          ncx:root;
      }
  }
}

XPath evaluation requires certain inputs, including a context node
and a document root.  The 'root' extension tells the tool to use
the node with the 'root' tag as the document root, when processing
XPath within its descendant nodes. Without the tag, the XPath parser
would use 'servers' as the document root, which is incorrect for
the relocated YANG nodes within 'config'.

(2) Move a subtree within the datastore

This is the hardest (of course) because it involves moving the context node
not the document root. It is possible for tools to get fooled about the intent
of the XPath writer.  Basically the tool has to remember the original context node,
and do some complicated data manipulation, processing [4] Step
in XPath 1.0.  Multiple relocated subtrees gets even more complicated.

It may be possible to come up with some guidelines on XPath to avoid.
Basically any Xpath that selects nodes by specific names can be
relocated automatically.  Nodes selected by function, wildcard, axis, etc.
will not be so easy.
 

 

Thanks,
Lou



Andy
 

On July 26, 2015 4:41:32 PM Andy Bierman <andy@yumaworks.com> wrote:

Hi Acee,

I agree that "Relocatable YANG" would be very useful, and have been
thinking about the problem for awhile.  I think the key is to precisely
define a protocol-independent document root for each of the various
YANG XPath contexts.  In most cases the expression can be
automatically relocated to an ancestor root.  For the rest, a
YANG mechanism is needed to tell the compiler to force evaluation
on the old docroot (not the new docroot ancestor).


Andy


On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we’d need the ability to prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
<netmod-bounces@ietf.org on behalf of
j.schoenwaelder@jacobs-university.de> wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates
>we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>
>> > On 20 Jul 2015, at 19:29, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> >
>> > > On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)  The whole point of
>> > > > anydata is that it does not have XML cruft in it.
>> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> >
>> > anyxml can do that, too.
>> >
>> >
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >  I don't see why we need 2 anyxml constructs that are not
>> > supported by the industry.  One is already too many.
>>
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>>
>> >
>> >
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
>>with no (YANG) schema available. My only complaint to “anyxml” has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue
>> > > as the contents of a datastore.  Our server stores its own
>> > > internal data structures.  XML, JSON, CBOR are just message
>> > > encoding formats between client and server.  The datastore
>> > > is not encoded in any of these formats.
>> >
>> > The payload of anyxml needn’t directly map to a data subtree in the
>>usual sense.
>> >
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>>
>> If the server doesn’t know the YANG data model at run time (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>>
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don’t intend to defend their model, the more serious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don’t have a good solution for this rather typical situation.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.  The NP
>> > > container called "device" is not helpful for aggregation.
>> >
>> > The parent node can be a list as well. The “root” node would be like
>>a mount point in a Unix filesystem.
>> >
>> >
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that  wants to have the datastores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own
>>container or
>> > lists.  It does not need the device to mirror its own structure.
>>
>> As I said, I don’t care that much about the “device” container. What
>>would be really useful is to have the possibility to do e.g. this:
>>
>> virtual-node* [name]
>>     name
>>     if:interfaces
>>         ...
>>
>> to support the use case where all virtual nodes are managed by the same
>>NETCONF/RESTCONF server.
>>
>> Lada
>>
>> >
>> >
>> >
>> > Lada
>> >
>> > Andy
>> >
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > Andy
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > > >
>> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > after listening to the presentation of
>> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am
>>wondering
>> > > > > whether the solution chosen for Y34 is really useful.
>> > > > >
>> > > > > The draft states they want to reuse ietf-interfaces but their
>>tree in
>> > > > > fact is
>> > > > >
>> > > > >   +--rw device
>> > > > >          +--rw info
>> > > > >          |  +--rw device-type?   enumeration
>> > > > >          +--rw hardware
>> > > > >          +--rw interfaces
>> > > > >          |  +--rw interface* [name]
>> > > > >          |     ...
>> > > > >          +--rw qos
>> > > > >
>> > > > > So the "interfaces" container is no more a top-level node.
>>There are
>> > > > > three possible options:
>> > > > >
>> > > > > 1. Change the ietf-interfaces module.
>> > > > > 2. Replicate its contents in another module.
>> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted
>>at a
>> > > > >   given data node.
>> > > > >
>> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3
>>but it
>> > > > > seems it is not so because it doesn't specify a concrete data
>>model
>> > > > > that's allowed at a given location.
>> > > > >
>> > > > > On the other hand, the only real contribution of "anydata" over
>>"anyxml"
>> > > > > is that is doesn't permit mixed content in XML, which is IMO
>>not much.
>> > > > >
>> > > > > I know Y34 was already closed but I think it is more important
>>to do
>> > > > > things right before YANG 1.1 becomes an RFC.
>> > > > >
>> > > > > What I want to propose is this:
>> > > > >
>> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate
>>"anyxml" (but
>> > > > >  keep it for backward compatibility).
>> > > >
>> > > > s/Rename/Introduce/
>> > > >
>> > > > >
>> > > > > - Introduce a new statement and data node type, e.g. "root",
>>that will
>> > > > >  extend the schema tree starting from that data node with a
>>precisely
>> > > > >  specified data model. The specification can be same or similar
>>as
>> > > > >  in yang-library.
>> > > > >
>> > > > > I believe there are other use cases in the existing modules. For
>> > > > > example, the ietf-routing module could simply define the data
>>model for
>> > > > > a single routing instance (i.e. without "routing-instance" list
>>at the
>> > > > > top), and it can be then used without changes on simple
>>devices, and
>> > > > > more complex router implementations can graft it as a subtree
>>under
>> > > > > "routing-instance", "networking-instance" or whatever.
>> > > > >
>> > > > > Lada
>> > > > >
>> > > > > --
>> > > > > 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
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > 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
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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


------------14ed033915d5e1628184306e730-- From nobody Mon Jul 27 09:58:25 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 2887E1B30AC for ; Mon, 27 Jul 2015 09:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_210=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 shNg6F1gTVZE for ; Mon, 27 Jul 2015 09:58:18 -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 CA99D1B3099 for ; Mon, 27 Jul 2015 09:58:17 -0700 (PDT) Received: by lafd3 with SMTP id d3so42562377laf.1 for ; Mon, 27 Jul 2015 09:58:16 -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=l2fcEhBmSyPIO0XbxvyB8G7/w21aM6S+llyPIgcYZ0M=; b=DfYNMsvGAyD/ZtnzbOSihOYDNhSslIrln1jjKi4oZMGjzvy+GNkpfsNFTfFMv3sigG MgjvsvKSA7JNMYfAjhGOXtrmrjWUl3Ib+MDRTKXaPt4ZUHexuxEMuL1Qk5hUFIh52+OP yR27dm5nzhR2JdA2M5PsOzP4GWHA8vtKw5lsVgnQKwR6qerz0hrb16wCwrPZT7U93smc T5gODBZQbf6aZIA0JRKvS4lV7Ykg9yXpqMRLSsvgqbf7WimPigltLv6Bbsn9F3pfGenr M8soriBmiJnTie4npWoG3UaO9ZVahqt8EUoWUrLNy1ssAjMjcYYGhjuU/HHkXkoZBCbw WeFg== X-Gm-Message-State: ALoCoQkqX1UP7ZLEQRYcFADszTJeivzwccbAi+4MxMJVNOV1D/vzfiLIYG+2TM+CMrZvPRK+DFxj MIME-Version: 1.0 X-Received: by 10.152.87.205 with SMTP id ba13mr27153002lab.37.1438016296155; Mon, 27 Jul 2015 09:58:16 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 27 Jul 2015 09:58:15 -0700 (PDT) In-Reply-To: <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Mon, 27 Jul 2015 09:58:15 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c3539a839568051bde4285 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Mon, 27 Jul 2015 16:58:23 -0000 --001a11c3539a839568051bde4285 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I don't think a standard for relocating subtrees would be worth it. I am not in favor of moving /interfaces or /system to a new location. That's not how YANG works. It only allows "obsolete and start over". I would suggest pursuing solutions that don't cause as much disruption and expense as possible. For example, a resource directory of symlinks (YANG leaf, type instance-identifier) would allow standard or vendor modules to be supported. The exact location of the data nodes can change over time, and be different on each server. Andy On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger wrote: > Andy, > > Thanks for the good information. (I'll followup off line a bit if that's > okay.) Of course there's a small matter of getting something standardized= . > > Lou > > On July 27, 2015 2:19:09 AM Andy Bierman wrote: > >> >> >> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger wrote: >> >>> Andy, >>> >>> Have you thought through implications / possibilities for existing >>> models, e.g., interfaces? >>> >> >> >> First we have to define various forms of relocation. >> >> (1) Aggregation of datastores >> >> The simplest form is aggregation. >> It is possible to define a YANG container that is a conceptual >> document root, such that the set of child nodes matches the set >> of top-level YANG data nodes supported by the server. >> >> A YANG extension can mark a YANG container or anyxml as a docroot. >> Yuma-based code has been doing this for years with a YANG >> extension called "root" >> >> http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 >> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html >> (See Y34-04) >> >> The node below is a document root: >> >> container servers { >> list server { >> key addr; >> leaf addr { type inet:ip-address; } >> anydata config { >> ncx:root; >> } >> } >> } >> >> XPath evaluation requires certain inputs, including a context node >> and a document root. The 'root' extension tells the tool to use >> the node with the 'root' tag as the document root, when processing >> XPath within its descendant nodes. Without the tag, the XPath parser >> would use 'servers' as the document root, which is incorrect for >> the relocated YANG nodes within 'config'. >> >> (2) Move a subtree within the datastore >> >> This is the hardest (of course) because it involves moving the context >> node >> not the document root. It is possible for tools to get fooled about the >> intent >> of the XPath writer. Basically the tool has to remember the original >> context node, >> and do some complicated data manipulation, processing [4] Step >> in XPath 1.0. Multiple relocated subtrees gets even more complicated. >> >> It may be possible to come up with some guidelines on XPath to avoid. >> Basically any Xpath that selects nodes by specific names can be >> relocated automatically. Nodes selected by function, wildcard, axis, et= c. >> will not be so easy. >> >> >> >> >>> Thanks, >>> Lou >>> >> >> >> Andy >> >> >>> On July 26, 2015 4:41:32 PM Andy Bierman wrote: >>> >>>> Hi Acee, >>>> >>>> I agree that "Relocatable YANG" would be very useful, and have been >>>> thinking about the problem for awhile. I think the key is to precisel= y >>>> define a protocol-independent document root for each of the various >>>> YANG XPath contexts. In most cases the expression can be >>>> automatically relocated to an ancestor root. For the rest, a >>>> YANG mechanism is needed to tell the compiler to force evaluation >>>> on the old docroot (not the new docroot ancestor). >>>> >>>> >>>> Andy >>>> >>>> >>>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) >>>> wrote: >>>> >>>>> I think being able to place a given model anywhere in the device tree >>>>> would be useful and this would allow a model to be rooted in differen= t >>>>> locations on different devices. Similarly, we=E2=80=99d need the abil= ity to >>>>> prefix >>>>> XPATH references to data nodes in the model with the root. >>>>> Thanks, >>>>> Acee >>>>> >>>>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" >>>>> >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>> >>>>> >Lada, >>>>> > >>>>> >Y34 is closed and I have not seen any new argument here that indicat= es >>>>> >we made a major mistake with the resolution of Y34. As such, Y34 >>>>> >remains closed. >>>>> > >>>>> >If you want to discuss new ideas to relocate or "symlink" data model= s, >>>>> >please do so in a separate thread. (And no, we do not accept new >>>>> >issues for YANG 1.1 either at this point in time.) >>>>> > >>>>> >/js >>>>> > >>>>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote: >>>>> >> >>>>> >> > On 20 Jul 2015, at 19:29, Andy Bierman >>>>> wrote: >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka >>>>> >>wrote: >>>>> >> > >>>>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman >>>>> wrote: >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka >>>> > >>>>> >>wrote: >>>>> >> > > >>>>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman >>>>> wrote: >>>>> >> > > > >>>>> >> > > > Hi, >>>>> >> > > > >>>>> >> > > > Can you explain why we need 2 broken anyxmls? >>>>> >> > > > (The original and a synonym?) The whole point of >>>>> >> > > > anydata is that it does not have XML cruft in it. >>>>> >> > > >>>>> >> > > Yes, I understand this was your main priority. For implementor= s >>>>> >>using off-the-shelf XML parsers and tools the XML cruft is not an >>>>> issue >>>>> >>at all. >>>>> >> > > >>>>> >> > > >>>>> >> > > yes it is an issue. >>>>> >> > > We need something to model a container full of arbitrary YANG >>>>> data >>>>> >>nodes. >>>>> >> > > This is something that can be applied to the contents of a >>>>> >>datastore. >>>>> >> > >>>>> >> > anyxml can do that, too. >>>>> >> > >>>>> >> > >>>>> >> > the WG already decided it can't. >>>>> >> > The extra XML PIs, etc. are not accepted by all servers, remembe= r? >>>>> >> > There is no use for the extra stuff in the datastore. >>>>> >> > I don't see why we need 2 anyxml constructs that are not >>>>> >> > supported by the industry. One is already too many. >>>>> >> >>>>> >> I agree, but this is what we are going to have. My proposal was to >>>>> have >>>>> >>just one with two different names. >>>>> >> >>>>> >> > >>>>> >> > >>>>> >> > > >>>>> >> > > >>>>> >> > > Anyway, I believe there are use cases for arbitrary >>>>> XML/JSON/CBOR/=E2=80=A6 >>>>> >>with no (YANG) schema available. My only complaint to =E2=80=9Canyx= ml=E2=80=9D has >>>>> >>always been that it is a misnomer for encodings other than XML. >>>>> >> > > >>>>> >> > > The message encoding on the wire is not the same issue >>>>> >> > > as the contents of a datastore. Our server stores its own >>>>> >> > > internal data structures. XML, JSON, CBOR are just message >>>>> >> > > encoding formats between client and server. The datastore >>>>> >> > > is not encoded in any of these formats. >>>>> >> > >>>>> >> > The payload of anyxml needn=E2=80=99t directly map to a data sub= tree in >>>>> the >>>>> >>usual sense. >>>>> >> > >>>>> >> > that's precisely the difference between anyxml and anydata. >>>>> >> > The anydata node MUST map directly into data subtrees. >>>>> >> >>>>> >> If the server doesn=E2=80=99t know the YANG data model at run time= (which is >>>>> >>possible) then it cannot do it - for instance, it cannot properly m= ap >>>>> >>module names to namespace URI or handle lists. >>>>> >> >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > > >>>>> >> > > > I also don't get the value of a single top-level node called >>>>> >>'device' >>>>> >> > > > that every YANG model on the planet is supposed to augment. >>>>> >> > > > Can you explain why a protocol operation to retrieve the >>>>> >> > > > document root (/) is not sufficient for the top-level node? >>>>> >> > > >>>>> >> > > I don=E2=80=99t intend to defend their model, the more serious= problem >>>>> IMO >>>>> >>is that a model for a single device/function may be needed in anoth= er >>>>> >>device that hosts many virtualised devices/functions of the former >>>>> type. >>>>> >>We don=E2=80=99t have a good solution for this rather typical situa= tion. >>>>> >> > > >>>>> >> > > But a single container called "whatever" provides no such >>>>> >>aggregation. >>>>> >> > > You would need a list for that. And the NMS might have multipl= e >>>>> >> > > layers of hierarchy to represent various aggregations. The NP >>>>> >> > > container called "device" is not helpful for aggregation. >>>>> >> > >>>>> >> > The parent node can be a list as well. The =E2=80=9Croot=E2=80= =9D node would be >>>>> like >>>>> >>a mount point in a Unix filesystem. >>>>> >> > >>>>> >> > >>>>> >> > Are you saying all data on a device needs to be in a top-level >>>>> list >>>>> >>called 'device' >>>>> >> > because an NMS might exist that wants to have the datastores fr= om >>>>> >>lots of devices? >>>>> >> > As Martin pointed out several times, the NMS can make its own >>>>> >>container or >>>>> >> > lists. It does not need the device to mirror its own structure. >>>>> >> >>>>> >> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevic= e=E2=80=9D container. What >>>>> >>would be really useful is to have the possibility to do e.g. this: >>>>> >> >>>>> >> virtual-node* [name] >>>>> >> name >>>>> >> if:interfaces >>>>> >> ... >>>>> >> >>>>> >> to support the use case where all virtual nodes are managed by the >>>>> same >>>>> >>NETCONF/RESTCONF server. >>>>> >> >>>>> >> Lada >>>>> >> >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > Lada >>>>> >> > >>>>> >> > Andy >>>>> >> > >>>>> >> > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > Lada >>>>> >> > > >>>>> >> > > >>>>> >> > > Andy >>>>> >> > > >>>>> >> > > >>>>> >> > > > >>>>> >> > > > Andy >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka < >>>>> lhotka@nic.cz> >>>>> >>wrote: >>>>> >> > > > >>>>> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka >>>>> wrote: >>>>> >> > > > > >>>>> >> > > > > Hi, >>>>> >> > > > > >>>>> >> > > > > after listening to the presentation of >>>>> >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I = am >>>>> >>wondering >>>>> >> > > > > whether the solution chosen for Y34 is really useful. >>>>> >> > > > > >>>>> >> > > > > The draft states they want to reuse ietf-interfaces but >>>>> their >>>>> >>tree in >>>>> >> > > > > fact is >>>>> >> > > > > >>>>> >> > > > > +--rw device >>>>> >> > > > > +--rw info >>>>> >> > > > > | +--rw device-type? enumeration >>>>> >> > > > > +--rw hardware >>>>> >> > > > > +--rw interfaces >>>>> >> > > > > | +--rw interface* [name] >>>>> >> > > > > | ... >>>>> >> > > > > +--rw qos >>>>> >> > > > > >>>>> >> > > > > So the "interfaces" container is no more a top-level node. >>>>> >>There are >>>>> >> > > > > three possible options: >>>>> >> > > > > >>>>> >> > > > > 1. Change the ietf-interfaces module. >>>>> >> > > > > 2. Replicate its contents in another module. >>>>> >> > > > > 3. Extend YANG so that a *specific* schema tree can be >>>>> grafted >>>>> >>at a >>>>> >> > > > > given data node. >>>>> >> > > > > >>>>> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was >>>>> essentially #3 >>>>> >>but it >>>>> >> > > > > seems it is not so because it doesn't specify a concrete >>>>> data >>>>> >>model >>>>> >> > > > > that's allowed at a given location. >>>>> >> > > > > >>>>> >> > > > > On the other hand, the only real contribution of "anydata" >>>>> over >>>>> >>"anyxml" >>>>> >> > > > > is that is doesn't permit mixed content in XML, which is I= MO >>>>> >>not much. >>>>> >> > > > > >>>>> >> > > > > I know Y34 was already closed but I think it is more >>>>> important >>>>> >>to do >>>>> >> > > > > things right before YANG 1.1 becomes an RFC. >>>>> >> > > > > >>>>> >> > > > > What I want to propose is this: >>>>> >> > > > > >>>>> >> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate >>>>> >>"anyxml" (but >>>>> >> > > > > keep it for backward compatibility). >>>>> >> > > > >>>>> >> > > > s/Rename/Introduce/ >>>>> >> > > > >>>>> >> > > > > >>>>> >> > > > > - Introduce a new statement and data node type, e.g. "root= ", >>>>> >>that will >>>>> >> > > > > extend the schema tree starting from that data node with = a >>>>> >>precisely >>>>> >> > > > > specified data model. The specification can be same or >>>>> similar >>>>> >>as >>>>> >> > > > > in yang-library. >>>>> >> > > > > >>>>> >> > > > > I believe there are other use cases in the existing >>>>> modules. For >>>>> >> > > > > example, the ietf-routing module could simply define the >>>>> data >>>>> >>model for >>>>> >> > > > > a single routing instance (i.e. without "routing-instance" >>>>> list >>>>> >>at the >>>>> >> > > > > top), and it can be then used without changes on simple >>>>> >>devices, and >>>>> >> > > > > more complex router implementations can graft it as a >>>>> subtree >>>>> >>under >>>>> >> > > > > "routing-instance", "networking-instance" or whatever. >>>>> >> > > > > >>>>> >> > > > > Lada >>>>> >> > > > > >>>>> >> > > > > -- >>>>> >> > > > > 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 >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > _______________________________________________ >>>>> >> > > > 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 >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > _______________________________________________ >>>>> >> > 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 >>>>> > >>>>> >-- >>>>> >Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >>>>> >Fax: +49 421 200 3103 >>>>> > >>>>> >_______________________________________________ >>>>> >netmod mailing list >>>>> >netmod@ietf.org >>>>> >https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >> --001a11c3539a839568051bde4285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't think a standard for re= locating subtrees would be worth it.
I am not in favor of moving = /interfaces or /system to a new location.
That's not how YANG= works. It only allows "obsolete and start over".

<= /div>
I would suggest pursuing solutions that don't cause
as much disruption and expense as possible.

For e= xample, a resource directory of symlinks
(YANG leaf, type instanc= e-identifier) would allow
standard or vendor modules to be suppor= ted.
The exact location of the data nodes can change over time,
and be different on each server.


Andy

On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger <lberger@labn.= net> wrote:

Andy,

Thanks for the good information.=C2=A0 (I'll followup off line a bit if that's okay.) O= f course there's a small matter of getting something standardized.

Lou

On July 27, 2015 2:19:09 AM Andy Bierman <andy@yumaworks.com> wrote:


<= div class=3D"gmail_extra">
On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <lberger@labn.net> wrote:=

Andy,

Have you thought through implications / possibilities for existing models,=C2=A0 e.g., interfaces?



First we have to define various forms of relocation.

(1) Aggregation of datastores

The simplest form is aggregation.
It is possible to define a YANG container that is a conceptual
document root, such that the set of child nodes matches the set
of top-level YANG data nodes supported by the server.

A YANG extension can mark a YANG container or anyxml as a docroot.
Yuma-based code has been doing this for years with a YANG
extension called "root"

<= br>
(See Y34-04)

The <config> node below is a document root:

container servers {
=C2= =A0 list server {
=C2=A0 =C2=A0 =C2=A0 key addr;
=C2=A0 =C2= =A0 =C2=A0 leaf addr { type inet:ip-address; }
=C2=A0 =C2=A0 =C2=A0 anydata config {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ncx:root;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 }
}

XPath evaluation requires certain inputs, including a context node
and a document root.=C2=A0 The 'root' extension tells the tool to use
the node with the 'root' tag as the document root, when processing
XPath within its descendant nodes. Without the tag, the XPath parser
would use 'servers' as the document root, which is incorrect for
the relocated YANG nodes within 'config'.

(2) Move a subtree within the datastore

This is the hardest (of course) because it involves moving the context node
not the document root. It is possible for tools to get fooled about the intent
of the XPath writer.=C2=A0 Basically the tool has to remember the original context node,
and do some complicated data manipulation, processing [4] Step
in XPath 1.0.=C2=A0 Multiple relocated subtrees gets even mo= re complicated.

It may be possible to come up with some guidelines on XPath to avoid.
Basically any Xpath that selects nodes by specific names can be
relocated automatically.= =C2=A0 Nodes selected by function, wildcard, axis, etc.
will not be so easy.
=C2=A0

=C2=A0

Thanks,
Lou



An= dy
=C2=A0

On July 26, 2015 4:41:32 PM Andy Bierman <andy@yumaworks.com> wrote:

Hi Ac= ee,

I agree that "Relocatable YANG" would be very useful, and have been
thinking about the problem for awhile.=C2=A0 I think the key is to precisely
define = a protocol-independent document root for each of the various
YANG XPath contexts.=C2=A0 In most cases the expression can be
automatically relocated to an ancestor root.=C2=A0 For the res= t, a
YANG mechanism is needed to tell the compiler to force evaluation
on the old docroot (not the new docroot ancestor).


Andy


On Sun, Jul= 26, 2015 at 10:49 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we=E2=80=99d need the ability to= prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"=
<netmod-bou= nces@ietf.org on behalf of
j= .schoenwaelder@jacobs-university.de> wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates<= br> >we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>
>> > On 20 Jul 2015, at 19:29, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> >
>> >
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> >
>> > > On 20 Jul 2015, at 17:00, Andy Bierman <andy@yumaworks.com> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz>
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman <andy@yumaworks.com> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)=C2=A0 The whole point= of
>> > > > anydata is that it does not have XML cruft in it. >> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> >
>> > anyxml can do that, too.
>> >
>> >
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >=C2=A0 I don't see why we need 2 anyxml constructs that ar= e not
>> > supported by the industry.=C2=A0 One is already too many.
>>
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>>
>> >
>> >
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/=E2=80=A6
>>with no (YANG) schema available. My only complaint to =E2=80=9Canyx= ml=E2=80=9D has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue >> > > as the contents of a datastore.=C2=A0 Our server stores = its own
>> > > internal data structures.=C2=A0 XML, JSON, CBOR are just message
>> > > encoding formats between client and server.=C2=A0 The datastore
>> > > is not encoded in any of these formats.
>> >
>> > The payload of anyxml needn=E2=80=99t directly map to a data = subtree in the
>>usual sense.
>> >
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>>
>> If the server doesn=E2=80=99t know the YANG data model at run time= (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>>
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don=E2=80=99t intend to defend their model, the more s= erious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don=E2=80=99t have a good solution for this rather typical situa= tion.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.= =C2=A0 The NP
>> > > container called "device" is not helpful for aggregation.
>> >
>> > The parent node can be a list as well. The =E2=80=9Croot=E2= =80=9D node would be like
>>a mount point in a Unix filesystem.
>> >
>> >
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that=C2=A0 wants to have the datas= tores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own=
>>container or
>> > lists.=C2=A0 It does not need the device to mirror its own structure.
>>
>> As I said, I don=E2=80=99t care that much about the =E2=80=9Cdevic= e=E2=80=9D container. What
>>would be really useful is to have the possibility to do e.g. this:<= br> >>
>> virtual-node* [name]
>>=C2=A0 =C2=A0 =C2=A0name
>>=C2=A0 =C2=A0 =C2=A0if:interfaces
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>
>> to support the use case where all virtual nodes are managed by the same
>>NETCONF/RESTCONF server.
>>
>> Lada
>>
>> >
>> >
>> >
>> > Lada
>> >
>> > Andy
>> >
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > Andy
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <lhotka@nic.cz>= ;
>>wrote:
>> > > >
>> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <lhotka@nic.cz>= ; wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > after listening to the presentation of
>> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am
>>wondering
>> > > > > whether the solution chosen for Y34 is really useful.
>> > > > >
>> > > > > The draft states they want to reuse ietf-interfaces but their
>>tree in
>> > > > > fact is
>> > > > >
>> > > > >=C2=A0 =C2=A0+--rw device
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info >> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--r= w device-type?=C2=A0 =C2=A0enumeration
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardwa= re
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interf= aces
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--r= w interface* [name]
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0...
>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos >> > > > >
>> > > > > So the "interfaces" container is no more a top-level node.
>>There are
>> > > > > three possible options:
>> > > > >
>> > > > > 1. Change the ietf-interfaces module.
>> > > > > 2. Replicate its contents in another module. >> > > > > 3. Extend YANG so that a *specific* schema tree can be grafted
>>at a
>> > > > >=C2=A0 =C2=A0given data node.
>> > > > >
>> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3
>>but it
>> > > > > seems it is not so because it doesn't specify a concrete data
>>model
>> > > > > that's allowed at a given location.
>> > > > >
>> > > > > On the other hand, the only real contribution of "anydata" over
>>"anyxml"
>> > > > > is that is doesn't permit mixed content in XML, which is IMO
>>not much.
>> > > > >
>> > > > > I know Y34 was already closed but I think it is more important
>>to do
>> > > > > things right before YANG 1.1 becomes an RFC. >> > > > >
>> > > > > What I want to propose is this:
>> > > > >
>> > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate
>>"anyxml" (but
>> > > > >=C2=A0 keep it for backward compatibility).
>> > > >
>> > > > s/Rename/Introduce/
>> > > >
>> > > > >
>> > > > > - Introduce a new statement and data node type, e.g. "root",
>>that will
>> > > > >=C2=A0 extend the schema tree starting from tha= t data node with a
>>precisely
>> > > > >=C2=A0 specified data model. The specification = can be same or similar
>>as
>> > > > >=C2=A0 in yang-library.
>> > > > >
>> > > > > I believe there are other use cases in the existing modules. For
>> > > > > example, the ietf-routing module could simply define the data
>>model for
>> > > > > a single routing instance (i.e. without "routing-instance" list
>>at the
>> > > > > top), and it can be then used without changes on simple
>>devices, and
>> > > > > more complex router implementations can graft it as a subtree
>>under
>> > > > > "routing-instance", "networking-instance" or whatever.
>> > > > >
>> > > > > Lada
>> > > > >
>> > > > > --
>> > > > > Ladislav Lhotka, CZ.NIC Labs
>> > > > > PGP Key ID: E74E8C0C
>> > > > >
>> > > > > _______________________________________________
>> > > > > netmod mailing list
>> > > > > netmod@ietf.org
>> > > > > https://www.ietf.org/mailma= n/listinfo/netmod
>> > > >
>> > > > --
>> > > > Ladislav Lhotka, CZ.NIC Labs
>> > > > PGP Key ID: E74E8C0C
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > netmod mailing list
>> > > > netmod@ietf.org
>> > > > https://www.ietf.org/mailman/lis= tinfo/netmod
>> > > >
>> > >
>> > > --
>> > > Ladislav Lhotka, CZ.NIC Labs
>> > > PGP Key ID: E74E8C0C
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/net= mod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Un= iversity Bremen gGmbH
>Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 = | 28759 Bremen | Germany
>Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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



--001a11c3539a839568051bde4285-- From nobody Tue Jul 28 02:42:06 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 D48E31A8831 for ; Tue, 28 Jul 2015 02:42:04 -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 IGZB4nQqm-JA for ; Tue, 28 Jul 2015 02:42:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF571A882E for ; Tue, 28 Jul 2015 02:42:03 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 5DE1B1AE0492; Tue, 28 Jul 2015 11:42:01 +0200 (CEST) Date: Tue, 28 Jul 2015 11:42:01 +0200 (CEST) Message-Id: <20150728.114201.494611943524175409.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150726071623.GB16276@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] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 09:42:05 -0000 Hi, Andy Bierman wrote: > On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I would like to open another issue for YANG 1.1, > > > because I don't want to have 1.1 and then 1.2 right away. > > > The NETMOD WG should evaluate the different ways to > > > support ephemeral state, based on Jeff's draft. [...] > The problem with using YANG extensions for important protocol features > is that the YANG spec says these statements MAY be completely skipped > by a tool implementation. This is not acceptable for ephemeral state > (or operational state either). I don't agree that this is a problem. If i2rs defines an extension, then i2rs implementations will have to support that extension. This is the whole idea behind extensions - we should not have to revise YANG everytime we need a new statement. /martin From nobody Tue Jul 28 02:56: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 C59C91A883F for ; Tue, 28 Jul 2015 02:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 WKm_k8cp0gcw for ; Tue, 28 Jul 2015 02:56:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741091A7007 for ; Tue, 28 Jul 2015 02:56:20 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:880a:2cbb:806b:95c7] (unknown [IPv6:2001:718:1a02:1:880a:2cbb:806b:95c7]) by mail.nic.cz (Postfix) with ESMTPSA id DA0DA1816BA; Tue, 28 Jul 2015 11:56:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438077378; bh=2bREVK58FD9AiUVp1i31S138J9SliCpDge8xkoZbgHw=; h=From:Date:To; b=sjd3x2O8yagbRr1TUZfJ1Hsp10fL/i2ZciI9ntj25Sz2dt3vaZTNdffmoEmTK6h04 J03VK7yNUWwOci37PEWVZhiWq+5cvcKPFF1CIZB1tFpIfoxwJL0xMapSUVmtmg+fs7 /24cBhRnsXeBw10/Lk4akHzoi6/kHvCD66GcPBUY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150728.114201.494611943524175409.mbj@tail-f.com> Date: Tue, 28 Jul 2015 11:56:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150726071623.GB16276@elstar.local> <20150728.114201.494611943524175409.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 09:56:23 -0000 > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: >=20 > Hi, >=20 > Andy Bierman wrote: >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >>=20 >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: >>>> Hi, >>>>=20 >>>> I would like to open another issue for YANG 1.1, >>>> because I don't want to have 1.1 and then 1.2 right away. >>>> The NETMOD WG should evaluate the different ways to >>>> support ephemeral state, based on Jeff's draft. >=20 > [...] >=20 >> The problem with using YANG extensions for important protocol = features >> is that the YANG spec says these statements MAY be completely skipped >> by a tool implementation. This is not acceptable for ephemeral state >> (or operational state either). >=20 > I don't agree that this is a problem. If i2rs defines an extension, > then i2rs implementations will have to support that extension. This > is the whole idea behind extensions - we should not have to revise > YANG everytime we need a new statement. >=20 Yes, it could work in this case as long as modules containing this = extension are never advertised to regular NETCONF/RESTCONF clients. Lada >=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 Tue Jul 28 02:59: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 3A99E1A883F for ; Tue, 28 Jul 2015 02:58:58 -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 faZT7ovMPLj2 for ; Tue, 28 Jul 2015 02:58:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D92CE1A8842 for ; Tue, 28 Jul 2015 02:58:54 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D60D1AE0492; Tue, 28 Jul 2015 11:58:54 +0200 (CEST) Date: Tue, 28 Jul 2015 11:58:52 +0200 (CEST) Message-Id: <20150728.115852.2189909749980729854.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150728.114201.494611943524175409.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 09:58:58 -0000 Ladislav Lhotka wrote: > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > Hi, > > > > Andy Bierman wrote: > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> I would like to open another issue for YANG 1.1, > >>>> because I don't want to have 1.1 and then 1.2 right away. > >>>> The NETMOD WG should evaluate the different ways to > >>>> support ephemeral state, based on Jeff's draft. > > > > [...] > > > >> The problem with using YANG extensions for important protocol features > >> is that the YANG spec says these statements MAY be completely skipped > >> by a tool implementation. This is not acceptable for ephemeral state > >> (or operational state either). > > > > I don't agree that this is a problem. If i2rs defines an extension, > > then i2rs implementations will have to support that extension. This > > is the whole idea behind extensions - we should not have to revise > > YANG everytime we need a new statement. > > > > Yes, it could work in this case as long as modules containing this > extension are never advertised to regular NETCONF/RESTCONF clients. I think it would. Such nodes would just be seen as config false nodes. /martin From nobody Tue Jul 28 06:27: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 B2AF61A8AFE for ; Tue, 28 Jul 2015 06:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Piw04sRhVTMU for ; Tue, 28 Jul 2015 06:26: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 A76201A8A4C for ; Tue, 28 Jul 2015 06:26:58 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so74557791lbb.3 for ; Tue, 28 Jul 2015 06:26: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; bh=E5D9MqADPXCPxj+AyXQgIwBGYWQQ/qAJL7SNkThw5xY=; b=TxbDcuFgCXaUBOxCeCo/2MxyNu/V6rZq+D0NgEc7sZTZ960rlt+mj+/khSyQczlVGx GTB3ol1QSdp30sY5aBAtyBtV++dN6SwzSUMzsJAJ2KDdi4aLVLHo+WUBx+JpjOvaf7Xw rGuKvLceOrkKzPFkXzrb1IBo+XESnsTbgWUpFur7x1v12u+SauClgtDUsgpGGeUH4GNY pgA0NkI6c0Su0t4vogZF2r5Xi4eeRtPGb6jPUGnt06PnxQ+uT1h1iA6PS2lHRKeugbZ9 9ZanLH2NJG1fo5G/SIlB0Nf4XXZVxIBoTWcasOxTn8iscnuuJscQcKAxFFSKW25KA1aY OOFQ== X-Gm-Message-State: ALoCoQlo3u9dS1T3HTA/vUR4gQiiinsSA0GcyStyyZ+ovuYp4x77f27ph/L/b4SV2EHnTY/za2Zf MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr32544580lab.38.1438090017149; Tue, 28 Jul 2015 06:26:57 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 28 Jul 2015 06:26:57 -0700 (PDT) In-Reply-To: References: <20150726071623.GB16276@elstar.local> <20150728.114201.494611943524175409.mbj@tail-f.com> Date: Tue, 28 Jul 2015 06:26:57 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e01176905a0b450051bef6c5a Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 13:27:00 -0000 --089e01176905a0b450051bef6c5a Content-Type: text/plain; charset=UTF-8 On Tue, Jul 28, 2015 at 2:56 AM, Ladislav Lhotka wrote: > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > Hi, > > > > Andy Bierman wrote: > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> I would like to open another issue for YANG 1.1, > >>>> because I don't want to have 1.1 and then 1.2 right away. > >>>> The NETMOD WG should evaluate the different ways to > >>>> support ephemeral state, based on Jeff's draft. > > > > [...] > > > >> The problem with using YANG extensions for important protocol features > >> is that the YANG spec says these statements MAY be completely skipped > >> by a tool implementation. This is not acceptable for ephemeral state > >> (or operational state either). > > > > I don't agree that this is a problem. If i2rs defines an extension, > > then i2rs implementations will have to support that extension. This > > is the whole idea behind extensions - we should not have to revise > > YANG everytime we need a new statement. > > > > Yes, it could work in this case as long as modules containing this > extension are never advertised to regular NETCONF/RESTCONF clients. > > This restriction is unacceptable. It must be possible to put I2RS data in any YANG module. > Lada > Andy > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --089e01176905a0b450051bef6c5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 28, 2015 at 2:56 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 28 Jul 2015, at 11:42, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> Andy Bierman <andy@yumaworks.= com> wrote:
>> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder <
>> j.schoenwa= elder@jacobs-university.de> wrote:
>>
>>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote:<= br> >>>> Hi,
>>>>
>>>> I would like to open another issue for YANG 1.1,
>>>> because I don't want to have 1.1 and then 1.2 right aw= ay.
>>>> The NETMOD WG should evaluate the different ways to
>>>> support ephemeral state, based on Jeff's draft.
>
> [...]
>
>> The problem with using YANG extensions for important protocol feat= ures
>> is that the YANG spec says these statements MAY be completely skip= ped
>> by a tool implementation.=C2=A0 This is not acceptable for ephemer= al state
>> (or operational state either).
>
> I don't agree that this is a problem.=C2=A0 If i2rs defines an ext= ension,
> then i2rs implementations will have to support that extension.=C2=A0 T= his
> is the whole idea behind extensions - we should not have to revise
> YANG everytime we need a new statement.
>

Yes, it could work in this case as long as modules containing this extensio= n are never advertised to regular NETCONF/RESTCONF clients.



This restriction is una= cceptable.
It must be possible to put I2RS data in any YANG modul= e.

=C2=A0
Lada


Andy
=C2= =A0


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





--089e01176905a0b450051bef6c5a-- From nobody Tue Jul 28 06:44:29 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 340AC1A9069 for ; Tue, 28 Jul 2015 06:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ryz_U7bthv4Q for ; Tue, 28 Jul 2015 06:44:26 -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 C232B1A8F44 for ; Tue, 28 Jul 2015 06:44:24 -0700 (PDT) Received: by laah7 with SMTP id h7so68878010laa.0 for ; Tue, 28 Jul 2015 06:44: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=+NWbunerkVc3hxu4AtKrPwK+D6SaLVo7WoYRpDS6Kic=; b=b2LyBNrxLFx6Mfn/swCjpXwHHp48JBkO3HEmjOtDT69PmrFXQEJ9cl7TKcoShu/qLj UAF8C8nBEAQgE/Bz58ghRT9wyYljs6CTL+T4Vn+6CFybsvZMaEfmVD8I5XjvOGVVXg89 m23KsO5ItTXGHjhd5PygfbpLbs5U9MbSCniHk8LhFqjPS02Zo0SOdhQkxlKq9UUqm3FD Rh/pZysFJ+Wv4+jpXFMvyo7LPI8Kq9dgytD2TqvyDBMCEtd3W9FRS8XMmXuEqlsTq6zg M6pMvIQdW9ZfI1qH0tpuic3GO6TdNfXzajxGJEetnuRiHePLa2OEpfC5G03hWANrbTuw SApw== X-Gm-Message-State: ALoCoQmZC02Bulkz+9YuPSQHL541gbtNyU7uoiOnTkN0WvxsJLBxVQH9iaM8wRQRUs7tajHTIZur MIME-Version: 1.0 X-Received: by 10.152.116.39 with SMTP id jt7mr32311075lab.82.1438091063321; Tue, 28 Jul 2015 06:44:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 28 Jul 2015 06:44:23 -0700 (PDT) In-Reply-To: <20150728.115852.2189909749980729854.mbj@tail-f.com> References: <20150728.114201.494611943524175409.mbj@tail-f.com> <20150728.115852.2189909749980729854.mbj@tail-f.com> Date: Tue, 28 Jul 2015 06:44:23 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c36592fbfc94051befaa58 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 13:44:28 -0000 --001a11c36592fbfc94051befaa58 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > > > Hi, > > > > > > Andy Bierman wrote: > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > >>>> Hi, > > >>>> > > >>>> I would like to open another issue for YANG 1.1, > > >>>> because I don't want to have 1.1 and then 1.2 right away. > > >>>> The NETMOD WG should evaluate the different ways to > > >>>> support ephemeral state, based on Jeff's draft. > > > > > > [...] > > > > > >> The problem with using YANG extensions for important protocol features > > >> is that the YANG spec says these statements MAY be completely skipped > > >> by a tool implementation. This is not acceptable for ephemeral state > > >> (or operational state either). > > > > > > I don't agree that this is a problem. If i2rs defines an extension, > > > then i2rs implementations will have to support that extension. This > > > is the whole idea behind extensions - we should not have to revise > > > YANG everytime we need a new statement. > > > > > > > Yes, it could work in this case as long as modules containing this > > extension are never advertised to regular NETCONF/RESTCONF clients. > > I think it would. Such nodes would just be seen as config false > nodes. > > I do not agree that YANG extensions are appropriate for defining standard protocols. They are fine for extra tools outside the scope of any protocol. The "get filter" hack in RFC 6241 does not even work since any tool is allowed to ignore the extension. The solution proposed by I2RS changed the config-stmt. IMO this is a better solution than defining an extension that every YANG tool MAY ignore. Ephemeral data can be defined in any YANG module, not in special hack modules that are not allowed to be shared by NETCONF or RESTCONF in any way, That would be a terrible solution for ephemeral data. > /martin > Andy --001a11c36592fbfc94051befaa58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 28 Jul 2015, at 11:42, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > Hi,
> >
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder <<= br> > >> j.sch= oenwaelder@jacobs-university.de> wrote:
> >>
> >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wr= ote:
> >>>> Hi,
> >>>>
> >>>> I would like to open another issue for YANG 1.1,
> >>>> because I don't want to have 1.1 and then 1.2 rig= ht away.
> >>>> The NETMOD WG should evaluate the different ways to > >>>> support ephemeral state, based on Jeff's draft. > >
> > [...]
> >
> >> The problem with using YANG extensions for important protocol= features
> >> is that the YANG spec says these statements MAY be completely= skipped
> >> by a tool implementation.=C2=A0 This is not acceptable for ep= hemeral state
> >> (or operational state either).
> >
> > I don't agree that this is a problem.=C2=A0 If i2rs defines a= n extension,
> > then i2rs implementations will have to support that extension.=C2= =A0 This
> > is the whole idea behind extensions - we should not have to revis= e
> > YANG everytime we need a new statement.
> >
>
> Yes, it could work in this case as long as modules containing this
> extension are never advertised to regular NETCONF/RESTCONF clients.
I think it would.=C2=A0 Such nodes would just be seen as config false
nodes.


I do not agree that YANG extensions are appropriate = for defining standard protocols.
They are fine for extra tools ou= tside the scope of any protocol.
The "get filter" hack = in RFC 6241 does not even work since
any tool is allowed to ignor= e the extension.

The solution proposed by I2RS cha= nged the config-stmt.
IMO this is a better solution than defining= an extension
that every YANG tool MAY ignore.=C2=A0
Ephemeral data can be defined in any YANG module,
no= t in special hack modules that are not allowed to be shared
by NE= TCONF or RESTCONF in any way,
That would be a terrible solution f= or ephemeral data.




/martin

Andy<= /div>

--001a11c36592fbfc94051befaa58-- From nobody Tue Jul 28 07:13:31 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 5DCFA1A92DD for ; Tue, 28 Jul 2015 07:13:30 -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 7CkM_OtMSziw for ; Tue, 28 Jul 2015 07:13:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08021A92E5 for ; Tue, 28 Jul 2015 07:13:20 -0700 (PDT) Received: from [172.20.6.143] (unknown [172.20.6.143]) by mail.nic.cz (Postfix) with ESMTPSA id 37E9A18169E; Tue, 28 Jul 2015 16:13:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438092799; bh=hqd2cRjMFQ7S5hSr3a2bUZoQJ3LcvZszPRlRBYnr+J0=; h=From:Date:To; b=GGev3c4sujeTz9C9NsCg6g2Vz+Uh58mcemJn9twZ8RizdC4XW0K3K0DcED4PdJk20 YFopDtK1hN0dUAaXBkNndRMptQyAeYzdacIPXk0/wglOdTMOLhtYYiO6MSV2SzuedC tDc2aQgBe09twKPIP6bnOvWZ5CQ45L/Y0jui9mIg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 28 Jul 2015 16:13:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <650F4101-CCAD-4F94-8764-7DCD887B3CB0@nic.cz> References: <20150728.114201.494611943524175409.mbj@tail-f.com> <20150728.115852.2189909749980729854.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 14:13:30 -0000 > On 28 Jul 2015, at 15:44, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > > > Hi, > > > > > > Andy Bierman wrote: > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > >>>> Hi, > > >>>> > > >>>> I would like to open another issue for YANG 1.1, > > >>>> because I don't want to have 1.1 and then 1.2 right away. > > >>>> The NETMOD WG should evaluate the different ways to > > >>>> support ephemeral state, based on Jeff's draft. > > > > > > [...] > > > > > >> The problem with using YANG extensions for important protocol = features > > >> is that the YANG spec says these statements MAY be completely = skipped > > >> by a tool implementation. This is not acceptable for ephemeral = state > > >> (or operational state either). > > > > > > I don't agree that this is a problem. If i2rs defines an = extension, > > > then i2rs implementations will have to support that extension. = This > > > is the whole idea behind extensions - we should not have to revise > > > YANG everytime we need a new statement. > > > > > > > Yes, it could work in this case as long as modules containing this > > extension are never advertised to regular NETCONF/RESTCONF clients. >=20 > I think it would. Such nodes would just be seen as config false > nodes. >=20 >=20 > I do not agree that YANG extensions are appropriate for defining = standard protocols. > They are fine for extra tools outside the scope of any protocol. > The "get filter" hack in RFC 6241 does not even work since > any tool is allowed to ignore the extension. >=20 > The solution proposed by I2RS changed the config-stmt. > IMO this is a better solution than defining an extension > that every YANG tool MAY ignore. > =20 >=20 > Ephemeral data can be defined in any YANG module, > not in special hack modules that are not allowed to be shared > by NETCONF or RESTCONF in any way, > That would be a terrible solution for ephemeral data. I am not sure the ephemeral property required by I2RS only means that a = given parameter is is stored in volatile memory. In the meeting with = Jeff and Alia on Thursday afternoon we (again) discussed the overlay = property: they apparently want to be able to override normal config = values with a new (ephemeral) value installed by an I2RS client. This = would mean that the same data node exists in two instances - one = permanent and one ephemeral, and config true/false/ephemeral is then = clearly insufficient. That=E2=80=99s why I asked during the session for clarification of the = interactions between ephemeral and standard config values. It also has implications for validation - the running config certainly = has to be always valid but what about validity of running + ephemeral = data? Jeff=E2=80=99s response was that no semantic validation is done in = this case, and it is up to the consuming server application to somehow = cope with invalid data and do whatever is the most appropriate action. Lada >=20 >=20 >=20 >=20 > /martin >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 28 07:38: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 948B41AC3CA for ; Tue, 28 Jul 2015 07:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=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 1C-uvOIcN8_U for ; Tue, 28 Jul 2015 07:38:07 -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 225EE1AC3B8 for ; Tue, 28 Jul 2015 07:38:07 -0700 (PDT) Received: by lagw2 with SMTP id w2so69922452lag.3 for ; Tue, 28 Jul 2015 07:38: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:cc:content-type; bh=J6uFj9czHBCEhMoA4DTEQL3Ty7C08XiBJ1xgC+h7IkA=; b=AGWObLFqPmin3Sdjxc/76wXFdCFQ5z6SpQKA9zMpsyHmmRoBpNEITBynCH8PeaMEzh Lo9p8KSHM7ycsAdg3iAKce6MmGryN/YcCYqASE655nzieVZh1bf+gRqtXy4J5+73bzTN RBmUkSlJwvX9XaKzHMfzjePPapcFsleSDpWeq0yYlteub65jp9/4cXbX1vFe34jXJy1y jy1q78S5FLetkedNOUwDvVAHMIqhOnRtUb0c8/qY3kwPleb6hedO3DARJPSr2h64Qt/I ryLiIEOkRqSXkgLLHCeKPA1bhjSOgOu9ws9XsJoytno03D83IT051yodNSzyLYNrSvqt P+2w== X-Gm-Message-State: ALoCoQmf7qwajPxURWxP0Gn1tGWzur0eCtLYIvEEXlNGRaq10qug5FIREdeVO2xAGWf6kBKMKsSG MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr32874911laj.88.1438094285387; Tue, 28 Jul 2015 07:38:05 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 28 Jul 2015 07:38:05 -0700 (PDT) In-Reply-To: <650F4101-CCAD-4F94-8764-7DCD887B3CB0@nic.cz> References: <20150728.114201.494611943524175409.mbj@tail-f.com> <20150728.115852.2189909749980729854.mbj@tail-f.com> <650F4101-CCAD-4F94-8764-7DCD887B3CB0@nic.cz> Date: Tue, 28 Jul 2015 07:38:05 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e0158b5e408c870051bf06b34 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 14:38:09 -0000 --089e0158b5e408c870051bf06b34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 28, 2015 at 7:13 AM, Ladislav Lhotka wrote: > > > On 28 Jul 2015, at 15:44, Andy Bierman wrote: > > > > > > > > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund > wrote: > > Ladislav Lhotka wrote: > > > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > > > > > Hi, > > > > > > > > Andy Bierman wrote: > > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > > >> j.schoenwaelder@jacobs-university.de> wrote: > > > >> > > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > >>>> Hi, > > > >>>> > > > >>>> I would like to open another issue for YANG 1.1, > > > >>>> because I don't want to have 1.1 and then 1.2 right away. > > > >>>> The NETMOD WG should evaluate the different ways to > > > >>>> support ephemeral state, based on Jeff's draft. > > > > > > > > [...] > > > > > > > >> The problem with using YANG extensions for important protocol > features > > > >> is that the YANG spec says these statements MAY be completely > skipped > > > >> by a tool implementation. This is not acceptable for ephemeral > state > > > >> (or operational state either). > > > > > > > > I don't agree that this is a problem. If i2rs defines an extension= , > > > > then i2rs implementations will have to support that extension. Thi= s > > > > is the whole idea behind extensions - we should not have to revise > > > > YANG everytime we need a new statement. > > > > > > > > > > Yes, it could work in this case as long as modules containing this > > > extension are never advertised to regular NETCONF/RESTCONF clients. > > > > I think it would. Such nodes would just be seen as config false > > nodes. > > > > > > I do not agree that YANG extensions are appropriate for defining > standard protocols. > > They are fine for extra tools outside the scope of any protocol. > > The "get filter" hack in RFC 6241 does not even work since > > any tool is allowed to ignore the extension. > > > > The solution proposed by I2RS changed the config-stmt. > > IMO this is a better solution than defining an extension > > that every YANG tool MAY ignore. > > > > > > Ephemeral data can be defined in any YANG module, > > not in special hack modules that are not allowed to be shared > > by NETCONF or RESTCONF in any way, > > That would be a terrible solution for ephemeral data. > > I am not sure the ephemeral property required by I2RS only means that a > given parameter is is stored in volatile memory. In the meeting with Jeff > and Alia on Thursday afternoon we (again) discussed the overlay property: > they apparently want to be able to override normal config values with a n= ew > (ephemeral) value installed by an I2RS client. This would mean that the > same data node exists in two instances - one permanent and one ephemeral, > and config true/false/ephemeral is then clearly insufficient. > > That=E2=80=99s why I asked during the session for clarification of the > interactions between ephemeral and standard config values. > > It also has implications for validation - the running config certainly ha= s > to be always valid but what about validity of running + ephemeral data? > Jeff=E2=80=99s response was that no semantic validation is done in this c= ase, and > it is up to the consuming server application to somehow cope with invalid > data and do whatever is the most appropriate action. > > There are 2 issues: 1) overlay: how does I2RS access config=3Dtrue data in the ephemeral datastore A: Define a new leaf that can be used as a target datastore for datastore parameters Define new operations like Enhance to filter for ephemeral data 2) state-only: how does I2RS access ephemeral data in the ephemeral datastore This is special data that is not a config=3Dtrue data model. This data is allowed to access operational state (e.g., reference system or protocol assigned values), which is not allowed for config=3Dtrue validation A: Define ephemeral-stmt or modify config-stmt to identify ephemeral-only data Config-stmt approach ----------------------------- Config or Ephemeral Data: config true; Ephemeral-only data: config ephemeral; Operational data: config false; New statement approach ----------------------------------- Config or Ephemeral Data: config true; Ephemeral-only data: config false; ephemeral true; Operational data: config false; ephemeral false; Lada > > > > Andy > > > > > > > > /martin > > > > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --089e0158b5e408c870051bf06b34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 28, 2015 at 7:13 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 28 Jul 2015, at 15:44, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
> >
> > > On 28 Jul 2015, at 11:42, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > Hi,
> > >
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder = <
> > >> = j.schoenwaelder@jacobs-university.de> wrote:
> > >>
> > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierm= an wrote:
> > >>>> Hi,
> > >>>>
> > >>>> I would like to open another issue for YANG 1.1,=
> > >>>> because I don't want to have 1.1 and then 1.= 2 right away.
> > >>>> The NETMOD WG should evaluate the different ways= to
> > >>>> support ephemeral state, based on Jeff's dra= ft.
> > >
> > > [...]
> > >
> > >> The problem with using YANG extensions for important pro= tocol features
> > >> is that the YANG spec says these statements MAY be compl= etely skipped
> > >> by a tool implementation.=C2=A0 This is not acceptable f= or ephemeral state
> > >> (or operational state either).
> > >
> > > I don't agree that this is a problem.=C2=A0 If i2rs defi= nes an extension,
> > > then i2rs implementations will have to support that extensio= n.=C2=A0 This
> > > is the whole idea behind extensions - we should not have to = revise
> > > YANG everytime we need a new statement.
> > >
> >
> > Yes, it could work in this case as long as modules containing thi= s
> > extension are never advertised to regular NETCONF/RESTCONF client= s.
>
> I think it would.=C2=A0 Such nodes would just be seen as config false<= br> > nodes.
>
>
> I do not agree that YANG extensions are appropriate for defining stand= ard protocols.
> They are fine for extra tools outside the scope of any protocol.
> The "get filter" hack in RFC 6241 does not even work since > any tool is allowed to ignore the extension.
>
> The solution proposed by I2RS changed the config-stmt.
> IMO this is a better solution than defining an extension
> that every YANG tool MAY ignore.
>
>
> Ephemeral data can be defined in any YANG module,
> not in special hack modules that are not allowed to be shared
> by NETCONF or RESTCONF in any way,
> That would be a terrible solution for ephemeral data.

I am not sure the ephemeral property required by I2RS only means that a giv= en parameter is is stored in volatile memory. In the meeting with Jeff and = Alia on Thursday afternoon we (again) discussed the overlay property: they = apparently want to be able to override normal config values with a new (eph= emeral) value installed by an I2RS client. This would mean that the same da= ta node exists in two instances - one permanent and one ephemeral, and conf= ig true/false/ephemeral is then clearly insufficient.

That=E2=80=99s why I asked during the session for clarification of the inte= ractions between ephemeral and standard config values.

It also has implications for validation - the running config certainly has = to be always valid but what about validity of running + ephemeral data? Jef= f=E2=80=99s response was that no semantic validation is done in this case, = and it is up to the consuming server application to somehow cope with inval= id data and do whatever is the most appropriate action.



There are 2 issues:

=C2=A0 =C2=A01) overlay: how does I2RS access config= =3Dtrue data in the ephemeral datastore

=C2=A0 =C2= =A0 A: Define a new <ephemeral /> leaf that can be used as a target d= atastore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for datastore parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Define new operations like <edit-ephe= meral>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Enhance <get> to filt= er for ephemeral data

=C2=A0 =C2=A02) state-only: = how does I2RS access ephemeral data in the ephemeral datastore
= =C2=A0 =C2=A0 =C2=A0 =C2=A0This is special data that is not a config=3Dtrue= data model.=C2=A0 This data is allowed
=C2=A0 =C2=A0 =C2=A0 =C2= =A0to access operational state (e.g., reference system or protocol assigned= values),
=C2=A0 =C2=A0 =C2=A0 which is not allowed for config=3D= true validation

=C2=A0 A: =C2=A0Define ephemeral-s= tmt or modify config-stmt to identify ephemeral-only data
Config-stmt approach
-----------------------------

Config or Ephemeral Data:
=C2=A0 =C2= =A0 =C2=A0config true;

Ephemeral-only data:
<= div>=C2=A0 =C2=A0 =C2=A0config ephemeral;

Operatio= nal data:
=C2=A0 =C2=A0 =C2=A0 config false;

=

New statement approach
----------------= -------------------

Config or Ephemeral Data:
=C2=A0 =C2=A0 =C2=A0config true;

Ephemeral-o= nly data:
=C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2= =A0 =C2=A0ephemeral true;

Operational data:
<= div>=C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 ephem= eral false;


Lada

>


Andy
=C2= =A0
>
>
>
> /martin
>
> Andy

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--089e0158b5e408c870051bf06b34-- From nobody Tue Jul 28 11:46: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 4E6981B2D8D for ; Tue, 28 Jul 2015 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Z77PGCd7xg0K for ; Tue, 28 Jul 2015 11:46:34 -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 DFF7F1B2CA5 for ; Tue, 28 Jul 2015 11:46:33 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-14-55b771ca37c7 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A3.A2.12958.AC177B55; Tue, 28 Jul 2015 14:12:58 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Tue, 28 Jul 2015 14:46:27 -0400 From: Scott Mansfield To: "netmod@ietf.org" Thread-Topic: IEEE Feature Topic call for papers Thread-Index: AdDJZRLp2mtO3P8vTtyvWfljKIgSOQ== Date: Tue, 28 Jul 2015 18:46:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/mixed; boundary="_004_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonUPdU4fZQg1trrSzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs729UwFb3YyVSy9N5upgfHPCqYuRg4OCQETieZ1Xl2MnECm mMSFe+vZuhi5OIQEjjJKPD3eAeUsZ5R4duIjK0gVG1DD1l3TGUFsEQF1iZk7QTo4OIQFtCUu vOYGMUUEDCQuNotBVOhJLJ30gAXEZhFQlZi7eicTiM0r4Cvx9moDmM0ItPf7qTVgNrOAuMSt J/OZIO4RkXh48TQbhC0q8fLxP1YIW0ni4+/57BD1mRJ3t81lh5gpKHFy5hOWCYxCs5CMmoWk bBaSMoh4vsSyReuhanQkFuz+xAZha0ssW/iaGcY+c+AxE6Z4L6PEoyvqELaTxO2ZGxlnAUOL WeAso8T9k/tZIRKKElO6H7IvYORZxchRWpxalptuZLCJERhzxyTYdHcw7nlpeYhRgINRiYd3 QeG2UCHWxLLiytxDjNIcLErivI5ReaFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGEsUWHIq 9INv5tYlnp94SdytKc7F/kKg0fkdLf4dsyXV1h/fYrG1/nCe9sKCtvJtb0r1xF+IGBzQuCJ4 8Pq2eaJnns/6xTQl12+uyYuFxb4Llttf6RPtbfNujHyr1+KcaFr4izWQWfx19stO5jaGxqJ9 3E+3JXj9ObnVtDOvRPvnw5klgm8eKLEUZyQaajEXFScCAKGIz7WaAgAA Archived-At: Subject: [netmod] IEEE Feature Topic call for papers 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: Tue, 28 Jul 2015 18:46:36 -0000 --_004_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_ Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_" --_000_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netmod! I am one of the guest editors for an IEEE Feature Topic entitled "Semantics= for Anything as a Service". The full call for papers is attached, but to = give y'all a flavor for what is in scope --- Solicited topics include (but are not limited to): * Information modeling * Data modeling * Transforming information models to data models * Service development lifecycle aspects * End-to-End service management frameworks * Model driven development * Modeling tools * Landscape of YANG models * Survey of modeling work from industry groups * Advances needed in network management protocols * Interaction of Open Source and Traditional Industry Fora and Stan= dards Development Organizations I encourage you to participate/contribute an article. Please forward to an= yone you think would have something to say in this space. BTW --- I did ask the wg-chairs of NETMOD and one of them suggested that I = forward this to the list. I appreciate your consideration! Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Netmod!

 

I am one of the guest editors for an IEEE Feature To= pic entitled “Semantics for Anything as a Service”.  The f= ull call for papers is attached, but to give y’all a flavor for what = is in scope ---

 

Solicited topics include (but are not limited to):

·         Information modeling

·         Data modeling

·         Transforming information models to data mode= ls

·         Service development lifecycle aspects

·         End-to-End service management frameworks

·         Model driven development

·         Modeling tools

·         Landscape of YANG models

·         Survey of modeling work from industry groups=

·         Advances needed in network management protoc= ols

·         Interaction of Open Source and Traditional I= ndustry Fora and Standards Development Organizations

I encourage you to participate/contribute an article= .  Please forward to anyone you think would have something to say in t= his space.

 

BTW --- I did ask the wg-chairs of NETMOD and one of= them suggested that I forward this to the list.  I appreciate your co= nsideration!

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 

--_000_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_-- --_004_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Call for Papers-management_r4_07-02-2015.docx" Content-Description: Call for Papers-management_r4_07-02-2015.docx Content-Disposition: attachment; filename="Call for Papers-management_r4_07-02-2015.docx"; size=19921; creation-date="Thu, 23 Jul 2015 18:05:47 GMT"; modification-date="Thu, 23 Jul 2015 18:05:47 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBY9K0pAEAAMIGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lU1PwzAMhu9I/IcqV9RmcEAIreMA4whIDHHOUneLaD4Ue4P9e5wVKkAbHQwulZrE7/Paqd3hxYtt siVENN6V4rgYiAyc9pVxs1I8TK7zM5EhKVepxjsoxQpQXIwOD4aTVQDMONphKeZE4VxK1HOwCgsf wPFO7aNVxK9xJoPST2oG8mQwOJXaOwJHOSUNMRpeQa0WDWXjF15unURoUGSX7cHEKoUKoTFaETuV S1d9oeRvhIIj12dwbgIesQ0hNxLSznbA9riZqb/EGZsyS+tMuuViRlNBdqci3SjLxuWzj5WsvF5Y zrr4HrwhM1/XRkMXn9RC9BoQ+ZZsU3Q7Vhn3nvFWH25hpxA58u+NdNK9JpBWDeDfO2h1d8Q/GpqP 6xo0f6P9l2IxT5UvWsSH2H4aEHG9d4F87py87+bxTbnXwjNM7//NxQfxXiM1d/RETRvYoeI/LEYn 3WuCeEyBXD+P9/axlvkOye15F31AHnvxF2m/z7UUnXPfB4hkoJtsm/q8I/LI3Ds/SEO5guqnbL1A 8nZvfCuzAS7Xf6DRKwAAAP//AwBQSwMEFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsACAJfcmVscy8u cmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACsks9Kw0AQxu+C77DMvZm0iog06UWE3kTiAwy70ySY/cPuVNu3dy2IBmrSg8ed +eab33zsenOwg3rnmHrvKlgWJSh22pvetRW8Nk+Le1BJyBkavOMKjpxgU19frV94IMlDqetDUtnF pQo6kfCAmHTHllLhA7vc2floSfIzthhIv1HLuCrLO4y/PaAeeaqtqSBuzQ2o5hjy5nlvv9v1mh+9 3lt2cmYF8kHYGTaLEDNblD5foxqKLUsFxuvnXE5IIRQZG/A80epyor+vRctChoRQ+8jTPF+KKaDl 5UDzEY0VP+l8+GgwR3TKdorm9j9p9D6JtzPxnDTfSDj6mPUnAAAA//8DAFBLAwQUAAYACAAAACEA yqS/TAkCAAD1CAAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lstu2zAQRfcF+g8G9xattE3aIHK8aApk0U3roGuaGkmM +RA4ozj++478NmK5MaBuBJCChnfOHV3p7v7V2cELRDTBZyJNRmIAXofc+DITT9Mfw69igKR8rmzw kIkloLgff/xw9wusIn4IK1PjgKt4zERFVN9KiboCpzAJNXi+U4ToFPEylrJWeq5KkFej0bWMhzXE +Kjm4DHPRHzM+fzpsuaT/107FIXR8D3oxoGnE0dI4/hsLqhiCZQJB7lR6800KU0h5GkN6ac+RRTB 01TN7IGQ3VbCuLpUdIlwRseAoaBEByfXENrmb475SqSlBfxjqHooCtCEexBvbp3TcdMnjIq9jdb4 +V7MxminE6d8gzqamjQbGpVddchdso1DA7Aj+DPkPCEPrwTRq06A6dV/Vu6UsRRuKejKhMlznRTN syFsWtnb/t4ntVela3e3AjKxXp+zOO0TlG/cDCIHyl7BbuuciOs+RXTP2WKxaP3BoFcBtZ4uzime yyE2M2ewzcZh2ZgceFA5/zb58T4n015ZnmhjM3Sc0C8GJ9qAV5fP25c+WS9g9huI2PEdq0wcbJ4z PeUPUH95341rrlxilZsoqxWBHdqmjZjLwX3uUy6+obbdOYfsW58SuomhDkRtJGNhwOYTfqU1YvCX M0t7hUb8r7H7EGRitZSra7qlJo9+VsZ/AQAA//8DAFBLAwQUAAYACAAAACEA6CPgRHgQAAB0agAA EQAAAHdvcmQvZG9jdW1lbnQueG1s7F3vcuLIEf+eqrzDFF9yV7XYgPGfpc7kMNh7JF6vy/hSdZ9S gzSAYkmjjEawbCrvcs9yT5Zfz0ggAQYc22uz66u6XSGNZrp7+n/3aH/66+fAZ2OhYk+Gp6XqXqXE ROhI1wuHp6Vfby/KJyUWax663JehOC1NRVz6a/PPf/pp0nClkwQi1AxThHFjEjmnpZHWUWN/P3ZG IuDxXuA5SsZyoPccGezLwcBzxP5EKne/VqlWzFWkpCPiGOu1eTjmcSmdLlieTUYixFoDqQKu4z2p hvsBV3dJVMbsEdde3/M9PcXclaNsGnlaSlTYSAEqzwCiVxoWoPSv7A21hMWKde2bnZQCZsV9JXzA IMN45EVzNP7f2YDiKANpvA6JceBn4yZRtb603gzlbfago/gEWzGfcGm6FcRw7UuBb+lA+zvf1cUZ q5V1yKQ7QlPMYNgGhOKaGSQB98LZNP8fafLEhUQ8hr8/KJlEM3Ai73GzdcO72VwkmA+ArHJkJC+P WvygCZZEtzfikSixwGl0h6FUvO8Dokm1zogjS00oi750p/R3xCYNKBv35rRUqVyc1M4rnVJ2qyMG PPF17ol9U96RmPc0VxpDPRcD6J2QB1jlnx/kGXfuSvv5seehOxtpHih6qptt7vsM+oNdA14V/7RP N+lPPMef0RKEx0dHx5XqKgjb1ePD+oXBLZ28B5UXas+JzQqtcKpHEKUyj8u83BNqDN23ecF65fjg 8GLVgikoBKJdkBRlI464AypESsRYQpSa6Uox+8ELHT8hRc54ARYaCFh+ZFwJpkeC9ZMvX5gXmmsv dJNYq+keYwVgsWi2TbQ/tWrloHpmsDf6fxmOK6EhlHexWWXdVDlC6mYgVURUW/fC5rWZlizRMAZf BAvFhGnhjELpy6Eninu+gFUelNXUZb53V9zFhSm2AC6lDLtIQofsxTpc8xA118K+xcL/8JROOKhi zBS4wmU92OYJ+KAM2fNC4bKrddCkzGlkaTV97KYTz62bJ4/V6nn0iOu1U2wGhbjbGfFwuAmaPOWa JA8TPmUzMaJpYI2EEu475shw4A0TXBvqBTL0tMSvdchuhvQBsta8lSxOokhCFRKoYiz9MSHohQPF IbiJowHeO7aWqzqd4/pxZZ30QmhCu5cG0VRlMCg4PhTG6Yvg7JAnFmMgyAGJy+Cy7qJyWQCx46EX YwzpXHhcQRJ6juW+dSS7aFfa9ZN18E08Uq4GtnUTbUaUk4MKJeUGHiDVCsCNBXMluQ7xAzZmNRt3 Q8s7efLIsOySpQA7rQM9LyNNdwpj5zlzBuR63bub6Qe1k+dgcNA71pd6tD1ItJvrdddm4jMeRX7G EHAZh4oH2AfiZi3UAJYNZqx13Y1hq6CsuGEhQO5DqpN1BMgTb/XOgI0hQFAyI47dHyri4XhmwEno lfh34kG2NzDBcfvg5PDY8moTPgoiJeXGIKYLY2OMX0LBDQmoiVsyyrtccxZIV/j0FOLjithRXt+a ZN4nXnQ0oDCmPdQ2tDB0IMF3heaeT0BnMu8yMyVJI273p0Y/SIVIzLC1VIAGRIQK00r6PtyfzOYL R8bTWItgr0DT1Q6RRTfzBXIuW44QynpbtyMvZheCk0ZitzLyHMiZC08lBmUIiUxTECTG7SCSJTHt jdlvd8xDx6ibGazYGc7kgHUXyNkhcn5MyVlAY8FA59yoezwXyxeZNjNwzhgjpS6pM/iYZS3L5Gqm xoJ9nKnHIiUXQNjMnYy1KaJVxBqzTYN6N6wCwmkZlV05CdkYOgpyq2VQTiISJyW5MyJ2WkeD80q9 VVmrXyF0kLycdF7npLObSeePa1fJo9l0xVj4MjKmA1zB/Vhi08eehoAVQH001/UkVArNS1Qib9z6 wYL90E+0EchQavhxQTrmx8bm9TcGKqk8XC/ELtG1EYWop6c+/IrGmPunpUvYmWuuoHR4NLJxS5gE dqTnj/1sXGX2rEvRjHm3RvdAovQFIpZ90Yrcal2Xl5UCrgt8mWeLZrA40sr0KglbuWW7TTKjThYp kG6yCV2flFYHncOz6sqgr/jkdbLXreJhTMaNtNPWNPMWR66JKnK6fvGtB+7JagEhpoZF2l5pNpc8 /jXQk2V6JNhNA2FhkpVCd3+6ovjEMFLOEn5tPZVlKeDGzM2C7w2EM3WgKHkcCUcXw93dxjfnLKyI pRC6BcJkSzZv8VnrqH5wvCpBVHzy0rqiaZwx5irEU2F+n781FK37Lv2nZtfUgJJi+erieQmnM3aQ IyVX+7fW1QcbqTw1ii+ogVYbgl6CHOqUkJ5FZiSWbKBksL0OX23ammlmlQ2pDvDUpHxJbmnZOM1m guB3IzGTJY/yCSMltXSeXk5eHROZ8AixO0X64KRPqFoiz5oox0a1cJdcjx5yH1Gszbav5a1OtVJ9 /95mGFaz7QVKLktTWH+dosd5VqKTM7ef1BDJOZsL3oIbN/rzps6yrrxzjcrqFjWf1KO7x35RvYM0 LipKAj4nSh/ViqkG2Z+tRMt0CJ6QleQDpJJmo8yv5UHIwWCmWt3MRD9uEqpgccxmgzCZaLp9OY/O TCSGACoNvy6QVolpudjxUNlrKY+jLDtpCETtrdjjp6VbL0B24wqZ1RtkF1GXnDRGrTDOD3ZQhrNv 2mqW/bMdm78hOsg6pHFgxfxnYYu/ZHdrx9mdNsFiI0ZzD96TgZS8qBRiDDCFuMK2ENPsGEpUwvvj 996vZx+7vV730xX78Gu3c37ZvTrvbXY1Fri6QIuMQLkcV3H4S7Ao0vaAK8ei+pJYzO77c+7cFuxX PVlmP3vvtbDfkyBBDNdSKPT6kOd4JBMf6Vbk5KAsSOqN+bM5T1K+E+VpDQtA1QokPCkPhNQ5kroj AeFHoZziTiQ1UWGKGdQMauM2BUwxEKbTxh2hLCTK37TmHoP+GlE6N0ClFpUV35cocWJA9/z8nBKH 8ypLjJTkkH+B5vpLzIYJpibOseUYgIAMoy3GwEzRBFBLCSWhI71nEpC+0GL5NShYRGdUJoF+NIA4 PCQKDGQChLn+4/eC4EHPTVFtx8p3TJnyveq6aNDBfWTCpJqSpjaKJ5O4ghi+qEo6Omylabi5lt3M 5sQhaT/GZDKhvptYOqZfCZcBH+5H1H5QjpN+4KH1CRWh+d4USAe5mdHu5Sj0VFKz2nnZY13NkBJG E9qUeQGVNtFGQVKBPC2JAoo0m7ibqiAyHPpTm9eFaKB7Ckl7CAwEkkoe6FN7NyueIHvaF4qcM1vN tZURTW0ryKeb3hDmi3CIelgq35QyFp8dqhLV3x1WKowajjC2hX6SVC5NAglSgNVIhqlGTGWCKOnP SlxGYDHEbDy0AlLUIwQDQyTsM/FFCSEVQdYGzArgx0hUL3l3LyIqT8QIPgzWjQgNja5R7DmD+rsz Po5u/lDg/xz7z1WHSX58B6ojcPbmCtmxzGB6+KwSKXtCFFtRvi1t0fwxK2K6sI5kt/ZYjzQmFXFS 6wslQZJT+shR52ToKV3gHvKXZ91muTjq1TtKZEGO7kPmq5rHJ5J53dy/Dx2KCndtb1b3+iFxDScv rQbfh+5u7l6JoW9HDOGtbVGuLYZJNwWMM4l8VVHVW+D/db3sUKKfQA6eLq+B0wi2CR14RA0vJHPB XIQXt9AuJXN1Nru6nF1RKReBCJqUG+g0QSzTpebiauvssHLWTh8IZOvodq1er19cvD+iUCVqiM/k UjLnM4KXeu3k+BACQoHMwcHBoY0YMGaAgpY+tyNR+MdS2vyJfNT7wxpe6dNPokJEpymuFaPmZqSt bGvztWea+RhumOag01I/QeOODfajhnM1/kAtBJ5zQfUjSuvwhmkqSO9cSgf9t/Z0BhJQCx3imxv5 bft8KNvURSlaJuwj8ADwPiBet/5jV82hYkrxiUKe7MEIoP2Deo+wY7hq4P8ULFw9erZwfO1hx+zU IEW6edjj4uYdrNg8goZesRNwgszu1TKtEQSl5FdKTkbwhJAjtFtQnGWffhaAQtwRXXi+T7Ska3jQ AnEPOAxsjmM9DtqvtOkdR7sdaMSJqS9jNMSbK2Zo/p/aSatSeV87K7cPK+0ymlnPy6339ePyceX8 uF6pn1Tb1fZ/6W3IUBIL4MH9TuRlDLDtqYtUfO25IMt4Jn1pxGPfAASum4OIS8KJYI2VcwM5A1fi WiuhnRFdDoB6eh+DZw8MneakIarFSImy/oQKlmnOl97/PFAB/Y0jKQxSjo2FfBtwLHnuF30sl70c qVh/ECge0QUIDzgNpfkYhCY5wuanQ2itUNKGGUz8sHADA+mOgZ7gTS8BvpkkFXuSlfxvXM/UIV3P tSRl5IzOz+xxwUibJ2meeEcy2zYN3P14/enmtnV1yzqt25dKAG/dzZWq0qybawJOfMbqxlvq+KsW Y7ZLE+byPSa4NelA1klEsSsR0voigvpk0d9STniGD5RqFv4VUTw+q529r8ELMyF8R5AHlY18bgX1 KLwpsT0c+fifzqsZMzYVlKW3nlNWYLuv/fi+wHFX0CfTYm2HRp9XhL5ySrZWDxfxetV7mEfiHWWW iuDj8fJhwecIe99sSbEm/ijBzDaVdi/1booqJ93B5+bMPjw8NDBsX9jfzpZ0UDCkahK7ktrDUXtT 2/se7chz79+TMCE5rFdyfJ92zBiTtH7abJ7dsq56ah53Btd3i/o/QyeH4a4gQ9GtcdZN+JwdvV4+ Mr0r+DTfDBw+7mD6xShziGTfW7D0CoOlC4+aJnMh03caJ+2MWvkbuhk42jrurct+1azTk5ltExCs M2e7ZpuLpea34IaSDmQI0jbgtx7L5+xa3i64uc71USHN/X3lx3KnTXeidWXWj/NwxbLcF2CC5e/n YIEpCsxSaOpVlF8OjkyVuhF/mR8ssPd2NqWyGSUK0D/8et67Zeed7u2nm4cfJ1jm5TTm/a5ODjxD tiuXwHtuX/gZoCfG6jn4ageFMvHAE/7K4+TPqemfBau+MqpaN88VvrsRIxHZDZ29RT95JzfMoEa6 jqCfteTPe5Lfk8e4vif5pFM/PzpH9X+u2wufBfklOyRRMlT8Cor/oUcaYuJZ6km2PPuzSLeZmpIL uwxCzWhk8M0j/SoM2lY+5z1ZvkVUlwtBxcrlTc4MFJ8YM5CLFdOixLfZBfAMKmf3zcAvOMta/jsP 2CUvilCqanbXBrR8ahj2y5cJHV0oyMxO47bGCFSpl3SDFaid1C7qrV22Anc82PN58DNPN9g3G/xm A1BTTr176iquFDX9mw2wJW/751MWvnffBlx5Q+GzDh97xc8w7LSapBin7YmQfx+a35QO1/v/u6/5 8WlT8OjPDm3rm75f0Pcrm7/ejAB5RI/9rMnmYG33jcBvyb88fCPXGXny29GYZAQugFisl77WvJMZ gU1ZoKrpVv7WzQC+4gUu/flf0d4Ae6vj5M0W4OQGTvbgFBF8Nnz8wQQAWxiEHl6ysUK1dmL/nZRo 2KPPOU3QjVRLv0c1wvXhCY6oGuc5GqK4hhH4uDHu1+3JVUW95vOf9ovQ89++GOSe0iEy+iTWcc3E qwOJz2zMfw4TfJgCP9Pl0DNBn5KilBTaougVAwVOK35QHn2WmMrk1x7OXJ2WDo7MUyhjSw1z4sj+ wy+4h1fMPxfV/J8AAAAA//8DAFBLAwQKAAAAAAAAACEACeF90IUAAACFAAAAFQAAAHdvcmQvbWVk aWEvaW1hZ2UxLmdpZkdJRjg5YQ8ADgCzAACr1GLs9duezUq/3oey127M5Z/5/PSYyj7///8AAAAA AAAAAAAAAAAAAAAAAAAAAAAh+QQBAAAIACwAAAAADwAOAAAEMhDJiQy9M4gDLJ7bwX2IJp4dFp4i QJksmyJrjEqAHQ+SkesHHuW3w/iKJKKQdFySnogIADtQSwMEFAAGAAgAAAAhADDdQymoBgAApBsA ABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboce aYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8e H6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i 13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy 4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqw trSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGe drfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63V hos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbY hyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLO qm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2B R2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMK eH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/Fu RBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sH dTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9 S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6 +w4ljrtPrwa3aeiINAsQPTMRFb68TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+HiCjeUyhdfP66Q +20t2Zuwe1XlzPaJQr0Id7I8d7kI6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8KJ8vviTPqjAUaN2L 2EbbtN3xwq57TBkbqCkjN6RpvCXsPUEfBvU6c+IkxSksjeBRZzIwcHChwGYNElx9RFU0iHAKTXvd 00RCmZEOJUq5hMOiGa6krfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81CjJGqtAcaHNGK5rAWZmtXMmI gm6vw6yuhTozt7oRzRRFh1uhsjaxOZSDyQvVYLCwJjQ1CFohsPIqnPk1azjsYEYCbXfro9wtxgsX 6SIZ4YBkPtJ6z/uobpyUx8qcIloPGwz64HiK1UrcWprsG3A7i5PK7BoL2OXeexMv5RE88xJQO5mO LCknJ0vQUdtrNZebHvJx2vbGcE6GxzgFr0vdR2IWwmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqew UwdSIdUWlpENDTOVhQBLNCcr/3ITzHpRClRUo7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8 oogYRMERGrGJ2Mfgfh2qoE9AJVx3mIqgX+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIh g3kriQe6VcpulDu/KiblL0iVchj/z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa 4H4XpiGo4ILa/BfkUP+3OWdpmLSGQ6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwR OSRsqGvgqt7bPRRBqJtqkpUBgzsZf+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFo D2a7ql1vlud7b1kRPTFrsxp5VgCz0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/ Knxmv3boDXXI96G2Ivh4oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7 i7/PaeyiOXPZObl4kcbOLOzY2o4tNDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg 6KEHJg8g+S1Hs3TjLwAAAP//AwBQSwMEFAAGAAgAAAAhABiRMeofBAAA0QoAABEAAAB3b3JkL3Nl dHRpbmdzLnhtbLRW227bOBB9X2D/wdDzOtbNlwh1iliOd1sk26JKP4CSaJsIbyApO+7X75AU43qj BsUW+yRqztxnOMN3758ZHR2w0kTwZZRcxdEI80a0hO+W0dfHzXgRjbRBvEVUcLyMTlhH729+/+3d sdDYGGDTI1DBdcGaZbQ3RhaTiW72mCF9JSTmAG6FYsjAr9pNGFJPnRw3gklkSE0oMadJGsezqFcj llGneNGrGDPSKKHF1liRQmy3pMH9J0ion7HrJdei6RjmxlmcKEzBB8H1nkgdtLH/qg1C3Aclh7eC ODAa+I5J/BZnH+5RqPZF4mfcswJSiQZrDQVi1IfLEOEvapL8laKXVF9Bqife9sSqAvEkdqez55q+ kh+otq/iPakVUr7M0ADWC9YUH3ZcKFRTaKpjkkc30FHfhGCjYyGxaqBI0I7TOJpYoBV/C7MmWlJ0 +ox2eCU66EhFsHYwxCq2lUEGg7SWmFLXvg3FCGwdi51CDBpvGXmKkzEKNU9f8IHYzvdqWrxFHTWP qK6MkCB3QBDlPO2daPYIZAxWlUQNGCgFN0rQwOd8LKGvFaTdu+273AbgT5W/MSDBEYO4PbW/BQ+i xdbZTpFXqf1haayA8xIy6MIaNiTghivSYgiN4sqcKN6A8xX5hm95+7HThsC9cnfhFzx4ywHMreVP MA8eTxJvMDIdpOl/MuYqsaFEPhClhPrAW+imXzU2CUW05YRx2epw+CKECWWI480ivYvXPheW7Yyk SZwlqyEkS7JyvRhEbvPV7HYQWU9XyWYQucvK6SCSx/NsGJmlaRpa6NLr+Ww2j5MhO/NVki76tvuX zCpdXaeDMmW2mM6HkOssS+PB7Kyup+v59ZDM6naWZ4PayjhbZIPaymQ+zQezs07i5HrQzno9z+f9 FLiM9C7Ob+PByv24DzaLWbkZlinjMncIdJs1BD3GCrtYPqtwshd3xPylLxGrFUGjB7t64PqzolZP K8IDXmNYvfh7pOrqAI7HHtAMUbqByRYAFygrWhi3a7x1aukDUruz3p5DDVJhin580WXnOFZ/KtFJ b+2okPQXMphL8rzXR7i5JyzQdVdXQYrD+vgOguH/6aCswsk5PcfCwKvDDbZ7xHfh3mE+/lpZVri/ VFX2ZYIfkJQwwIGl3iXLiJLd3iR2GBn4g73y5H7qXdpjqcPgz2LuBzU2MuDuD5bBH4GrP5xpWaBl ZxrsX8+Xn2nTQJueabNAgxfSsdjD9FSw3Z5gRYSjpW8FpeKI278CcRm9Ivkk6D2SGOpqNx20lygc oV99enQo8DNsXtwSAw8/SVqGnmERx+nMivfcsIVFZy54LWaZ5QV11CKDQNyV6kIYSger+tIX2PO4 IdCO1YnV58V65R2nRJsKS9jBRigI2a29P5zm81v05h8AAAD//wMAUEsDBBQABgAIAAAAIQCEsUGU 3ggAAIRCAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzMXG1z2zYM/r67/Qedvqd+SRq3 ubm7Nmna3HVdVye3z7RMx7pIoqaXpNmvHwhKtCxZEhCpd/vkiCLxAATwgHaJ/vb7jzBwHmWS+ipa urNXU9eRkac2fnS/dO9ur0/euE6aiWgjAhXJpfssU/f3d7/+8tvTRZo9BzJ1QECUXjzF3tLdZVl8 MZmk3k6GIn0V+l6iUrXNXnkqnKjt1vfk5Eklm8l8OpviX3GiPJmmgHYpokeRuoW4sClNxTICrK1K QpGlr1RyPwlF8pDHJyA9Fpm/9gM/ewbZ0/NSjFq6eRJdFAqdWIX0kgujUPFRrkgaVhzBNSuvlJeH MsoQcZLIAHRQUbrz470ZL5UGJu5KlR67jHgMg3LeUzw7a+BZkyk+uErEE7hiL7Ah7shmbMyiMDD7 oP2792pd4mzaZUzhES3C6kBR4RCz1CQUfmTFvGxrqpsL+TAkvj8lKo+tOrE/TNpN9GBl6bRkaDY9 x8yrmpayBDRSd7UTsXSd0Lu4uY9UItYBaPQ0O3N0RLrvgCo2yruSW5EHWaofk29J8Vg84ce1irLU eboQqef7t0AhICX0QeDn91Hqu/BGijR7n/ri6MudnnX0jZdmFWkf/I3vTjRi+i/IfBTB0p3Py5FL rcHBWCCi+3JMRid3q6omS9cOrUHu0hXJyeq9FjZBM8vPirnxgfHwhKrEwoPMAxyxzSSQELCYxgl8 7d35AhjNPHzP9eaKPFMFCAoAsKpYeKztOHATMNXKMDa8ldsvynuQm1UGL5YuYsHg3c23xFcJ0OjS fftWY8LgSob+Z3+zkbpAFGN30c7fyL93MrpL5WY//tc10nMh0VN5lIH65wuMgiDdfPzhyVjTJIiO hPbwV70AOAzcUcFBhXJ/r40ZqKHi4D8l5Mz48CjKTgpd0hzUvxMIrc4HA821RVUDUC5L19PhIs6G i3g9XAQG77C9WAzXAg4yQz1iYqMSlXSnZsozwVfdh9O3HSGrVzSiqHdFI2h6VzRipHdFIyR6VzQi oHdFw+G9Kxr+7V3RcGfnCk8gcdWj6BR3g5TYt34WQJ3sYbrZQKorSo3zTSTiPhHxztGFta52F1mu 8nVGUxXp9OVkucoSpY+bPTsC1Vmn7os5+WMY70Tqw6m8D2jg1t/qo4/zKfHh+NoD9doEX8MmPJgc LWHfAuHJnQo2MnFu5Q/jUcb6r8pZmVNGr3ID3frFv99lDpwKdcntBTtv2fT2nTDyv/gp7kFnNT9v MaVPOMmH5y1x2S78D7nx87DcGsJp5NzwOcPNNQhUsXuLzrSLmtnVa4V2AMUEUy74JqB8gv6muPDl ax9T9Del6IXyCfqbwvVC+Rgf3f5lM80V/KzikNJrwc7dSxWoZJsHZQ700sOCncEWgmYCO4mtfBJJ LNgZfECfznvPg29ulDhl+2LPowwUtjsMCiYb3Ra2U2q0N2NYxHZQDWvOwBrGtQwgNul+l4++/hGY WwyQpe1ZszedT1t2AEoQ6Qz9V66y/jP0vIXzqCg3EfxckkqHhnbaknlUtCKeTL1j+HhY4WMADauA DKBhpZAB1BIf7WceWxPpIMOLIwOLTcu2imHYkZl5wWZmC8QrASPVTcL5qyV722OhWTcJKGwHNesm AYXtnVots3WTgDVa3SRgtVSNdh9VOZVjFLtuVoHsSYBg0TjkTQAah7wJQOOQNwFoOHn3g4xH3gQs NjdYTq2SNwEIp3C+6lugKnkTgNjcYNiu+M2orHsopfvL7QjkTUBhO6hJ3gQUtnfayJuAhVM4kVDD slRHwBqHvAlA45A3AWgc8iYAjUPeBKBxyJsANJy8+0HGI28CFpsbLKdWyZsAxKYHC1QlbwIQTuFw w1Hyxqz/6eRNQGE7qEneBBS2d2qEag+pBCy2g2pYlrwJWDiFEwwFFgY3x6hxyJtg0TjkTQAah7wJ QOOQNwFoOHn3g4xH3gQsNjdYTq2SNwGITQ8WqEreBCA2Nxwlb0zGn07eBBS2g5rkTUBhe6dGqJbn CFhsB9WwLHkTsDBeBpM3AQinvBSIY9E45E2waBzyJgCNQ94EoOHk3Q8yHnkTsNjcYDm1St4EIDY9 WKAqeROA2NxwlLwxR346eRNQ2A5qkjcBhe2dGqFa8iZgsR1Uw7JUR8Aah7wJQBiYg8mbAIRTXgCE WcRx0zjkTbBoHPImAA0n736Q8cibgMXmBsupVfImALHpwQJVyZsAxOYGfc8W7ouSr6fOWoKAes+g vNVABpy3OIkKWBj4XW5lAl2Fsv92yEDA0kIGYkt4UE38oNSDQ7vYfdoSIGQofx34Cq90P+MtnUoj wumio5Pg9s9L57NpgGmsw5A6vHkD3UPVdiFsT9KNQ6Bn9hxDy05c3izX0qBBSPd1FS1A2BN6Aw1B RVuPXqz7fGAiNlUVw/jvtgUq/A2IuLAJ5e0Ay4OOqA6o4sK7vYOE193rwC234lGRfUtGqWZxO35/ hjLzDu5oduqd6ZvgHTrjTfHOPXJwivFqU0FozkKV+jQEl60D02IGf9xEG7DwqejOMs7c/BBGFLy/ lEHwh8CGtEzF7VMDuc3M29kUK2BN1FplmQrb1yd4QRw1OSYAwqGqjHnURrTHSZSHa5kU181bQ1JX DuxEOwxJc9e1JRSoO92u20G62AT5IIJAqQhv8teDtXhnrvmjXmsBbXZ/6q65RhpBi+BDOV4RegmZ Mzx6oC9chwyCTqfXb+Yfp1dGalvjIv6DbNG2eGYfjrctFi2S8HHQ+7l0b8VOhULnD3Z1Vgc8aFYt XpsMsE2cs/MiJ/7dN3GaMfANtJx2xc8Bz3h5CuGLzZJ1WqtvcJfnnL0Lau47ylhoTYszmY5s9xpu w/9gv4/nhM5PS+ONRMVz3/51X140SRPunuKifeGBnegLcB85UzPe0l3Mp0aCBx1V0IKTi6BoqQG5 EGRlLy6lmFki+Aw1NdF+bxi8f3PM1vYgalpektjhdy+U2r4BRax4+sb+ngOABa51YmJLNR6VoXnc moAi83K2/n8doAyazallYMmX6bv/AAAA//8DAFBLAwQUAAYACAAAACEASKwu5FoIAACTPwAADwAA AHdvcmQvc3R5bGVzLnhtbMxbbW/bOAz+fsD9B8Pfu7y012zFsqFr11uBvXRLi/us2Epj1LZytrO2 +/VHUbbi2LFN1h5wnxrLEh9SJB8qqfj2/VMUOj9lkgYqnruTV2PXkbGn/CC+n7t3t1dHr10nzUTs i1DFcu4+y9R9/+7PP94+nqXZcyhTBwTE6Vnkzd11lm3ORqPUW8tIpK/URsbwcqWSSGTwmNyPIpE8 bDdHnoo2IguWQRhkz6PpeHzq5mISihS1WgWevFTeNpJxhutHiQxBoorTdbBJC2mPFGmPKvE3ifJk moLRUWjkRSKIrZjJSU1QFHiJStUqewXGjIxGIy0Klk/G+CkKXSfyzq7vY5WIZQib9zg5cd/BzvnK u5QrsQ2zVD8mN0n+mD/hnysVZ6nzeCZSLwhuYUtBQBSArE/ncRq48EaKNDtPA3Hw5VrPOvjGS7OS tA+BH7gjjZj+Apk/RTh3p9Ni5EJrsDcWivi+GJPx0d2irMnctUNLkDt3RXK0ONfCRmhm8bdk7mbP eHhCVTbCA2cAjlhlEoICYkTjhIGOwekM4sU8/NjqfRXbTOUgKADAymLhsbLjECsQOQsTwPBWrj4r 70H6iwxezF3EgsG765skUAkE6dx980ZjwuBCRsGnwPelzpd87C5eB778Zy3ju1T6u/HvVxj8uURP beMM1D+dYRSEqf/xyZMbHbYgOhbaw1/1AggccEcJBxXaBjttzEAFFQf/LSAnxocHUdZS6Ax3UP9W ILR62xtoqi0qG4ByWboe9xdx0l/EX/1FYPD224tZfy2A1/t6xMRGKSrpTs2UZ4KvvA/Hb1pCVq+o RVHnilrQdK6oxUjnilpIdK6oRUDniprDO1fU/Nu5oubO1hWeQOKqRtEx7gYpsW+DLJR6fSsBTXpS XV5qnBuRiPtEbNaOLqxVtdvIcrFdZjRVkU5fTpaLLFHxfeeOQHXWqftiTv4YbdYiDeCU1LH1055b f6tPPc7fSeB3Qv1lgq9mEx5MDpawm1B4cq1CXybOrXwyHmWs/6qchTlldCrX062fg/t15izWWHI7 wU4bNr15J4z8z0GKe9CaTKcNpnQJJ/nwtCEum4V/kX6wjYqtIZxGTg2fM9xcgUAV27foRLuonl2d VmgHUEww5YJvAson6G+KC1++9jFFf1OKXiifoL8pXC+Uj/HR7l8201zCl1aHlF4zdu5eqFAlq21Y 5EAnPczYGWwhaCawk9jKJ5HEjJ3Be/TpnHsefHOjxCnbFzseZaCw3WFQMNnotrCdUqG9CcMitoMq WFMGVj+uZQCxSfeH/Bno38S4xQBZ2p41O9P5uGEHoASRztDftyrrPkNPGziPinIdw88lqXRoaMcN mUdFy+PJ1DuGj/sVPgZQvwrIAOpXChlADfHRfOaxNZEO0r84MrDYtGyrGIYdmZlnbGa2QLwSMFDd JJy/GrK3ORbqdZOAwnZQvW4SUNjeqdQyWzcJWIPVTQJWQ9Vo9lGZUzlGsetmGcieBAgWDUPeBKBh yJsANAx5E4D6k3c3yHDkTcBic4Pl1DJ5E4BwCuervgUqkzcBiM0Nhu3y34yKuodS2r/cDkDeBBS2 g+rkTUBhe6eJvAlYOIUTCRUsS3UErGHImwA0DHkTgIYhbwLQMORNABqGvAlA/cm7G2Q48iZgsbnB cmqZvAlAbHqwQGXyJgDhFA43HCRvzPrfTt4EFLaD6uRNQGF7p0Ko9pBKwGI7qIJlyZuAhVM4wZBj YXBzjBqGvAkWDUPeBKBhyJsANAx5E4D6k3c3yHDkTcBic4Pl1DJ5E4DY9GCByuRNAGJzw0HyxmT8 7eRNQGE7qE7eBBS2dyqEanmOgMV2UAXLkjcBC+OlN3kTgHDKS4E4Fg1D3gSLhiFvAtAw5E0A6k/e 3SDDkTcBi80NllPL5E0AYtODBSqTNwGIzQ0HyRtz5LeTNwGF7aA6eRNQ2N6pEKolbwIW20EVLEt1 BKxhyJsAhIHZm7wJQDjlBUCYRRw3DUPeBIuGIW8CUH/y7gYZjrwJWGxusJxaJm8CEJseLFCZvAlA bG7Q92zhvij5euqkIQio9wyKWw1kwGmDk6iAuYE/5Eom0GQlu2+H9AQsLGQgNoQH1cQPSj04tIvd xw0BQoYKlmGg8Er3M97SKTUiHM9aOgluv104n0wDTG0dhtT+zRvoHiq3C2F7km4cAj2z5w207GyK m+VaGjQI6b6uvAUIW+SuoSEob+vRi3WfD0zEpqp8GP9vm6PCZ0DEhXUobw1YHnREtUDlF97tHSS8 7l4FbrgVj4rsWjIKNfPb8bszlJm3d0ezVe9M3wRv0RlvirfukYNTjFfrCkJzFqrUpSG4bBmaFjP4 cB37YCE0CeJ/zYwz/SdhRMH7CxmGXwQ2pGVq0zw1lKvMvJ2MsQJWRC1VlqmoeX2CF8RRk0MCIBzK yphHbURznMTbaCkT6PBq2fOvSlcO7ETbD0lz17UhFKg73azbXrrYBPkgwlCpGG/yV4M1f2eu+aNe SwFtdt9011wtjaBF8KEYLwm9gMzpHz3QJqtDBkHH46vX04/jSyO1qXERQytvWzyxD4fbFvMWSfiz 1/s5d2/FWkVC+xK7OssDXmqfTAbYJs7JaZ4Tv3ZNnGYMfAMtp23xs8cz3jaF8MVmySqtVTe4zXPO zgUV9x1kLLSmwZlMRzZ7Dbfhf7Dfh3NC56el8Vqi4rlv97orL+qkCXdPcdGu8MBOdAV4gJypGW/u zqBBCCV40FEFLThbEeYtNTAKQVb04lKKmSWCT1BTE+33msG7N4dsbQ6iuuUFie1/90KpzRuQx4qn b+zvOABY4EonJrZU41EZWsWtCShyW8zW/eVQBs3mVDKw4Mv03X8AAAD//wMAUEsDBBQABgAIAAAA IQBff8Ug9wAAAGwBAAATAAgBZG9jUHJvcHMvY3VzdG9tLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJyQy26DMBBF95X6D9bsHRsSEkCGqIFk3UXavWUMQcIP2U5aVPXfa5Q+ 9l3O3NGZM8P272pCN+n8aHQFyYoCklqYbtRDBS/nE84B+cB1xyejZQWz9LCvHx/YszNWujBKjyJC +wouIdiSEC8uUnG/irGOSW+c4iGWbiCm70chWyOuSupAUkq3RFx9MArbXxzceeUt/BfZGbHY+dfz bKNuzb7hM+pVGLsKPtqsaduMZjg9Fg1OaHLAxbrYYZpTmh7S5lQ8HT8B2WU4BaS5iqf7fuJDpN1C Odk3H1ydbNbZbrtJipyRvy4jP/tqRhaR+5vqLwAAAP//AwBQSwMEFAAGAAgAAAAhAM1nRoBMAQAA iwIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJySX0vDMBTF3wW/Q8l7m7RjKqXtQGVPDoRNFN9CctcFmz8kcd2+vWm71Y755GN6zv3lnJsW i4Nsoj1YJ7QqUZoQFIFimgtVl+hts4wfUOQ8VZw2WkGJjuDQorq9KZjJmbbwarUB6wW4KJCUy5kp 0c57k2Ps2A4kdUlwqCButZXUh6OtsaHsi9aAM0LusARPOfUUd8DYjER0QnI2Is23bXoAZxgakKC8 w2mS4l+vByvdnwO9MnFK4Y8mdDrFnbI5G8TRfXBiNLZtm7SzPkbIn+KP1cu6rxoL1e2KAaoKznJm gXptqzXT3kcrqtxWQMMLPNG6PTbU+VVYeVD54/Hafm3ppizsRfdqVVbg6THc3Bcdrgcehej5UPSs vM+enjdLVGUkncfkPibZJiX5bJ4T8tmlu5jvqgwf5Cnjv4lnQNUnvvx9qh8AAAD//wMAUEsDBBQA BgAIAAAAIQCK4/PEkAQAAAwnAAASAAAAd29yZC9udW1iZXJpbmcueG1s7FrNbts4EL4v0HcwdE/0 Y8V2jTpF4iSLLLrFAk3RMy3TMVGJFEjJrvfYl+kj7GP1FXZIWjIteRVHUrIq4ItlcYbD4UcO+Q2p d++/RWFvhbkgjE4s99yxepgGbE7o48T6/HB3NrJ6IkF0jkJG8cTaYGG9v3zz27v1mKbRDHNQ7IEN KsbrOJhYyySJx7YtgiWOkDiPSMCZYIvkPGCRzRYLEmB7zfjc9hzXUf9izgIsBNiZIrpCwtqai8rW WIwptLVgPEKJOGf80Y4Q/5rGZ2A9RgmZkZAkG7DtDDIzbGKlnI63Dp3lDskqY+3Q9pHV4KVeHGhX 17xhQRphmqgWbY5D8IFRsSTxrht1rUEXl5lLq6pOrKIw01vHrl9qL+/yMWNww9EahmJnsGTuABhz XSkKNQ5yfHejWrToOlWd2Y6INJH7cIwL+21mnkSI0NxMPWhMcCEkmszv3zlL49ydmDSzdk+/5rZk ZD7DM2egIs/smniWgVLoflqiGFu9KBjfP1LG0SwEj9au35Mz0rqE1QLNRMJRkHxMo97e2/18YjlK hQoyB9kKhVDS92+H02vPsmXlKA0T8gGvcPiwiXGmo0pDWaq1kigOM5l7N/Wubv0rLQlXUkDgkbUF axpPcmWtBQvaXZQXztIwxEle/wF/y0U/v/+Tl/8RZFZCvNiqx39x6XUCfd4+Mx1owoL/MQO8h54j rdg7RUJl/6UdLYWXJaKPai3uDzLtrXWuG+F3jCYCNJEICEypT5toxmBBgKpXAOheAaFgeI4XCODU HRB/g6ICPHdG2QWnACzpvAmdK80msN7BMreCAXbVsDWCkrUApOv7GTYZ5CaSSizxeC6UU5Zygnnv I14beBZLm4LqtQ/qz+8/WoDVc/MpdwhWJa4D6xeYz5JfwBaZT9L9sqaQ9jsL6WhUNVM9Ke4mpH5X IYV1sQpSJe4mpBddhdTv55vBocBX4m5CCqy/7Q2qnbX0wqncopS4m5AOOwvpsHJ7upDibkIKKXU3 Z+nAr9yelLgrkAJDNVIKyVSNV3DSeJMZhqaqZobhTb1r7617oZnS4QxjuZlxMv9TZh//kWcMh9e3 7nQ4yvkWNJ3lGXKU4xCOMSD43zqO0wJdPjLzMOmvTDPqDNpzEgkYjCfTBhOJFyBoRyUSJi4vmxYE kOA9lSlUo6bzAhO1/48wmLi9Iu+vBkhPIhOgF8hPawRcbRbfXsRptm5C04WIq83Fi4GkDzYKpc0j TseXiVo3Iu4VCXd1xGl6bQLUjYirTZ/bizhNk01ouhBxtUlwIba2R4mF0uYRp5mwiVo3Iu4VmW4x 4uDdoK5P8lqvdHI+HA384ag/bcZrb65cbzC4Vkcr+4fAik2eeC3cJOjFz5y9/Vc6EDf52K/IY+W0 bnRtcOSpjInTibdOrNIV1R5AdU+f29tFT7xV3zQVL0CKm8T+inzirfISteIA4sRb4T4aIDpwpXvi rXUi7sRbSxFX5q3wrQOcO8Lv7vzVYLb38lMH/amHZKpQHTQlL9irpuntwWpuRTXNww5WU1+UZK3p p/6K7fJfAAAA//8DAFBLAwQUAAYACAAAACEALpnlTYYCAADjCQAAEgAAAHdvcmQvZm9udFRhYmxl LnhtbNSVUW/aMBSF3yftP0R+L3FCoIAKFWND2sseVqY9m+AQa7Ed2YaUf7/rOCF0mBWmddKIIHBt H5xP51w/PD7zIthTpZkUUxT1MAqoSOWGie0UfVst70Yo0IaIDSmkoFN0oBo9zt6/e6gmmRRGB7Be 6AlPpyg3ppyEoU5zyonuyZIKGMyk4sTAT7UNOVE/duVdKnlJDFuzgplDGGM8RI2MukZFZhlL6UeZ 7jgVpl4fKlqAohQ6Z6Vu1apr1CqpNqWSKdUanpkXTo8TJo4yUXImxFmqpJaZ6cHDhG5HoZWC5RGu v/ECBTydfN4Kqci6AHZVlKBZAy6oJoJwKD4d+FoWdb0kQmoawdCeFFOEB3BF2Are4yHcB/gehVYg zYnS1Bwnxq6cEc6KQ1tVkhPhBkpm0ryt74lidj9uSLMtDOz0GsMfNi/kKhH44WUlPpvTf1lJa53R ySqogM5RGbYfOuecgVgxTnXwhVbB13rndsKvRGKgMMR9IJHAO4ZviZ8I/jtEPsHG4/ly2RFZQOV+ lERNpSMybipeIvXzR07neiILuVOMKsvE648YfNHHY+BgvREDk1tocLmhymeQjD3Tzbk7LrLo/wsW 3yGctilpL4lBa7Du7veFNylkZ6Sb/l8EZUEKtlbMCyLGy9oK1hIJmAM+/SC8AdEV0/omEtYUOD4N SAKF+eJY6QLSRuY3ARnXQbs+ICuSQ6u4AOIDdAqLwPaK5M9BCGlWakdXh5LWvfc2i7TZOO2Brrt2 YODIrTvwZTAY1/CuBzOHFu8/U2LsuFiDuOvtDeLtoC2ZjsNbdFDCISmXHGLPEOcPe6bcFpXbT1d/ VHDiicrrjohejUpzzOrZTwAAAP//AwBQSwMEFAAGAAgAAAAhAI5pz6bxAQAAoAkAABQAAAB3b3Jk L3dlYlNldHRpbmdzLnhtbOxW32/bIBB+n7T/weK98Y/GSWzFqZRVnSZ167R1e8cYx2jAWUDipX/9 znbcpU2kNVK0pzwBB/dxdx8fML/5raS34cYK0BkJRwHxuGZQCL3KyI/Hu6sZ8ayjuqASNM/Illty s3j/bt6kDc+/c+dwpfUQRdtUsYxUztWp71tWcUXtCGqucbIEo6jDoVn5ippf6/qKgaqpE7mQwm39 KAgmZAdj3oICZSkYvwW2Vly7zt83XCIiaFuJ2g5ozVvQGjBFbYBxazEfJXs8RYV+hgnHB0BKMAMW SjfCZPw+Ir+FQvcw6HpKEk+x9NNKg6G5xAo24ZgssHyF2Nhd6zWpKDIShdN4FmMdWnMOxfZWbHBq QyUyQ/zWirW756UbrMGz9ZtYVUfMj1Afrl2Cc6Be2TGcZWHaPdxfH42cE1xonzKCJwM7NWWYQ9dn IAGpomsHfRhyL7LTPPMXEZ3ma/YzP8XV7zjYJd2y8aESsnhJSTgZB/EsmoQdJ5fqH3B+jur3RCzm fTvQMFg7lvDotQqZxK1Epkl8kcgpwjwHSf2FdUQiSRJOZ5PraHqRyPFr8RzVH8Twb4mESTKOo+sw iC4a+d8aecVS+5RA7YQST/wOzNJAY7np3nH8qWwf9M/P992ISgnN1y8fcYAQe/+qxR8AAAD//wMA UEsDBBQABgAIAAAAIQDq4utJ6gEAAOcDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTwW7bMAy9D9g/GL43irOs2QJFxZBu6GFbA8Rtz5pM J8JkSZDYoNnXj7IbV9l6ak6Pj8TTyyPNr546UxwgRO3sqqwm07IAq1yj7W5V3tXfLj6VRURpG2mc hVV5hFheiffv+CY4DwE1xIIkbFyVe0S/ZCyqPXQyTqhtqdO60EmkMuyYa1ut4Nqpxw4sstl0esng CcE20Fz4UbAcFJcHfKto41TyF+/royfDgtfQeSMRxM9kx0wahx1nI8trh9LUugNRET0WfCN3EMWM swHwBxeaKOaLj5wNkK/3MkiFlKCYLaopZxnBv3hvtJJI4YofWgUXXYvFbR9DkQQ4y0c4RbMF9Rg0 HgVJ5SX/rm2yQl4GRN6C3AXp91FcJoNjxbdKGlhTAKKVJgJnLwS/AZmWu5GaHPMDLg+g0IUi6j+0 3llZ/JIRUmyr8iCDlhYpvjQ2FD02PmIQtUZD2tQb6h7mYznW85QszRI4H0zk4IEa5+76F+JtS/8N XzFb5WZ7D4PVzE4Gxzf+UV27zkt7FF+DVjE6Sxt8ZlLkv+Odr911Op3nLM/JbP8PGvdbLxVt6UO1 +JxfQtbiWzoYaGi1J8EXgt9Q7sGkV+mK7A6a08z/jXRb98N3K6r5ZEq//phOHF3E+EGJvwAAAP// AwBQSwECLQAUAAYACAAAACEAQWPStKQBAADCBgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCZVX4FBAEAAOECAAALAAAAAAAAAAAAAAAAAN0DAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDKpL9MCQIAAPUIAAAcAAAAAAAAAAAAAAAAABIHAAB3 b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAOgj4ER4EAAAdGoAABEA AAAAAAAAAAAAAAAAXQoAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0ACgAAAAAAAAAhAAnhfdCFAAAA hQAAABUAAAAAAAAAAAAAAAAABBsAAHdvcmQvbWVkaWEvaW1hZ2UxLmdpZlBLAQItABQABgAIAAAA IQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAALwbAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEAGJEx6h8EAADRCgAAEQAAAAAAAAAAAAAAAACXIgAAd29yZC9zZXR0aW5ncy54 bWxQSwECLQAUAAYACAAAACEAhLFBlN4IAACEQgAAGgAAAAAAAAAAAAAAAADlJgAAd29yZC9zdHls ZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAAACEASKwu5FoIAACTPwAADwAAAAAAAAAAAAAA AAD7LwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAF9/xSD3AAAAbAEAABMAAAAAAAAA AAAAAAAAgjgAAGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAAACEAzWdGgEwBAACLAgAA EQAAAAAAAAAAAAAAAACyOgAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAiuPzxJAE AAAMJwAAEgAAAAAAAAAAAAAAAAA1PQAAd29yZC9udW1iZXJpbmcueG1sUEsBAi0AFAAGAAgAAAAh AC6Z5U2GAgAA4wkAABIAAAAAAAAAAAAAAAAA9UEAAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQA BgAIAAAAIQCOac+m8QEAAKAJAAAUAAAAAAAAAAAAAAAAAKtEAAB3b3JkL3dlYlNldHRpbmdzLnht bFBLAQItABQABgAIAAAAIQDq4utJ6gEAAOcDAAAQAAAAAAAAAAAAAAAAAM5GAABkb2NQcm9wcy9h cHAueG1sUEsFBgAAAAAPAA8AzQMAAO5JAAAAAA== --_004_EF35EE4B92789843B1DECBC0E24558644BB39F0Beusaamb105erics_-- From nobody Tue Jul 28 14:45:41 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 7E8D01B3003 for ; Tue, 28 Jul 2015 14:45: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 Rvs_nEw0K45T for ; Tue, 28 Jul 2015 14:45: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 CADF71B2AB8 for ; Tue, 28 Jul 2015 14:45:37 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id A62A61AE0492; Tue, 28 Jul 2015 23:45:35 +0200 (CEST) Date: Tue, 28 Jul 2015 23:45:35 +0200 (CEST) Message-Id: <20150728.234535.236342825744515088.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150728.115852.2189909749980729854.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 21:45:39 -0000 Andy Bierman wrote: > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > > > > > Hi, > > > > > > > > Andy Bierman wrote: > > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > > >> j.schoenwaelder@jacobs-university.de> wrote: > > > >> > > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > >>>> Hi, > > > >>>> > > > >>>> I would like to open another issue for YANG 1.1, > > > >>>> because I don't want to have 1.1 and then 1.2 right away. > > > >>>> The NETMOD WG should evaluate the different ways to > > > >>>> support ephemeral state, based on Jeff's draft. > > > > > > > > [...] > > > > > > > >> The problem with using YANG extensions for important protocol features > > > >> is that the YANG spec says these statements MAY be completely skipped > > > >> by a tool implementation. This is not acceptable for ephemeral state > > > >> (or operational state either). > > > > > > > > I don't agree that this is a problem. If i2rs defines an extension, > > > > then i2rs implementations will have to support that extension. This > > > > is the whole idea behind extensions - we should not have to revise > > > > YANG everytime we need a new statement. > > > > > > > > > > Yes, it could work in this case as long as modules containing this > > > extension are never advertised to regular NETCONF/RESTCONF clients. > > > > I think it would. Such nodes would just be seen as config false > > nodes. > > > > > I do not agree that YANG extensions are appropriate for defining standard > protocols. > They are fine for extra tools outside the scope of any protocol. > The "get filter" hack in RFC 6241 does not even work since > any tool is allowed to ignore the extension. > > The solution proposed by I2RS changed the config-stmt. > IMO this is a better solution than defining an extension > that every YANG tool MAY ignore. 6020(bis) says that a tool that doesn't understand the extension statement MAY ignore it. My point is that if I2RS defines an extension estatement, I2RS-compliant tools will have to implement this statement and they can of course not simply ignore it. Again, this is the whole point of having extensions - the language can be extended without having to revise the base specification. > Ephemeral data can be defined in any YANG module, > not in special hack modules that are not allowed to be shared > by NETCONF or RESTCONF in any way, I agree that get-filter-element-attributes is a hack. But that hack really just defines the NETCONF *protocol*. It is not applicable to RESTCONF. I do not agree that a module that defines an extension is a "special hack module". > That would be a terrible solution for ephemeral data. /martin From nobody Tue Jul 28 16:57:33 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 67FC51A0383 for ; Tue, 28 Jul 2015 16:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JCZM2SOXhyjV for ; Tue, 28 Jul 2015 16:57:28 -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 8F0681A0060 for ; Tue, 28 Jul 2015 16:57:27 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so85036718lbb.3 for ; Tue, 28 Jul 2015 16:57:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3eGiz1X6lAt1aIHYT/tWInFBS+1LWA8iLy/fYP4mSiE=; b=JqbR1NmjVOcMIOgFiHYVnAG9PBXilp8tQzvd4r/9wjj5v2TxaKwxuE+t5TZC3NmoKq cAYi2j1nrPOyNbDh5t6gea5pjKEJA+zE4FBTP5IuqYO3Phc7HrR920lhm6ZZtaPNGvNL W6by26rfqLJ3NEfll1GVc/Zg9PV+DWO1oRIAzHkwe+XxL4z1Kzn4bwYnJLB/zAvgjLxu TjcI8fmkZ9MA3L9NumZNrNcA/HCnPYHsNTMfWtMsA3YAUQyYi78piCHZUrKDwQDqKtvh ut3xf7k26vkDk5WOLlOVBXYJr0w+LMqDSfopXunkem9l6W/Mlp5mjFJpHDyeUmmKLjfE oo7A== X-Gm-Message-State: ALoCoQnHqmA/jPPmr0I/XNKnhRiX5HFqAp6z3NASTN/c6qnxpeXQCW1t5gm+QVPI7jS/bED3zj0C MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr35426601lbp.88.1438127846034; Tue, 28 Jul 2015 16:57:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 28 Jul 2015 16:57:25 -0700 (PDT) In-Reply-To: <20150728.234535.236342825744515088.mbj@tail-f.com> References: <20150728.115852.2189909749980729854.mbj@tail-f.com> <20150728.234535.236342825744515088.mbj@tail-f.com> Date: Tue, 28 Jul 2015 16:57:25 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113403d867a633051bf83b72 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Tue, 28 Jul 2015 23:57:31 -0000 --001a113403d867a633051bf83b72 Content-Type: text/plain; charset=UTF-8 Hi, I do not agree that ephemeral data should be outside the scope of the standard. I do not agree that YANG extensions should be used for IETF standards track modules. It was a mistake to define the "get-filter" hack in the first place. IMO it is a mistake to define Lada's "annotation" statement as an extension. I don't think you are correct in your interpretation of "MAY ignore". My reading of this text is that no YANG tool anywhere (or ever) MUST or even SHOULD understand any YANG extension. I don't see how YANG conformance applies to usage of extension statements. It only applies to usage of YANG statements. Andy On Tue, Jul 28, 2015 at 2:45 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund > wrote: > > > > > Ladislav Lhotka wrote: > > > > > > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: > > > > > > > > > > Hi, > > > > > > > > > > Andy Bierman wrote: > > > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < > > > > >> j.schoenwaelder@jacobs-university.de> wrote: > > > > >> > > > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: > > > > >>>> Hi, > > > > >>>> > > > > >>>> I would like to open another issue for YANG 1.1, > > > > >>>> because I don't want to have 1.1 and then 1.2 right away. > > > > >>>> The NETMOD WG should evaluate the different ways to > > > > >>>> support ephemeral state, based on Jeff's draft. > > > > > > > > > > [...] > > > > > > > > > >> The problem with using YANG extensions for important protocol > features > > > > >> is that the YANG spec says these statements MAY be completely > skipped > > > > >> by a tool implementation. This is not acceptable for ephemeral > state > > > > >> (or operational state either). > > > > > > > > > > I don't agree that this is a problem. If i2rs defines an > extension, > > > > > then i2rs implementations will have to support that extension. > This > > > > > is the whole idea behind extensions - we should not have to revise > > > > > YANG everytime we need a new statement. > > > > > > > > > > > > > Yes, it could work in this case as long as modules containing this > > > > extension are never advertised to regular NETCONF/RESTCONF clients. > > > > > > I think it would. Such nodes would just be seen as config false > > > nodes. > > > > > > > > I do not agree that YANG extensions are appropriate for defining standard > > protocols. > > They are fine for extra tools outside the scope of any protocol. > > The "get filter" hack in RFC 6241 does not even work since > > any tool is allowed to ignore the extension. > > > > The solution proposed by I2RS changed the config-stmt. > > IMO this is a better solution than defining an extension > > that every YANG tool MAY ignore. > > 6020(bis) says that a tool that doesn't understand the extension > statement MAY ignore it. My point is that if I2RS defines an > extension estatement, I2RS-compliant tools will have to implement this > statement and they can of course not simply ignore it. > > Again, this is the whole point of having extensions - the language can > be extended without having to revise the base specification. > > > Ephemeral data can be defined in any YANG module, > > not in special hack modules that are not allowed to be shared > > by NETCONF or RESTCONF in any way, > > I agree that get-filter-element-attributes is a hack. But that hack > really just defines the NETCONF *protocol*. It is not applicable to > RESTCONF. > > I do not agree that a module that defines an extension is a "special > hack module". > > > That would be a terrible solution for ephemeral data. > > > /martin > --001a113403d867a633051bf83b72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I do not agree that ephemeral data = should be outside the scope of the standard.
I do not agree that = YANG extensions should be used for IETF standards track modules.
= It was a mistake to define the "get-filter" hack in the first pla= ce.
IMO it is a mistake to define Lada's "annotation&quo= t; statement as an extension.

I don't think yo= u are correct in your interpretation of "MAY ignore".
M= y reading of this text is that no YANG tool anywhere (or ever)
MU= ST or even SHOULD understand any YANG extension.
I don't see = how YANG conformance applies to usage of extension
statements.=C2= =A0 It only applies to usage of YANG statements.

<= br>

Andy


On Tue, Jul 28, 2015 at 2:45 PM,= Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@y= umaworks.com> wrote:
> On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > >
> > > > On 28 Jul 2015, at 11:42, Martin Bjorklund <mbj@tail-f.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwae= lder <
> > > >> j.schoenwaelder@jacobs-university.de> wrote:
> > > >>
> > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy = Bierman wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> I would like to open another issue for YANG= 1.1,
> > > >>>> because I don't want to have 1.1 and th= en 1.2 right away.
> > > >>>> The NETMOD WG should evaluate the different= ways to
> > > >>>> support ephemeral state, based on Jeff'= s draft.
> > > >
> > > > [...]
> > > >
> > > >> The problem with using YANG extensions for importan= t protocol features
> > > >> is that the YANG spec says these statements MAY be = completely skipped
> > > >> by a tool implementation.=C2=A0 This is not accepta= ble for ephemeral state
> > > >> (or operational state either).
> > > >
> > > > I don't agree that this is a problem.=C2=A0 If i2rs= defines an extension,
> > > > then i2rs implementations will have to support that ext= ension.=C2=A0 This
> > > > is the whole idea behind extensions - we should not hav= e to revise
> > > > YANG everytime we need a new statement.
> > > >
> > >
> > > Yes, it could work in this case as long as modules containin= g this
> > > extension are never advertised to regular NETCONF/RESTCONF c= lients.
> >
> > I think it would.=C2=A0 Such nodes would just be seen as config f= alse
> > nodes.
> >
> >
> I do not agree that YANG extensions are appropriate for defining stand= ard
> protocols.
> They are fine for extra tools outside the scope of any protocol.
> The "get filter" hack in RFC 6241 does not even work since > any tool is allowed to ignore the extension.
>
> The solution proposed by I2RS changed the config-stmt.
> IMO this is a better solution than defining an extension
> that every YANG tool MAY ignore.

6020(bis) says that a tool that doesn't understand the extension
statement MAY ignore it.=C2=A0 My point is that if I2RS defines an
extension estatement, I2RS-compliant tools will have to implement this
statement and they can of course not simply ignore it.

Again, this is the whole point of having extensions - the language can
be extended without having to revise the base specification.

> Ephemeral data can be defined in any YANG module,
> not in special hack modules that are not allowed to be shared
> by NETCONF or RESTCONF in any way,

I agree that get-filter-element-attributes is a hack.=C2=A0 But that hack really just defines the NETCONF *protocol*.=C2=A0 It is not applicable to RESTCONF.

I do not agree that a module that defines an extension is a "special hack module".

> That would be a terrible solution for ephemeral data.


/martin

--001a113403d867a633051bf83b72-- From nobody Wed Jul 29 00:34:22 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 7BCB01B33B1 for ; Wed, 29 Jul 2015 00:34:21 -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 1HKJiL5rEfwu for ; Wed, 29 Jul 2015 00:34:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 249E91B3393 for ; Wed, 29 Jul 2015 00:34:20 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F4701AE0491; Wed, 29 Jul 2015 09:34:18 +0200 (CEST) Date: Wed, 29 Jul 2015 09:34:17 +0200 (CEST) Message-Id: <20150729.093417.1237072433774489399.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150728.234535.236342825744515088.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 07:34:21 -0000 Hi, Andy Bierman wrote: > Hi, > > I do not agree that ephemeral data should be outside the scope of the > standard. I don't think anyone has said that. > I do not agree that YANG extensions should be used for IETF standards track > modules. I strongly disagree. This was one of the two original ideas behind extension statements (the other was that vendors could add their own stuff). > It was a mistake to define the "get-filter" hack in the first place. > IMO it is a mistake to define Lada's "annotation" statement as an extension. > > I don't think you are correct in your interpretation of "MAY ignore". > My reading of this text is that no YANG tool anywhere (or ever) > MUST or even SHOULD understand any YANG extension. > I don't see how YANG conformance applies to usage of extension > statements. It only applies to usage of YANG statements. Then I think we need to clarify the text in 6020bis. /martin From nobody Wed Jul 29 01:37:22 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 8D6B21B34D7 for ; Wed, 29 Jul 2015 01:37:21 -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 6O7naCPTl7ca for ; Wed, 29 Jul 2015 01:37:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 866311B34C5 for ; Wed, 29 Jul 2015 01:37:18 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9651D1CC008C; Wed, 29 Jul 2015 10:37:17 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: <20150725082507.GA14481@elstar.local> <20150726072210.GC16276@elstar.local> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 29 Jul 2015 10:37:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items 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, 29 Jul 2015 08:37:21 -0000 Andy Bierman writes: > On Sun, Jul 26, 2015 at 12:22 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bierman wrote: >> > On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder < >> > j.schoenwaelder@jacobs-university.de> wrote: >> > >> > > This is the summary of the discussion of YANG 1.1 issue Y60 at the >> > > IETF 93 meeting in Prague: >> > > >> > > - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which >> > > will of course be interpreted according to the YANG 1.0 rules). >> > >> > I am not convinced this will be a good idea. >> > Obviously the compiler has to restrict 1.0 modules to 1.0 syntax, >> > but the corner-case semantics that have been clarified in 1.1 >> > SHOULD be followed if a 1.1 module imports 1.0, even for augment. >> > >> >> Please provide concrete examples what breaks if we allow to import >> YANG 1.0 modules (using 1.0 semantics). >> > > > I have not reviewed the YANG 1.1 draft. I am waiting for WGLC. > But from memory -- > > > -- the handling of default prefixes in XPath in groupings was clarified > -- the handling of ".." wrt/ top-level nodes in XPath in groupings > was clarified > -- I think auto-numbering of enum/bit was clarified Also Y41, Y55 and Y56. > > I guess there is no new text to add here. > If this is unspecified in 1.0 then handling it the same as 1.1 is OK > I'd suggest to write errata to RFC 6020 for each of these cases. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 01:49:55 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 1E1471A9152 for ; Wed, 29 Jul 2015 01:49:54 -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 9cN_Ne9EpEoH for ; Wed, 29 Jul 2015 01:49:52 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8283E1A8989 for ; Wed, 29 Jul 2015 01:49:52 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id CCB671CC008C; Wed, 29 Jul 2015 10:49:52 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <20150727151913.GB9620@elstar.local> References: <20150725082507.GA14481@elstar.local> <20150726072210.GC16276@elstar.local> <20150727151913.GB9620@elstar.local> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 29 Jul 2015 10:49:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items 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, 29 Jul 2015 08:49:54 -0000 Juergen Schoenwaelder writes: > On Sun, Jul 26, 2015 at 10:12:01AM -0700, Andy Bierman wrote: >> On Sun, Jul 26, 2015 at 12:22 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: ... >> > > If this is the case then I think the "restconf-media-type" hack >> > > should be a real YANG statement. The reason it is an extension >> > > is because YANG is NETCONF-only. A real statement >> > > could support augments and deviations. >> > > >> > > Just removing a sentence from the abstract is not going to fix all >> > > NETCONF-specific details in YANG. (Just ask Lada ;-) It is >> > > not going to make YANG correct for RESTCONF. >> > >> > Please provide concrete examples where YANG is incorrect for RESTCONF. >> >> The XPath context for operations are not correct. >> They are not mentioned in RESTCONF at all. >> >> YANG 1.1 should define the XPath contexts in a reusable way, >> instead of in terms of NETCONF messages. NETCONF, RESTCONF, >> and CoMI can all map these reusable contexts to their specific protocol >> messages. >> Lada has been saying this for a long time. >> > > I assume you refer to section 6.4.1 in draft-ietf-netmod-rfc6020bis-06.txt. > Can you or Lada rewrite it to be protocol agnostic? I guess the > biggest challenge are the namespace declarations for protocols that do not > use XML encoding. Anything else (except some wording changes)? I made a few comments related to this in my review of 6020bis. I think we have to define all properties of the data tree without refering to XML, and describe in more detail how the data tree maps to the XPath data model. The only task for any encoding spec will then be to define how to map encoded data to the data tree, and vice versa. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 02:36: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 1152D1A01D5 for ; Wed, 29 Jul 2015 02:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TSvjD3MSSOki for ; Wed, 29 Jul 2015 02:35:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0B41A00FE for ; Wed, 29 Jul 2015 02:35:57 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 680541CC0474; Wed, 29 Jul 2015 11:35:56 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <20150728.115852.2189909749980729854.mbj@tail-f.com> <20150728.234535.236342825744515088.mbj@tail-f.com> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 29 Jul 2015 11:35:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 09:35:59 -0000 Andy Bierman writes: > Hi, > > I do not agree that ephemeral data should be outside the scope of the > standard. > I do not agree that YANG extensions should be used for IETF standards track > modules. > It was a mistake to define the "get-filter" hack in the first place. > IMO it is a mistake to define Lada's "annotation" statement as an extension. > > I don't think you are correct in your interpretation of "MAY ignore". > My reading of this text is that no YANG tool anywhere (or ever) > MUST or even SHOULD understand any YANG extension. This was my reading, too. The text actually talks about "compiler" which is even less clear - it may apply to server or client software as well. Lada > I don't see how YANG conformance applies to usage of extension > statements. It only applies to usage of YANG statements. > > > > Andy > > > On Tue, Jul 28, 2015 at 2:45 PM, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> > On Tue, Jul 28, 2015 at 2:58 AM, Martin Bjorklund >> wrote: >> > >> > > Ladislav Lhotka wrote: >> > > > >> > > > > On 28 Jul 2015, at 11:42, Martin Bjorklund wrote: >> > > > > >> > > > > Hi, >> > > > > >> > > > > Andy Bierman wrote: >> > > > >> On Sun, Jul 26, 2015 at 12:16 AM, Juergen Schoenwaelder < >> > > > >> j.schoenwaelder@jacobs-university.de> wrote: >> > > > >> >> > > > >>> On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: >> > > > >>>> Hi, >> > > > >>>> >> > > > >>>> I would like to open another issue for YANG 1.1, >> > > > >>>> because I don't want to have 1.1 and then 1.2 right away. >> > > > >>>> The NETMOD WG should evaluate the different ways to >> > > > >>>> support ephemeral state, based on Jeff's draft. >> > > > > >> > > > > [...] >> > > > > >> > > > >> The problem with using YANG extensions for important protocol >> features >> > > > >> is that the YANG spec says these statements MAY be completely >> skipped >> > > > >> by a tool implementation. This is not acceptable for ephemeral >> state >> > > > >> (or operational state either). >> > > > > >> > > > > I don't agree that this is a problem. If i2rs defines an >> extension, >> > > > > then i2rs implementations will have to support that extension. >> This >> > > > > is the whole idea behind extensions - we should not have to revise >> > > > > YANG everytime we need a new statement. >> > > > > >> > > > >> > > > Yes, it could work in this case as long as modules containing this >> > > > extension are never advertised to regular NETCONF/RESTCONF clients. >> > > >> > > I think it would. Such nodes would just be seen as config false >> > > nodes. >> > > >> > > >> > I do not agree that YANG extensions are appropriate for defining standard >> > protocols. >> > They are fine for extra tools outside the scope of any protocol. >> > The "get filter" hack in RFC 6241 does not even work since >> > any tool is allowed to ignore the extension. >> > >> > The solution proposed by I2RS changed the config-stmt. >> > IMO this is a better solution than defining an extension >> > that every YANG tool MAY ignore. >> >> 6020(bis) says that a tool that doesn't understand the extension >> statement MAY ignore it. My point is that if I2RS defines an >> extension estatement, I2RS-compliant tools will have to implement this >> statement and they can of course not simply ignore it. >> >> Again, this is the whole point of having extensions - the language can >> be extended without having to revise the base specification. >> >> > Ephemeral data can be defined in any YANG module, >> > not in special hack modules that are not allowed to be shared >> > by NETCONF or RESTCONF in any way, >> >> I agree that get-filter-element-attributes is a hack. But that hack >> really just defines the NETCONF *protocol*. It is not applicable to >> RESTCONF. >> >> I do not agree that a module that defines an extension is a "special >> hack module". >> >> > That would be a terrible solution for ephemeral data. >> >> >> /martin >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 02:37:53 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 CF7141A0194 for ; Wed, 29 Jul 2015 02: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 WtFK3OLP7ZjW for ; Wed, 29 Jul 2015 02: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 A582C1A00FE for ; Wed, 29 Jul 2015 02:37:50 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EFDE1AE0491; Wed, 29 Jul 2015 11:37:49 +0200 (CEST) Date: Wed, 29 Jul 2015 11:37:48 +0200 (CEST) Message-Id: <20150729.113748.413804880132043767.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150728.234535.236342825744515088.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 09:37:52 -0000 Andy Bierman wrote: > I do not agree that YANG extensions should be used for IETF standards track > modules. > It was a mistake to define the "get-filter" hack in the first place. > IMO it is a mistake to define Lada's "annotation" statement as an extension. We also have extensions defined in RFC 6536 (NACM). /martin From nobody Wed Jul 29 02:49:08 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 D0C821A013B for ; Wed, 29 Jul 2015 02:49:06 -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 nD3yXdyzHLuT for ; Wed, 29 Jul 2015 02:49:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5022B1A0141 for ; Wed, 29 Jul 2015 02:49:04 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E80261CC0474; Wed, 29 Jul 2015 11:49:03 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150726114937.GB17078@elstar.local> References: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> <20150726105515.GA16978@elstar.local> <0D8E54C3-9CC1-4616-9D9D-3111ED0224FC@nic.cz> <20150726114937.GB17078@elstar.local> User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 29 Jul 2015 11:49:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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, 29 Jul 2015 09:49:07 -0000 Juergen Schoenwaelder writes: > Lada, > > there won't be any decision as long as there is not a concrete > actionable proposal to be discussed. Such a proposal does not have to > be 'complete rewrite' but it needs to be a detailed list of what would > have to change so that it is possible to assess such a proposal. This is still quite some work, so I'd first like to see an elementary consensus that it is a good thing to do now. Clearly it would mean further delay for 6020bis and all other documents that depend on it. And frankly - I need to show my employer that at least some of my IETF work ever gets finished. Lada > > /js > > On Sun, Jul 26, 2015 at 01:06:54PM +0200, Ladislav Lhotka wrote: >>=20 >> > On 26 Jul 2015, at 12:55, Juergen Schoenwaelder wrote: >> >=20 >> > Any are concrete actionable proposals? >>=20 >> Start rewriting 6020bis, but only if we decide to go that way - it is a = difficult decision. I will be slightly in favor of doing so. >>=20 >> Lada >>=20 >> >=20 >> > /js >> >=20 >> > On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: >> >>=20 >> >>> On 26 Jul 2015, at 02:26, Andy Bierman wrote: >> >>>=20 >> >>> Hi, >> >>>=20 >> >>> The WG should decide what it means for YANG to not >> >>> be NETCONF-specific. Why does YANG define extensions >> >>> to NETCONF operations (like insert)? IMO the normative text >> >>> about NETCONF should not be in the YANG RFC. >> >>>=20 >> >>=20 >> >> This is essentially what I proposed in Berlin (IETF 87): >> >>=20 >> >> http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod >> >>=20 >> >> (first item in Open mike section). >> >>=20 >> >> Another thing that I realized only recently is that some properties t= hat are inherent to the conceptual data tree are defined in =E2=80=9CXML Ma= pping=E2=80=9D sections. >> >>=20 >> >> I think most YANG concepts and statements can be defined in terms of = data tree properties. Separate documents would then define different encodi= ngs, and =E2=80=9Cprofiles=E2=80=9D for management protocols. >> >>=20 >> >> It would need massive changes in 6020bis text though. >> >>=20 >> >> Lada >> >>=20 >> >>>=20 >> >>> Andy >> >>>=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>> _______________________________________________ >> >>> netmod mailing list >> >>> netmod@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/netmod >> >>=20 >> >> -- >> >> Ladislav Lhotka, CZ.NIC Labs >> >> PGP Key ID: E74E8C0C >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> >=20 >> > --=20 >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 03:25:25 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 916B41A1BDF for ; Wed, 29 Jul 2015 03:25: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 hl0rEPNCwyC4 for ; Wed, 29 Jul 2015 03:25: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 65F4C1A1A33 for ; Wed, 29 Jul 2015 03:25: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 63DC01282; Wed, 29 Jul 2015 12:25:15 +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 y-vDU8MWGVDf; Wed, 29 Jul 2015 12:25: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; Wed, 29 Jul 2015 12:25:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 703C720046; Wed, 29 Jul 2015 12:25:16 +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 Qi7LzV7Aj1Ba; Wed, 29 Jul 2015 12:25:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B74920045; Wed, 29 Jul 2015 12:25:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6BBBE35F4C1D; Wed, 29 Jul 2015 12:25:12 +0200 (CEST) Date: Wed, 29 Jul 2015 12:25:11 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150729102511.GA13635@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150729.093417.1237072433774489399.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 10:25:23 -0000 On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > > I do not agree that YANG extensions should be used for IETF standards track > > modules. > > I strongly disagree. This was one of the two original ideas behind > extension statements (the other was that vendors could add their own > stuff). An extension defines certain semantics. For example: extension default-deny-write { description "Used to indicate that the data model node represents a sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have write access to the node. An explicit access control rule is required for all other users. The 'default-deny-write' extension MAY appear within a data definition statement. It is ignored otherwise."; } If a data model writer uses an extension, then the semantics associated with the extension are embedded in the data model. The extension can be seen as a shorthand for copying the semantics directly into the description clause. In other words, an implementation has to implement the semantics no matter which tool is used. Whether tools understand the semantics of an extension statement or not is a tool implementation issue. If a YANG tool does not support default-deny-write, an implementation still needs to provide the behaviour called out for if a data model uses this extension. Given this interpretation of extensions, I do not really understand the discussion here. /js PS: Perhaps we should change If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 13), the entire unknown-statement MAY be ignored by the compiler. to If a YANG parser does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 13), the entire unknown-statement MAY be ignored by the parser. Note that even in this case the semantics associated with the extension still apply (as if they were part of a description statement). and consistently use YANG parser everywhere instead of sometimes YANG parser and sometimes YANG compiler. -- 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 Jul 29 03:34:34 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 6B0701A1A33 for ; Wed, 29 Jul 2015 03:34:33 -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 bUXTqUDBNdxL for ; Wed, 29 Jul 2015 03:34:31 -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 8CCA91A044F for ; Wed, 29 Jul 2015 03:34:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D65E410AC; Wed, 29 Jul 2015 12:34: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 qCLoZisOvEj0; Wed, 29 Jul 2015 12:34: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; Wed, 29 Jul 2015 12:34:27 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8620120046; Wed, 29 Jul 2015 12:34:29 +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 tscJzz71-8Fn; Wed, 29 Jul 2015 12:34:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D128520045; Wed, 29 Jul 2015 12:34:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 670C835F4C75; Wed, 29 Jul 2015 12:34:24 +0200 (CEST) Date: Wed, 29 Jul 2015 12:34:24 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150729103422.GA13703@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> <20150726105515.GA16978@elstar.local> <0D8E54C3-9CC1-4616-9D9D-3111ED0224FC@nic.cz> <20150726114937.GB17078@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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, 29 Jul 2015 10:34:33 -0000 On Wed, Jul 29, 2015 at 11:49:01AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > Lada, > > > > there won't be any decision as long as there is not a concrete > > actionable proposal to be discussed. Such a proposal does not have to > > be 'complete rewrite' but it needs to be a detailed list of what would > > have to change so that it is possible to assess such a proposal. > > This is still quite some work, so I'd first like to see an elementary > consensus that it is a good thing to do now. I think the WG needs to see a half way complete list of changes that this implies in order to form an opinion, something like 'section X needs to be rewritten', 'section X needs to be split into A and B', 'section X does not require any changes' etc. Unless we have an outline of how much work this is, we simply do not know what we are talking about. > Clearly it would mean further delay for 6020bis and all other documents > that depend on it. And frankly - I need to show my employer that at > least some of my IETF work ever gets finished. I agree. If such a reorganization costs say more of four additional weeks, I have a hard time to like it. /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 Jul 29 03:43:55 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 2D29A1A8033 for ; Wed, 29 Jul 2015 03:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 XttmfvtFV5i5 for ; Wed, 29 Jul 2015 03:43:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F271A70E1 for ; Wed, 29 Jul 2015 03:43:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml406-hub.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGQ99025; Wed, 29 Jul 2015 05:43:50 -0500 (CDT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 29 Jul 2015 11:42:26 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.124]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0158.001; Wed, 29 Jul 2015 18:41:51 +0800 From: Tina TSOU To: Juergen Schoenwaelder Thread-Topic: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific Thread-Index: AQHQxzm3dKTre3Z1Mkiq8+5r/EXPm53tDA8AgAACfICAAANBAIAAC++AgASVTYCAAAyuAIAAiDCB Date: Wed, 29 Jul 2015 10:41:50 +0000 Message-ID: <95C1E663-0BCD-459B-AECC-C4E8EAC740CA@huawei.com> References: <7864CE12-9C25-4681-A76E-E3B24062A42F@nic.cz> <20150726105515.GA16978@elstar.local> <0D8E54C3-9CC1-4616-9D9D-3111ED0224FC@nic.cz> <20150726114937.GB17078@elstar.local> ,<20150729103422.GA13703@elstar.local> In-Reply-To: <20150729103422.GA13703@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_95C1E6630BCD459BAECCC4E8EAC740CAhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific 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, 29 Jul 2015 10:43:54 -0000 --_000_95C1E6630BCD459BAECCC4E8EAC740CAhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Agree with Lada and Juergen, regarding quantifying the changes and the time= frame. Thank you, Tina On Jul 29, 2015, at 6:35 PM, Juergen Schoenwaelder > wrote: On Wed, Jul 29, 2015 at 11:49:01AM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder > writes: Lada, there won't be any decision as long as there is not a concrete actionable proposal to be discussed. Such a proposal does not have to be 'complete rewrite' but it needs to be a detailed list of what would have to change so that it is possible to assess such a proposal. This is still quite some work, so I'd first like to see an elementary consensus that it is a good thing to do now. I think the WG needs to see a half way complete list of changes that this implies in order to form an opinion, something like 'section X needs to be rewritten', 'section X needs to be split into A and B', 'section X does not require any changes' etc. Unless we have an outline of how much work this is, we simply do not know what we are talking about. Clearly it would mean further delay for 6020bis and all other documents that depend on it. And frankly - I need to show my employer that at least some of my IETF work ever gets finished. I agree. If such a reorganization costs say more of four additional weeks, I have a hard time to like it. /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 --_000_95C1E6630BCD459BAECCC4E8EAC740CAhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,

Agree with Lada and Juergen, regardin= g quantifying the changes and the time frame.


Thank you,
Tina

On Jul 29, 2015, at 6:35 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Jul 29, 2015 at 11:49:01AM +0200, Ladislav Lhotka wr= ote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > writes:

Lada,

there won't be any decision as long as ther= e is not a concrete
actionable proposal to be discussed. Such a= proposal does not have to
be 'complete rewrite' but it needs to be a = detailed list of what would
have to change so that it is possible to as= sess such a proposal.

This is still quite some work, so I'd first= like to see an elementary
consensus that it is a good thing to do now= .

I think the WG needs to see a half way complete list of changes that<= /span>
this implies in order to form an opinion, something like 'section X
needs to be rewritten', 'section X needs to be split into A and B',
'section X does not require any changes' etc. Unless we have an
outline of how much work this is, we simply do not know what we are
talking about.

Clearly it would mean further delay for 602= 0bis and all other documents
that depend on it. And frankly - I need to = show my employer that at
least some of my IETF work ever gets finish= ed.

I agree. If such a reorganization costs say more of four additional
weeks, I have a hard time to like it.

/js

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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.= ietf.org/mailman/listinfo/netmod
--_000_95C1E6630BCD459BAECCC4E8EAC740CAhuaweicom_-- From nobody Wed Jul 29 03:57:17 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 2778D1A8749 for ; Wed, 29 Jul 2015 03:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 rm7Ko8_qgrig for ; Wed, 29 Jul 2015 03:57:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB2F1A8745 for ; Wed, 29 Jul 2015 03:57:12 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id F2437180C46; Wed, 29 Jul 2015 12:57:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438167431; bh=sp7p83qz1MQkcgm4mvgVDO+irh/1CNpfXUZynr5P1A4=; h=From:Date:To; b=LcEXY61Ewi4SFhv4qMeim8VBG+f04xf+oefOsX9r2NO2inIq4XLY0edD6OSLRu7e6 lpFgymZX7oa3R6Aj0sk7KKuFDeqfLAoL3xC93Lofk/bn79XPLZNXnc1mTFCpEZ4tQ8 93if4bJbIkY2IOVxuhnfBr68zaQqDBWSpKpSdDrk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729102511.GA13635@elstar.local> Date: Wed, 29 Jul 2015 12:57:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 10:57:15 -0000 > On 29 Jul 2015, at 12:25, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: >> Hi, >>=20 >> Andy Bierman wrote: >>=20 >>> I do not agree that YANG extensions should be used for IETF = standards track >>> modules. >>=20 >> I strongly disagree. This was one of the two original ideas behind >> extension statements (the other was that vendors could add their own >> stuff). >=20 > An extension defines certain semantics. For example: >=20 > extension default-deny-write { > description > "Used to indicate that the data model node > represents a sensitive security system parameter. >=20 > If present, and the NACM module is enabled (i.e., > /nacm/enable-nacm object equals 'true'), the NETCONF server > will only allow the designated 'recovery session' to have > write access to the node. An explicit access control rule = is > required for all other users. >=20 > The 'default-deny-write' extension MAY appear within a data > definition statement. It is ignored otherwise."; > } >=20 > If a data model writer uses an extension, then the semantics > associated with the extension are embedded in the data model. The > extension can be seen as a shorthand for copying the semantics > directly into the description clause. In other words, an The difference is that YANG spec doesn=E2=80=99t say descriptions may be = ignored. > implementation has to implement the semantics no matter which > tool is used. I agree, but then I think the text you have in PS should be removed = entirely. There is again the issue of old client support that IMO = doesn=E2=80=99t hold water anyway: a client that doesn=E2=80=99t fully = understand the semantics of the data model cannot be guaranteed to work, = and is in fact dangerous. Lada >=20 > Whether tools understand the semantics of an extension statement or > not is a tool implementation issue. If a YANG tool does not support > default-deny-write, an implementation still needs to provide the > behaviour called out for if a data model uses this extension. >=20 > Given this interpretation of extensions, I do not really understand > the discussion here. >=20 > /js >=20 > PS: Perhaps we should change >=20 > If a YANG compiler does not support a particular extension, = which > appears in a YANG module as an unknown-statement (see Section = 13), > the entire unknown-statement MAY be ignored by the compiler. >=20 > to=20 >=20 > If a YANG parser does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section = 13), > the entire unknown-statement MAY be ignored by the parser. Note > that even in this case the semantics associated with the = extension > still apply (as if they were part of a description statement). >=20 > and consistently use YANG parser everywhere instead of sometimes = YANG > parser and sometimes YANG compiler. >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 04:47:58 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 130B51A87C5 for ; Wed, 29 Jul 2015 04:47: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 1r6ZRq043TFs for ; Wed, 29 Jul 2015 04:47: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 F21E71A8788 for ; Wed, 29 Jul 2015 04:47:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3A54012C6; Wed, 29 Jul 2015 13:47:51 +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 q0EX93-Lgr6O; Wed, 29 Jul 2015 13:47: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; Wed, 29 Jul 2015 13:47:49 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AC2420047; Wed, 29 Jul 2015 13:47: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 zK_tE7l7u9FN; Wed, 29 Jul 2015 13:47:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DC0920045; Wed, 29 Jul 2015 13:47:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2BDEB35F4DDD; Wed, 29 Jul 2015 13:47:47 +0200 (CEST) Date: Wed, 29 Jul 2015 13:47:47 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150729114747.GA13893@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@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] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 11:47:57 -0000 On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: > > > On 29 Jul 2015, at 12:25, Juergen Schoenwaelder wrote: > > > > On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: > >> Hi, > >> > >> Andy Bierman wrote: > >> > >>> I do not agree that YANG extensions should be used for IETF standards track > >>> modules. > >> > >> I strongly disagree. This was one of the two original ideas behind > >> extension statements (the other was that vendors could add their own > >> stuff). > > > > An extension defines certain semantics. For example: > > > > extension default-deny-write { > > description > > "Used to indicate that the data model node > > represents a sensitive security system parameter. > > > > If present, and the NACM module is enabled (i.e., > > /nacm/enable-nacm object equals 'true'), the NETCONF server > > will only allow the designated 'recovery session' to have > > write access to the node. An explicit access control rule is > > required for all other users. > > > > The 'default-deny-write' extension MAY appear within a data > > definition statement. It is ignored otherwise."; > > } > > > > If a data model writer uses an extension, then the semantics > > associated with the extension are embedded in the data model. The > > extension can be seen as a shorthand for copying the semantics > > directly into the description clause. In other words, an > > The difference is that YANG spec doesn’t say descriptions may be ignored. I do not get it, please help me. > > implementation has to implement the semantics no matter which > > tool is used. > > I agree, but then I think the text you have in PS should be removed entirely. There is again the issue of old client support that IMO doesn’t hold water anyway: a client that doesn’t fully understand the semantics of the data model cannot be guaranteed to work, and is in fact dangerous. > Again, I do not get it. There are non-machine readable semantics anyway. A decent client better understands the semantics - otherwise it is just a clueless yang browser. So why is there a problem with extension statements (which are just a shorthand for semantics that happen to be machine readable for those tools that are programmed to read and understand them). /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 Jul 29 05:24:11 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 9F43D1A8940 for ; Wed, 29 Jul 2015 05:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 NLQwQiN8LTsw for ; Wed, 29 Jul 2015 05:24:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18DD1A8934 for ; Wed, 29 Jul 2015 05:24:06 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id EB89E180C0C; Wed, 29 Jul 2015 14:24:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438172644; bh=qNmsVAu2KPq6Hjw0BDIyXPUa+oIm1FQN84C2VQOxPNs=; h=From:Date:To; b=Z54t/D2MZ/4/xfBSqBAxEUJlEd8oMfhDTz1enUHSafF/hNLjK7feWw0Ot5FYmodzi kSN/sm9Rt0D9iWnw2pBfoqrSokUaLn0YUnnaBxFXjX0PIOtQ86vp//sNrNs8lf3po2 lec2w4ywPxRkjP1FQjU9IzbJUtc6dsI+d6hVI83I= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729114747.GA13893@elstar.local> Date: Wed, 29 Jul 2015 14:24:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 12:24:10 -0000 > On 29 Jul 2015, at 13:47, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder = wrote: >>>=20 >>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: >>>> Hi, >>>>=20 >>>> Andy Bierman wrote: >>>>=20 >>>>> I do not agree that YANG extensions should be used for IETF = standards track >>>>> modules. >>>>=20 >>>> I strongly disagree. This was one of the two original ideas behind >>>> extension statements (the other was that vendors could add their = own >>>> stuff). >>>=20 >>> An extension defines certain semantics. For example: >>>=20 >>> extension default-deny-write { >>> description >>> "Used to indicate that the data model node >>> represents a sensitive security system parameter. >>>=20 >>> If present, and the NACM module is enabled (i.e., >>> /nacm/enable-nacm object equals 'true'), the NETCONF server >>> will only allow the designated 'recovery session' to have >>> write access to the node. An explicit access control rule = is >>> required for all other users. >>>=20 >>> The 'default-deny-write' extension MAY appear within a data >>> definition statement. It is ignored otherwise."; >>> } >>>=20 >>> If a data model writer uses an extension, then the semantics >>> associated with the extension are embedded in the data model. The >>> extension can be seen as a shorthand for copying the semantics >>> directly into the description clause. In other words, an >>=20 >> The difference is that YANG spec doesn=E2=80=99t say descriptions may = be ignored. >=20 > I do not get it, please help me. A client that ignores constraints expressed in a description statement = should be considered broken. I am not sure it is also the case for a = client that ignores an extension and the implied semantics, because sec. = 6.3.1 seems to allow it. In fact, I think it can be applied to the server, too: An implementor = may take a module, remove extensions he doesn=E2=80=99t want to = implement (or let a =E2=80=9Ccompiler=E2=80=9D remove them) and = implement the modified form of the module. >=20 >>> implementation has to implement the semantics no matter which >>> tool is used. >>=20 >> I agree, but then I think the text you have in PS should be removed = entirely. There is again the issue of old client support that IMO = doesn=E2=80=99t hold water anyway: a client that doesn=E2=80=99t fully = understand the semantics of the data model cannot be guaranteed to work, = and is in fact dangerous. >>=20 >=20 > Again, I do not get it. There are non-machine readable semantics > anyway. A decent client better understands the semantics - otherwise > it is just a clueless yang browser. So why is there a problem with > extension statements (which are just a shorthand for semantics that > happen to be machine readable for those tools that are programmed to > read and understand them). As I said, it is unclear (to me at least) from the text in 6.3.1 whether = extensions are an integral part of the contract expressed by the module. = If I had a contract with an insurance company saying =E2=80=9CAnybody = who cannot read fine print may ignore it=E2=80=9D, I would get quite = nervous. 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 05:58:03 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 D669E1A8A7F for ; Wed, 29 Jul 2015 05:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=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 6Un8P941Tj0a for ; Wed, 29 Jul 2015 05:57: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 292281A8A4D for ; Wed, 29 Jul 2015 05:57:59 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 4AD971AE0491; Wed, 29 Jul 2015 14:57:57 +0200 (CEST) Date: Wed, 29 Jul 2015 14:57:57 +0200 (CEST) Message-Id: <20150729.145757.1271023696132663288.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> References: <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 12:58:01 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjkgSnVs IDIwMTUsIGF0IDEzOjQ3LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiANCj4gPiBPbiBXZWQsIEp1bCAy OSwgMjAxNSBhdCAxMjo1NzowOVBNICswMjAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4+ IA0KPiA+Pj4gT24gMjkgSnVsIDIwMTUsIGF0IDEyOjI1LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIN Cj4gPj4+IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+ Pj4gDQo+ID4+PiBPbiBXZWQsIEp1bCAyOSwgMjAxNSBhdCAwOTozNDoxN0FNICswMjAwLCBNYXJ0 aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+Pj4+IEhpLA0KPiA+Pj4+IA0KPiA+Pj4+IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPj4+PiANCj4gPj4+Pj4gSSBkbyBu b3QgYWdyZWUgdGhhdCBZQU5HIGV4dGVuc2lvbnMgc2hvdWxkIGJlIHVzZWQgZm9yIElFVEYgc3Rh bmRhcmRzDQo+ID4+Pj4+IHRyYWNrDQo+ID4+Pj4+IG1vZHVsZXMuDQo+ID4+Pj4gDQo+ID4+Pj4g SSBzdHJvbmdseSBkaXNhZ3JlZS4gIFRoaXMgd2FzIG9uZSBvZiB0aGUgdHdvIG9yaWdpbmFsIGlk ZWFzIGJlaGluZA0KPiA+Pj4+IGV4dGVuc2lvbiBzdGF0ZW1lbnRzICh0aGUgb3RoZXIgd2FzIHRo YXQgdmVuZG9ycyBjb3VsZCBhZGQgdGhlaXIgb3duDQo+ID4+Pj4gc3R1ZmYpLg0KPiA+Pj4gDQo+ ID4+PiBBbiBleHRlbnNpb24gZGVmaW5lcyBjZXJ0YWluIHNlbWFudGljcy4gRm9yIGV4YW1wbGU6 DQo+ID4+PiANCj4gPj4+IGV4dGVuc2lvbiBkZWZhdWx0LWRlbnktd3JpdGUgew0KPiA+Pj4gICBk ZXNjcmlwdGlvbg0KPiA+Pj4gICAgICAgICAiVXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBkYXRh IG1vZGVsIG5vZGUNCj4gPj4+ICAgICAgICAgIHJlcHJlc2VudHMgYSBzZW5zaXRpdmUgc2VjdXJp dHkgc3lzdGVtIHBhcmFtZXRlci4NCj4gPj4+IA0KPiA+Pj4gICAgICAgICAgSWYgcHJlc2VudCwg YW5kIHRoZSBOQUNNIG1vZHVsZSBpcyBlbmFibGVkIChpLmUuLA0KPiA+Pj4gICAgICAgICAgL25h Y20vZW5hYmxlLW5hY20gb2JqZWN0IGVxdWFscyAndHJ1ZScpLCB0aGUgTkVUQ09ORiBzZXJ2ZXIN Cj4gPj4+ICAgICAgICAgIHdpbGwgb25seSBhbGxvdyB0aGUgZGVzaWduYXRlZCAncmVjb3Zlcnkg c2Vzc2lvbicgdG8gaGF2ZQ0KPiA+Pj4gICAgICAgICAgd3JpdGUgYWNjZXNzIHRvIHRoZSBub2Rl LiAgQW4gZXhwbGljaXQgYWNjZXNzIGNvbnRyb2wgcnVsZSBpcw0KPiA+Pj4gICAgICAgICAgcmVx dWlyZWQgZm9yIGFsbCBvdGhlciB1c2Vycy4NCj4gPj4+IA0KPiA+Pj4gICAgICAgICAgVGhlICdk ZWZhdWx0LWRlbnktd3JpdGUnIGV4dGVuc2lvbiBNQVkgYXBwZWFyIHdpdGhpbiBhIGRhdGENCj4g Pj4+ICAgICAgICAgIGRlZmluaXRpb24gc3RhdGVtZW50LiAgSXQgaXMgaWdub3JlZCBvdGhlcndp c2UuIjsNCj4gPj4+IH0NCj4gPj4+IA0KPiA+Pj4gSWYgYSBkYXRhIG1vZGVsIHdyaXRlciB1c2Vz IGFuIGV4dGVuc2lvbiwgdGhlbiB0aGUgc2VtYW50aWNzDQo+ID4+PiBhc3NvY2lhdGVkIHdpdGgg dGhlIGV4dGVuc2lvbiBhcmUgZW1iZWRkZWQgaW4gdGhlIGRhdGEgbW9kZWwuIFRoZQ0KPiA+Pj4g ZXh0ZW5zaW9uIGNhbiBiZSBzZWVuIGFzIGEgc2hvcnRoYW5kIGZvciBjb3B5aW5nIHRoZSBzZW1h bnRpY3MNCj4gPj4+IGRpcmVjdGx5IGludG8gdGhlIGRlc2NyaXB0aW9uIGNsYXVzZS4gSW4gb3Ro ZXIgd29yZHMsIGFuDQo+ID4+IA0KPiA+PiBUaGUgZGlmZmVyZW5jZSBpcyB0aGF0IFlBTkcgc3Bl YyBkb2VzbuKAmXQgc2F5IGRlc2NyaXB0aW9ucyBtYXkgYmUNCj4gPj4gaWdub3JlZC4NCj4gPiAN Cj4gPiBJIGRvIG5vdCBnZXQgaXQsIHBsZWFzZSBoZWxwIG1lLg0KPiANCj4gQSBjbGllbnQgdGhh dCBpZ25vcmVzIGNvbnN0cmFpbnRzIGV4cHJlc3NlZCBpbiBhIGRlc2NyaXB0aW9uIHN0YXRlbWVu dA0KPiBzaG91bGQgYmUgY29uc2lkZXJlZCBicm9rZW4uIEkgYW0gbm90IHN1cmUgaXQgaXMgYWxz byB0aGUgY2FzZSBmb3IgYQ0KPiBjbGllbnQgdGhhdCBpZ25vcmVzIGFuIGV4dGVuc2lvbiBhbmQg dGhlIGltcGxpZWQgc2VtYW50aWNzLCBiZWNhdXNlDQo+IHNlYy4gNi4zLjEgc2VlbXMgdG8gYWxs b3cgaXQuDQoNClRoZSByZWFzb24gdGhhdCB0aGUgdGV4dCBhYm91dCBNQVkgaWdub3JlIGlzIHRo ZXJlIHdhcyB0byBhbGxvdyBhIHRvb2wNCmxpa2UgcHlhbmcgdG8gZnVuY3Rpb24gZXZlbiBpZiBp dCBmaW5kcyBhbiBleHRlbnNpb24gbGlrZSB5dW1hOnJvb3QgaW4NCmEgbW9kZWwuICBweWFuZyBk b2Vzbid0ICJ1bmRlcnN0YW5kIiB0aGlzIGV4dGVuc2lvbiwgeWV0IGl0IGNhbg0KcHJvY2VzcyB0 aGUgbW9kdWxlLg0KDQpJIGxpa2UgSnVlcmdlbnMgYW5hbG9neSB3aXRoIHRleHQgaW4gdGhlIGRl c2NyaXB0aW9uIHN0YXRlbWVudCAtIHlvdQ0KY2FuIHdyaXRlIGFueSBydWxlcyBpbiB0aGUgZGVz Y3JpcHRpb24gc3RhdGVtZW50LCBvciB5b3UgY2FuIGNob29zZSB0bw0KZm9ybWFsaXplIGl0IGlu IGFuIGV4dGVuc2lvbi4gIFNvbWV0aW1lcyBzdWNoIHJ1bGVzIGFyZSBkaXJlY3RlZCB0byBhDQpj bGllbnQsIHNvbWV0aW1lcyB0byBhIHNlcnZlciwgc29tZXRpbWVzIHRvIHRoZSBZQU5HIGNvbXBp bGVyDQooZS5nLiwgY29kZSBnZW5lcmF0aW9uIGRpcmVjdGl2ZXMpLCBhbmQgc29tZXRpbWVzIHRv IGh1bWFucyByZWFkaW5nDQp0aGUgbW9kdWxlLg0KDQoNCi9tYXJ0aW4NCg0KDQo+IEluIGZhY3Qs IEkgdGhpbmsgaXQgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIHNlcnZlciwgdG9vOiBBbiBpbXBsZW1l bnRvcg0KPiBtYXkgdGFrZSBhIG1vZHVsZSwgcmVtb3ZlIGV4dGVuc2lvbnMgaGUgZG9lc27igJl0 IHdhbnQgdG8gaW1wbGVtZW50IChvcg0KPiBsZXQgYSDigJxjb21waWxlcuKAnSByZW1vdmUgdGhl bSkgYW5kIGltcGxlbWVudCB0aGUgbW9kaWZpZWQgZm9ybSBvZiB0aGUNCj4gbW9kdWxlLg0KPiAN Cj4gPiANCj4gPj4+IGltcGxlbWVudGF0aW9uIGhhcyB0byBpbXBsZW1lbnQgdGhlIHNlbWFudGlj cyBubyBtYXR0ZXIgd2hpY2gNCj4gPj4+IHRvb2wgaXMgdXNlZC4NCj4gPj4gDQo+ID4+IEkgYWdy ZWUsIGJ1dCB0aGVuIEkgdGhpbmsgdGhlIHRleHQgeW91IGhhdmUgaW4gUFMgc2hvdWxkIGJlIHJl bW92ZWQNCj4gPj4gZW50aXJlbHkuIFRoZXJlIGlzIGFnYWluIHRoZSBpc3N1ZSBvZiBvbGQgY2xp ZW50IHN1cHBvcnQgdGhhdCBJTU8NCj4gPj4gZG9lc27igJl0IGhvbGQgd2F0ZXIgYW55d2F5OiBh IGNsaWVudCB0aGF0IGRvZXNu4oCZdCBmdWxseSB1bmRlcnN0YW5kIHRoZQ0KPiA+PiBzZW1hbnRp Y3Mgb2YgdGhlIGRhdGEgbW9kZWwgY2Fubm90IGJlIGd1YXJhbnRlZWQgdG8gd29yaywgYW5kIGlz IGluDQo+ID4+IGZhY3QgZGFuZ2Vyb3VzLg0KPiA+PiANCj4gPiANCj4gPiBBZ2FpbiwgSSBkbyBu b3QgZ2V0IGl0LiBUaGVyZSBhcmUgbm9uLW1hY2hpbmUgcmVhZGFibGUgc2VtYW50aWNzDQo+ID4g YW55d2F5LiBBIGRlY2VudCBjbGllbnQgYmV0dGVyIHVuZGVyc3RhbmRzIHRoZSBzZW1hbnRpY3Mg LSBvdGhlcndpc2UNCj4gPiBpdCBpcyBqdXN0IGEgY2x1ZWxlc3MgeWFuZyBicm93c2VyLiBTbyB3 aHkgaXMgdGhlcmUgYSBwcm9ibGVtIHdpdGgNCj4gPiBleHRlbnNpb24gc3RhdGVtZW50cyAod2hp Y2ggYXJlIGp1c3QgYSBzaG9ydGhhbmQgZm9yIHNlbWFudGljcyB0aGF0DQo+ID4gaGFwcGVuIHRv IGJlIG1hY2hpbmUgcmVhZGFibGUgZm9yIHRob3NlIHRvb2xzIHRoYXQgYXJlIHByb2dyYW1tZWQg dG8NCj4gPiByZWFkIGFuZCB1bmRlcnN0YW5kIHRoZW0pLg0KPiANCj4gQXMgSSBzYWlkLCBpdCBp cyB1bmNsZWFyICh0byBtZSBhdCBsZWFzdCkgZnJvbSB0aGUgdGV4dCBpbiA2LjMuMQ0KPiB3aGV0 aGVyIGV4dGVuc2lvbnMgYXJlIGFuIGludGVncmFsIHBhcnQgb2YgdGhlIGNvbnRyYWN0IGV4cHJl c3NlZCBieQ0KPiB0aGUgbW9kdWxlLiBJZiBJIGhhZCBhIGNvbnRyYWN0IHdpdGggYW4gaW5zdXJh bmNlIGNvbXBhbnkgc2F5aW5nDQo+IOKAnEFueWJvZHkgd2hvIGNhbm5vdCByZWFkIGZpbmUgcHJp bnQgbWF5IGlnbm9yZSBpdOKAnSwgSSB3b3VsZCBnZXQgcXVpdGUNCj4gbmVydm91cy4NCj4gDQo+ IExhZGENCj4gDQo+ID4gDQo+ID4gL2pzDQo+ID4gDQo+ID4gLS0gDQo+ID4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDov L3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90a2Es IENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0KPiANCj4gDQo+IA0K From nobody Wed Jul 29 06:46:36 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 41F451A1B20 for ; Wed, 29 Jul 2015 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 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_44=0.6, 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 k4nGQtUMu6th for ; Wed, 29 Jul 2015 06:46:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20241A0419 for ; Wed, 29 Jul 2015 06:46:31 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:8cd0:8953:5269:71f1] (unknown [IPv6:2001:718:1a02:1:8cd0:8953:5269:71f1]) by mail.nic.cz (Postfix) with ESMTPSA id 7DDA91810E4; Wed, 29 Jul 2015 15:46:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438177590; bh=sLcuHzjSUbfhe1zQ2OcU5x/BKYrGeXFqUxePOcFxeyg=; h=From:Date:To; b=QdH21qHem91SzCEHcbW6T+AXI1tZT8NkuvPRX7VuGWWnmkSNBOA8+BVWmKdLAmco3 7MJhAVOA6d2Zob+tRf/djWyyQidfQ1hn1O1jiEdmHDEGzL8MPFELR8rdJehvUbjTlk Ssj6l4PT3EqLY4bK0vmOXY/5qKFoX04g4Njmpsuc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729.145757.1271023696132663288.mbj@tail-f.com> Date: Wed, 29 Jul 2015 15:46:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34D29B3E-89A4-42EA-A369-AAE75D50AC8C@nic.cz> References: <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729.145757.1271023696132663288.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 13:46:34 -0000 > On 29 Jul 2015, at 14:57, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 29 Jul 2015, at 13:47, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Andy Bierman wrote: >>>>>>=20 >>>>>>> I do not agree that YANG extensions should be used for IETF = standards >>>>>>> track >>>>>>> modules. >>>>>>=20 >>>>>> I strongly disagree. This was one of the two original ideas = behind >>>>>> extension statements (the other was that vendors could add their = own >>>>>> stuff). >>>>>=20 >>>>> An extension defines certain semantics. For example: >>>>>=20 >>>>> extension default-deny-write { >>>>> description >>>>> "Used to indicate that the data model node >>>>> represents a sensitive security system parameter. >>>>>=20 >>>>> If present, and the NACM module is enabled (i.e., >>>>> /nacm/enable-nacm object equals 'true'), the NETCONF = server >>>>> will only allow the designated 'recovery session' to have >>>>> write access to the node. An explicit access control rule = is >>>>> required for all other users. >>>>>=20 >>>>> The 'default-deny-write' extension MAY appear within a = data >>>>> definition statement. It is ignored otherwise."; >>>>> } >>>>>=20 >>>>> If a data model writer uses an extension, then the semantics >>>>> associated with the extension are embedded in the data model. The >>>>> extension can be seen as a shorthand for copying the semantics >>>>> directly into the description clause. In other words, an >>>>=20 >>>> The difference is that YANG spec doesn=E2=80=99t say descriptions = may be >>>> ignored. >>>=20 >>> I do not get it, please help me. >>=20 >> A client that ignores constraints expressed in a description = statement >> should be considered broken. I am not sure it is also the case for a >> client that ignores an extension and the implied semantics, because >> sec. 6.3.1 seems to allow it. >=20 > The reason that the text about MAY ignore is there was to allow a tool > like pyang to function even if it finds an extension like yuma:root in > a model. pyang doesn't "understand" this extension, yet it can > process the module. I think this is unnecessary. After all, I can write a tool that ignores = everything in a module except the module name, so what? Is that tool = illegal? RFC 2119 keywords should be primarily used where it matters to = interoperability, i.e. client/server contract. >=20 > I like Juergens analogy with text in the description statement - you > can write any rules in the description statement, or you can choose to > formalize it in an extension. Sometimes such rules are directed to a > client, sometimes to a server, sometimes to the YANG compiler > (e.g., code generation directives), and sometimes to humans reading > the module. But in order to determine whether a given extension is directed to a = piece of software, I need to know the semantics of that extension. If I = have no idea what yuma:root means, it may not be safe to ignore it. I think it is important to understand that all extensions in the data = model advertised by the server are an integral part of the model. If an = implementation or tool ignores an extension because it=E2=80=99s of no = interest to it, then OK but it=E2=80=99s the implementor=E2=80=99s = responsibility. Lada >=20 >=20 > /martin >=20 >=20 >> In fact, I think it can be applied to the server, too: An implementor >> may take a module, remove extensions he doesn=E2=80=99t want to = implement (or >> let a =E2=80=9Ccompiler=E2=80=9D remove them) and implement the = modified form of the >> module. >>=20 >>>=20 >>>>> implementation has to implement the semantics no matter which >>>>> tool is used. >>>>=20 >>>> I agree, but then I think the text you have in PS should be removed >>>> entirely. There is again the issue of old client support that IMO >>>> doesn=E2=80=99t hold water anyway: a client that doesn=E2=80=99t = fully understand the >>>> semantics of the data model cannot be guaranteed to work, and is in >>>> fact dangerous. >>>>=20 >>>=20 >>> Again, I do not get it. There are non-machine readable semantics >>> anyway. A decent client better understands the semantics - otherwise >>> it is just a clueless yang browser. So why is there a problem with >>> extension statements (which are just a shorthand for semantics that >>> happen to be machine readable for those tools that are programmed to >>> read and understand them). >>=20 >> As I said, it is unclear (to me at least) from the text in 6.3.1 >> whether extensions are an integral part of the contract expressed by >> the module. If I had a contract with an insurance company saying >> =E2=80=9CAnybody who cannot read fine print may ignore it=E2=80=9D, I = would get quite >> nervous. >>=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 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 07:14:16 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 40AB91A6EEC for ; Wed, 29 Jul 2015 07:14: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 74OBpicbU3QO for ; Wed, 29 Jul 2015 07:14: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 132E51A1EF3 for ; Wed, 29 Jul 2015 07:14:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 32DB914B5; Wed, 29 Jul 2015 16:14:06 +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 wp7GjiXPXrqM; Wed, 29 Jul 2015 16:14: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; Wed, 29 Jul 2015 16:14:04 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13E6D20045; Wed, 29 Jul 2015 16:14:07 +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 tbiPRkHguwMJ; Wed, 29 Jul 2015 16:14: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 8C1FD20046; Wed, 29 Jul 2015 16:14:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1BBFA35F502E; Wed, 29 Jul 2015 16:14:03 +0200 (CEST) Date: Wed, 29 Jul 2015 16:14:03 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150729141403.GA14223@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@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: <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 14:14:15 -0000 On Wed, Jul 29, 2015 at 02:24:03PM +0200, Ladislav Lhotka wrote: > > > On 29 Jul 2015, at 13:47, Juergen Schoenwaelder wrote: > > > > On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: > >> > >>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder wrote: > >>> > >>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: > >>>> Hi, > >>>> > >>>> Andy Bierman wrote: > >>>> > >>>>> I do not agree that YANG extensions should be used for IETF standards track > >>>>> modules. > >>>> > >>>> I strongly disagree. This was one of the two original ideas behind > >>>> extension statements (the other was that vendors could add their own > >>>> stuff). > >>> > >>> An extension defines certain semantics. For example: > >>> > >>> extension default-deny-write { > >>> description > >>> "Used to indicate that the data model node > >>> represents a sensitive security system parameter. > >>> > >>> If present, and the NACM module is enabled (i.e., > >>> /nacm/enable-nacm object equals 'true'), the NETCONF server > >>> will only allow the designated 'recovery session' to have > >>> write access to the node. An explicit access control rule is > >>> required for all other users. > >>> > >>> The 'default-deny-write' extension MAY appear within a data > >>> definition statement. It is ignored otherwise."; > >>> } > >>> > >>> If a data model writer uses an extension, then the semantics > >>> associated with the extension are embedded in the data model. The > >>> extension can be seen as a shorthand for copying the semantics > >>> directly into the description clause. In other words, an > >> > >> The difference is that YANG spec doesn’t say descriptions may be ignored. > > > > I do not get it, please help me. > > A client that ignores constraints expressed in a description statement should be considered broken. I am not sure it is also the case for a client that ignores an extension and the implied semantics, because sec. 6.3.1 seems to allow it. > > In fact, I think it can be applied to the server, too: An implementor may take a module, remove extensions he doesn’t want to implement (or let a “compiler” remove them) and implement the modified form of the module. > As I tried to explain, I believe there is confusion between a tool skipping over an extension statement and the semantics that are applied to the data model. The text in 6.3.1 talks about the tool (the 'compiler'). > >>> implementation has to implement the semantics no matter which > >>> tool is used. > >> > >> I agree, but then I think the text you have in PS should be removed entirely. There is again the issue of old client support that IMO doesn’t hold water anyway: a client that doesn’t fully understand the semantics of the data model cannot be guaranteed to work, and is in fact dangerous. > >> > > > > Again, I do not get it. There are non-machine readable semantics > > anyway. A decent client better understands the semantics - otherwise > > it is just a clueless yang browser. So why is there a problem with > > extension statements (which are just a shorthand for semantics that > > happen to be machine readable for those tools that are programmed to > > read and understand them). > > As I said, it is unclear (to me at least) from the text in 6.3.1 whether extensions are an integral part of the contract expressed by the module. If I had a contract with an insurance company saying “Anybody who cannot read fine print may ignore it”, I would get quite nervous. I believe this is a mis-interpretation of the text in 6.3.1. and I tried to propose new text that hopefully clarifies this. You agree with the proposed text? /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 Jul 29 07:38:56 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 534D91A874C for ; Wed, 29 Jul 2015 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 GOfDK-h2f4Fz for ; Wed, 29 Jul 2015 07:38:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8911A87A6 for ; Wed, 29 Jul 2015 07:38:45 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id BCDB71813B2; Wed, 29 Jul 2015 16:38:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438180723; bh=aGSwr2abvGDyNiFx+bgaEqD/zuNbKxRYp2Hb1wQN7pU=; h=From:Date:To; b=HqfQBp4Lw6qE9FtHx2a0U2nzVOeLTAyfrchz/SvCJeIYtLpGPHNMkRvIetMyvZdQG tqUC8HgxXHuH3MP7fRih8NPn5Jiphwvh8hxLbaEcaRtydOGjFnWma4thypZOUvXGLg rQSh5DmWPAvUHboz7D9eNjxpIWpOcP8wH4cfpknM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729141403.GA14223@elstar.local> Date: Wed, 29 Jul 2015 16:38:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A20A56D-8F9E-4915-9AA5-87F1B6E326C8@nic.cz> References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 14:38:55 -0000 > On 29 Jul 2015, at 16:14, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 29, 2015 at 02:24:03PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 29 Jul 2015, at 13:47, Juergen Schoenwaelder = wrote: >>>=20 >>> On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Andy Bierman wrote: >>>>>>=20 >>>>>>> I do not agree that YANG extensions should be used for IETF = standards track >>>>>>> modules. >>>>>>=20 >>>>>> I strongly disagree. This was one of the two original ideas = behind >>>>>> extension statements (the other was that vendors could add their = own >>>>>> stuff). >>>>>=20 >>>>> An extension defines certain semantics. For example: >>>>>=20 >>>>> extension default-deny-write { >>>>> description >>>>> "Used to indicate that the data model node >>>>> represents a sensitive security system parameter. >>>>>=20 >>>>> If present, and the NACM module is enabled (i.e., >>>>> /nacm/enable-nacm object equals 'true'), the NETCONF = server >>>>> will only allow the designated 'recovery session' to have >>>>> write access to the node. An explicit access control rule = is >>>>> required for all other users. >>>>>=20 >>>>> The 'default-deny-write' extension MAY appear within a = data >>>>> definition statement. It is ignored otherwise."; >>>>> } >>>>>=20 >>>>> If a data model writer uses an extension, then the semantics >>>>> associated with the extension are embedded in the data model. The >>>>> extension can be seen as a shorthand for copying the semantics >>>>> directly into the description clause. In other words, an >>>>=20 >>>> The difference is that YANG spec doesn=E2=80=99t say descriptions = may be ignored. >>>=20 >>> I do not get it, please help me. >>=20 >> A client that ignores constraints expressed in a description = statement should be considered broken. I am not sure it is also the case = for a client that ignores an extension and the implied semantics, = because sec. 6.3.1 seems to allow it. >>=20 >> In fact, I think it can be applied to the server, too: An implementor = may take a module, remove extensions he doesn=E2=80=99t want to = implement (or let a =E2=80=9Ccompiler=E2=80=9D remove them) and = implement the modified form of the module. >>=20 >=20 > As I tried to explain, I believe there is confusion between a tool > skipping over an extension statement and the semantics that are > applied to the data model. The text in 6.3.1 talks about the tool > (the 'compiler'). >=20 >>>>> implementation has to implement the semantics no matter which >>>>> tool is used. >>>>=20 >>>> I agree, but then I think the text you have in PS should be removed = entirely. There is again the issue of old client support that IMO = doesn=E2=80=99t hold water anyway: a client that doesn=E2=80=99t fully = understand the semantics of the data model cannot be guaranteed to work, = and is in fact dangerous. >>>>=20 >>>=20 >>> Again, I do not get it. There are non-machine readable semantics >>> anyway. A decent client better understands the semantics - otherwise >>> it is just a clueless yang browser. So why is there a problem with >>> extension statements (which are just a shorthand for semantics that >>> happen to be machine readable for those tools that are programmed to >>> read and understand them). >>=20 >> As I said, it is unclear (to me at least) from the text in 6.3.1 = whether extensions are an integral part of the contract expressed by the = module. If I had a contract with an insurance company saying =E2=80=9CAnyb= ody who cannot read fine print may ignore it=E2=80=9D, I would get quite = nervous. >=20 > I believe this is a mis-interpretation of the text in 6.3.1. and I > tried to propose new text that hopefully clarifies this. You agree > with the proposed text? The first part about parser behaviour still doesn=E2=80=99t make much = sense to me and may be misinterpreted. I think that even a parser that = does understand an extension may ignore it. It all depends on what the = parser output is used for. I would just say (somewhere) that descriptions and extensions are = integral and binding parts of the data model. Unless I missed something, = it is not clearly stated for descriptions either. 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 07:44:57 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 6A9A41A87DE for ; Wed, 29 Jul 2015 07:44:55 -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 wvV7JPdFtDOs for ; Wed, 29 Jul 2015 07:44:53 -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 CE6CB1A87A5 for ; Wed, 29 Jul 2015 07:44:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8D1B126D; Wed, 29 Jul 2015 16:44: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 Pxof3gaqI3ye; Wed, 29 Jul 2015 16:44:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 29 Jul 2015 16:44:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4B9E20048; Wed, 29 Jul 2015 16:44:50 +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 kIdcouTXX_Pe; Wed, 29 Jul 2015 16:44:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D63C20047; Wed, 29 Jul 2015 16:44:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D254C35F5142; Wed, 29 Jul 2015 16:44:46 +0200 (CEST) Date: Wed, 29 Jul 2015 16:44:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150729144446.GA14397@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> <3A20A56D-8F9E-4915-9AA5-87F1B6E326C8@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: <3A20A56D-8F9E-4915-9AA5-87F1B6E326C8@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 14:44:56 -0000 On Wed, Jul 29, 2015 at 04:38:41PM +0200, Ladislav Lhotka wrote: > > The first part about parser behaviour still doesn’t make much sense to me and may be misinterpreted. I think that even a parser that does understand an extension may ignore it. It all depends on what the parser output is used for. > Oh boy - very high level of nitpicking. > I would just say (somewhere) that descriptions and extensions are integral and binding parts of the data model. Unless I missed something, it is not clearly stated for descriptions either. I tried to say so. Looking forward to your improved proposal. /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 Jul 29 08:18:18 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 1391E1A8822 for ; Wed, 29 Jul 2015 08:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 xiy9yhxPwf8i for ; Wed, 29 Jul 2015 08:18:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50E71A8824 for ; Wed, 29 Jul 2015 07:55:07 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:8cd0:8953:5269:71f1] (unknown [IPv6:2001:718:1a02:1:8cd0:8953:5269:71f1]) by mail.nic.cz (Postfix) with ESMTPSA id 2BBBA180C0C; Wed, 29 Jul 2015 16:55:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438181706; bh=Y2/ZJxXavRIC3ZhqznPMQXO31tpjLu9F4gNrEV0EDFY=; h=From:Date:To; b=wbK+IycwX9Mqtt9TKjURztHKns0nXGV4kFzaZTiDYxD8mQYLRIkChzjbbZvSQE5ga BT90qPISYiF2Nir0GejbmpYLfIe7a1KRANI7rCavUDCRs3IS+jDtcTH9t+tUbkoZgs uu7DAavJ7BqxbweQ/1ghVuTtIHycxc294EjfpFoE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729144446.GA14397@elstar.local> Date: Wed, 29 Jul 2015 16:55:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> <3A20A56D-8F9E-4915-9AA5-87F1B6E326C8@nic.cz> <20150729144446.GA14397@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:18:17 -0000 > On 29 Jul 2015, at 16:44, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 29, 2015 at 04:38:41PM +0200, Ladislav Lhotka wrote: >>=20 >> The first part about parser behaviour still doesn=E2=80=99t make much = sense to me and may be misinterpreted. I think that even a parser that = does understand an extension may ignore it. It all depends on what the = parser output is used for. >>=20 >=20 > Oh boy - very high level of nitpicking. >=20 >> I would just say (somewhere) that descriptions and extensions are = integral and binding parts of the data model. Unless I missed something, = it is not clearly stated for descriptions either. >=20 > I tried to say so. Looking forward to your improved proposal. >=20 OK, here it is: Sec. 7.21.3 ----------- Add this paragraph at the end: Constraints and rules stated in the text of a =E2=80=9Cdescription=E2=80=9D= statement are an integral and binding part of the data model. Sec. 6.3.1 ---------- OLD If a YANG compiler does not support a particular extension, which = appears in a YANG module as an unknown-statement (see Section 13), the = entire unknown-statement MAY be ignored by the compiler. NEW Extensions and their semantics as defined by the corresponding = =E2=80=9Cextension=E2=80=9D statement are an integral and binding part = of the data model. Lada > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 08:20: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 1D0A11A89F1 for ; Wed, 29 Jul 2015 08:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 6106NBXjCTYa for ; Wed, 29 Jul 2015 08:20:54 -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 1A5841B3028 for ; Wed, 29 Jul 2015 08:00:22 -0700 (PDT) Received: by lafd3 with SMTP id d3so8001432laf.1 for ; Wed, 29 Jul 2015 08:00:20 -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=MKanO9uvk7Aa701C4OGBUXaXmdQ7PtfNOpS/H7s2+Yg=; b=KveTur1eoNdCQ1NUk3uDk78sfR1o6+xeJMBighB78txTGhosueDugMLeAQYYRGI1cc VkBzI7Dt34eIoCa3VBKk7egYIP+3oD8x6Fta4/OR6qGEJ417poliXPGREc1todgbMft/ h60MCVwr6VaeReH3r5KQfJlOmCg3PaXx+7dDx7Y3yjYBBfp8T5uwKFa/AY3Fq19G5CLC 1K2lN8WeC4w9j+Xh1dA5wdzbaUpYYlU50/YrpG0TVnBptPvHzs44XuqrcLppsiaIkRIV wqkhCKxM8VxBLjDaILmmdZwsNxEHqT7IDVoiXZbFheTuYwTIchhiD5SbL3kPEiJYK6aI NmXQ== X-Gm-Message-State: ALoCoQn1NJARs4LVfa+sLPfNQ88A9wl0mbY6hUHCwqtwdW/pZ2AyOawDed/NXQ2AWCArREMD//5w MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr39220853lbz.33.1438182020399; Wed, 29 Jul 2015 08:00:20 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Jul 2015 08:00:20 -0700 (PDT) In-Reply-To: <20150729141403.GA14223@elstar.local> References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> Date: Wed, 29 Jul 2015 08:00:20 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134946c72e3c0051c04d862 Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:20:57 -0000 --001a1134946c72e3c0051c04d862 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, So why don't we make all the new YANG 1.1 statements like "action" into extensions? This is just as good, right? It seems like real keywords are for feature you like, and extensions are for features you don't like. IMO ephemeral state is much more fundamental than the action-stmt. Every YANG tool MUST understand any statements added for this purpose. Andy On Wed, Jul 29, 2015 at 7:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jul 29, 2015 at 02:24:03PM +0200, Ladislav Lhotka wrote: > > > > > On 29 Jul 2015, at 13:47, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: > > >> > > >>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > >>> > > >>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: > > >>>> Hi, > > >>>> > > >>>> Andy Bierman wrote: > > >>>> > > >>>>> I do not agree that YANG extensions should be used for IETF > standards track > > >>>>> modules. > > >>>> > > >>>> I strongly disagree. This was one of the two original ideas behin= d > > >>>> extension statements (the other was that vendors could add their o= wn > > >>>> stuff). > > >>> > > >>> An extension defines certain semantics. For example: > > >>> > > >>> extension default-deny-write { > > >>> description > > >>> "Used to indicate that the data model node > > >>> represents a sensitive security system parameter. > > >>> > > >>> If present, and the NACM module is enabled (i.e., > > >>> /nacm/enable-nacm object equals 'true'), the NETCONF serve= r > > >>> will only allow the designated 'recovery session' to have > > >>> write access to the node. An explicit access control rule > is > > >>> required for all other users. > > >>> > > >>> The 'default-deny-write' extension MAY appear within a dat= a > > >>> definition statement. It is ignored otherwise."; > > >>> } > > >>> > > >>> If a data model writer uses an extension, then the semantics > > >>> associated with the extension are embedded in the data model. The > > >>> extension can be seen as a shorthand for copying the semantics > > >>> directly into the description clause. In other words, an > > >> > > >> The difference is that YANG spec doesn=E2=80=99t say descriptions ma= y be > ignored. > > > > > > I do not get it, please help me. > > > > A client that ignores constraints expressed in a description statement > should be considered broken. I am not sure it is also the case for a clie= nt > that ignores an extension and the implied semantics, because sec. 6.3.1 > seems to allow it. > > > > In fact, I think it can be applied to the server, too: An implementor > may take a module, remove extensions he doesn=E2=80=99t want to implement= (or let a > =E2=80=9Ccompiler=E2=80=9D remove them) and implement the modified form o= f the module. > > > > As I tried to explain, I believe there is confusion between a tool > skipping over an extension statement and the semantics that are > applied to the data model. The text in 6.3.1 talks about the tool > (the 'compiler'). > > > >>> implementation has to implement the semantics no matter which > > >>> tool is used. > > >> > > >> I agree, but then I think the text you have in PS should be removed > entirely. There is again the issue of old client support that IMO doesn= =E2=80=99t > hold water anyway: a client that doesn=E2=80=99t fully understand the sem= antics of > the data model cannot be guaranteed to work, and is in fact dangerous. > > >> > > > > > > Again, I do not get it. There are non-machine readable semantics > > > anyway. A decent client better understands the semantics - otherwise > > > it is just a clueless yang browser. So why is there a problem with > > > extension statements (which are just a shorthand for semantics that > > > happen to be machine readable for those tools that are programmed to > > > read and understand them). > > > > As I said, it is unclear (to me at least) from the text in 6.3.1 whethe= r > extensions are an integral part of the contract expressed by the module. = If > I had a contract with an insurance company saying =E2=80=9CAnybody who ca= nnot read > fine print may ignore it=E2=80=9D, I would get quite nervous. > > I believe this is a mis-interpretation of the text in 6.3.1. and I > tried to propose new text that hopefully clarifies this. You agree > with the proposed text? > > /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 > --001a1134946c72e3c0051c04d862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

So why don't we make all the ne= w YANG 1.1 statements like "action"
into extensions? Th= is is just as good, right?=C2=A0 It seems like real keywords
are = for feature you like, and extensions are for features you don't like.
IMO ephemeral state is much more fundamental than the action-stmt.=
Every YANG tool MUST understand any statements added for thi= s purpose.


Andy



On Wed, Jul 29, 2015 at 7:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jul 29, 2015 at 02:24:03PM +0200, Ladislav = Lhotka wrote:
>
> > On 29 Jul 2015, at 13:47, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit= y.de> wrote:
> >
> > On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote:<= br> > >>
> >>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder <j.schoenwaelder@jacobs-u= niversity.de> wrote:
> >>>
> >>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklun= d wrote:
> >>>> Hi,
> >>>>
> >>>> Andy Bierman <andy@yumaworks.com> wrote:
> >>>>
> >>>>> I do not agree that YANG extensions should be use= d for IETF standards track
> >>>>> modules.
> >>>>
> >>>> I strongly disagree.=C2=A0 This was one of the two or= iginal ideas behind
> >>>> extension statements (the other was that vendors coul= d add their own
> >>>> stuff).
> >>>
> >>> An extension defines certain semantics. For example:
> >>>
> >>> extension default-deny-write {
> >>>=C2=A0 =C2=A0description
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Used to indicate t= hat the data model node
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 represents a sensitive = security system parameter.
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If present, and the NAC= M module is enabled (i.e.,
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /nacm/enable-nacm objec= t equals 'true'), the NETCONF server
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will only allow the des= ignated 'recovery session' to have
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 write access to the nod= e.=C2=A0 An explicit access control rule is
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 required for all other = users.
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The 'default-deny-w= rite' extension MAY appear within a data
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition statement.= =C2=A0 It is ignored otherwise.";
> >>> }
> >>>
> >>> If a data model writer uses an extension, then the semant= ics
> >>> associated with the extension are embedded in the data mo= del. The
> >>> extension can be seen as a shorthand for copying the sema= ntics
> >>> directly into the description clause. In other words, an<= br> > >>
> >> The difference is that YANG spec doesn=E2=80=99t say descript= ions may be ignored.
> >
> > I do not get it, please help me.
>
> A client that ignores constraints expressed in a description statement= should be considered broken. I am not sure it is also the case for a clien= t that ignores an extension and the implied semantics, because sec. 6.3.1 s= eems to allow it.
>
> In fact, I think it can be applied to the server, too: An implementor = may take a module, remove extensions he doesn=E2=80=99t want to implement (= or let a =E2=80=9Ccompiler=E2=80=9D remove them) and implement the modified= form of the module.
>

As I tried to explain, I believe there is confusion between a tool
skipping over an extension statement and the semantics that are
applied to the data model. The text in 6.3.1 talks about the tool
(the 'compiler').

> >>> implementation has to implement the semantics no matter w= hich
> >>> tool is used.
> >>
> >> I agree, but then I think the text you have in PS should be r= emoved entirely. There is again the issue of old client support that IMO do= esn=E2=80=99t hold water anyway: a client that doesn=E2=80=99t fully unders= tand the semantics of the data model cannot be guaranteed to work, and is i= n fact dangerous.
> >>
> >
> > Again, I do not get it. There are non-machine readable semantics<= br> > > anyway. A decent client better understands the semantics - otherw= ise
> > it is just a clueless yang browser. So why is there a problem wit= h
> > extension statements (which are just a shorthand for semantics th= at
> > happen to be machine readable for those tools that are programmed= to
> > read and understand them).
>
> As I said, it is unclear (to me at least) from the text in 6.3.1 wheth= er extensions are an integral part of the contract expressed by the module.= If I had a contract with an insurance company saying =E2=80=9CAnybody who = cannot read fine print may ignore it=E2=80=9D, I would get quite nervous.
I believe this is a mis-interpretation of the text in 6.3.1. and I
tried to propose new text that hopefully clarifies this. You agree
with the proposed text?

/js

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

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

--001a1134946c72e3c0051c04d862-- From nobody Wed Jul 29 08:21:49 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 D9D591A8A46 for ; Wed, 29 Jul 2015 08:21:47 -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 oaittKFnPkKy for ; Wed, 29 Jul 2015 08:21: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 2AFA91A8A17 for ; Wed, 29 Jul 2015 08:02: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 465FE1206; Wed, 29 Jul 2015 17:02:29 +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 Bw3AQ7oiJTLl; Wed, 29 Jul 2015 17:02:28 +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, 29 Jul 2015 17:02:28 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 394FB20046; Wed, 29 Jul 2015 17:02: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 GDugT5R8AhKh; Wed, 29 Jul 2015 17:02:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F2E720045; Wed, 29 Jul 2015 17:02:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E19035F5263; Wed, 29 Jul 2015 17:02:28 +0200 (CEST) Date: Wed, 29 Jul 2015 17:02:28 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150729150228.GD14397@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> <3A20A56D-8F9E-4915-9AA5-87F1B6E326C8@nic.cz> <20150729144446.GA14397@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] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:21:48 -0000 On Wed, Jul 29, 2015 at 04:55:03PM +0200, Ladislav Lhotka wrote: > > > On 29 Jul 2015, at 16:44, Juergen Schoenwaelder wrote: > > > > On Wed, Jul 29, 2015 at 04:38:41PM +0200, Ladislav Lhotka wrote: > >> > >> The first part about parser behaviour still doesn’t make much sense to me and may be misinterpreted. I think that even a parser that does understand an extension may ignore it. It all depends on what the parser output is used for. > >> > > > > Oh boy - very high level of nitpicking. > > > >> I would just say (somewhere) that descriptions and extensions are integral and binding parts of the data model. Unless I missed something, it is not clearly stated for descriptions either. > > > > I tried to say so. Looking forward to your improved proposal. > > > > OK, here it is: > > Sec. 7.21.3 > ----------- > > Add this paragraph at the end: > > Constraints and rules stated in the text of a “description” statement are an integral and binding part of the data model. > > Sec. 6.3.1 > ---------- > > OLD > > If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 13), the entire unknown-statement MAY be ignored by the compiler. > > NEW > > Extensions and their semantics as defined by the corresponding “extension” statement are an integral and binding part of the data model. > Well, this leaves it open whether a tool can skip over extension statements. I liked to have the difference explained... /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 Jul 29 08:24:17 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 B6B591A8887 for ; Wed, 29 Jul 2015 08:24: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 7JGhq0Y12gHN for ; Wed, 29 Jul 2015 08:24: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 17ECF1A9084 for ; Wed, 29 Jul 2015 08:09: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 3184EF7D; Wed, 29 Jul 2015 17:09: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 5-73eHPmYqfW; Wed, 29 Jul 2015 17:09: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; Wed, 29 Jul 2015 17:09:35 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5517220045; Wed, 29 Jul 2015 17:09:38 +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 L2RdJo8yRaQT; Wed, 29 Jul 2015 17:09: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 0831320046; Wed, 29 Jul 2015 17:09:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 81CD135F528F; Wed, 29 Jul 2015 17:09:35 +0200 (CEST) Date: Wed, 29 Jul 2015 17:09:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150729150935.GE14397@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:24:15 -0000 On Wed, Jul 29, 2015 at 08:00:20AM -0700, Andy Bierman wrote: > Hi, > > So why don't we make all the new YANG 1.1 statements like "action" > into extensions? This is just as good, right? It seems like real keywords > are for feature you like, and extensions are for features you don't like. I guess we leave constructive communication here. > IMO ephemeral state is much more fundamental than the action-stmt. > Every YANG tool MUST understand any statements added for this purpose. Again, it remains unclear to me whether any changes to YANG are needed to support ephemeral state and as long as this is case (there is no agreement on the solution for ephemeral state) I am not that much interested to further delay YANG 1.1. There was agreement when we started work on YANG 1.1 that we want to finish this in a reasonable amount of time (~ 1 year) and I hope this agreement still holds true since this is what I am trying to achieve. /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 Jul 29 08:25:14 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 828921A9078 for ; Wed, 29 Jul 2015 08:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 qvdHhwdgHgy0 for ; Wed, 29 Jul 2015 08:25:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AAA1A8820 for ; Wed, 29 Jul 2015 08:11:36 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 6F1C6181420; Wed, 29 Jul 2015 17:11:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438182695; bh=5kYjPBdmPKnZV83HVbsxQkJMKQYnSktGFCb67uINh0M=; h=From:Date:To; b=ug/+h4W7F4PI8Xquu/RxN5FNKE9m9sKjVKBOYW8sf9Ltqyv/YEb+9uVojfkj8mwO2 IoCF7YYnVmIsIziS8hX22WlY1oUAysYDG0a3GnxMQWFjx5WytSJy0GWH/U5STOUW0G D9BtTxNYggeo16De/bFHB7PpG+pccxfPBlgxXoxo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729150228.GD14397@elstar.local> Date: Wed, 29 Jul 2015 17:11:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AC8C68F-2759-4702-8372-2D12763F527A@nic.cz> References: <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> <3A20A56D-8F9E-4915-9AA5-87F1B6E326C8@nic.cz> <20150729144446.GA14397@elstar.local> <20150729150228.GD14397@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:25:08 -0000 > On 29 Jul 2015, at 17:02, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 29, 2015 at 04:55:03PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 29 Jul 2015, at 16:44, Juergen Schoenwaelder = wrote: >>>=20 >>> On Wed, Jul 29, 2015 at 04:38:41PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>> The first part about parser behaviour still doesn=E2=80=99t make = much sense to me and may be misinterpreted. I think that even a parser = that does understand an extension may ignore it. It all depends on what = the parser output is used for. >>>>=20 >>>=20 >>> Oh boy - very high level of nitpicking. >>>=20 >>>> I would just say (somewhere) that descriptions and extensions are = integral and binding parts of the data model. Unless I missed something, = it is not clearly stated for descriptions either. >>>=20 >>> I tried to say so. Looking forward to your improved proposal. >>>=20 >>=20 >> OK, here it is: >>=20 >> Sec. 7.21.3 >> ----------- >>=20 >> Add this paragraph at the end: >>=20 >> Constraints and rules stated in the text of a =E2=80=9Cdescription=E2=80= =9D statement are an integral and binding part of the data model. >>=20 >> Sec. 6.3.1 >> ---------- >>=20 >> OLD >>=20 >> If a YANG compiler does not support a particular extension, which = appears in a YANG module as an unknown-statement (see Section 13), the = entire unknown-statement MAY be ignored by the compiler. >>=20 >> NEW >>=20 >> Extensions and their semantics as defined by the corresponding = =E2=80=9Cextension=E2=80=9D statement are an integral and binding part = of the data model. >>=20 >=20 > Well, this leaves it open whether a tool can skip over extension > statements. I liked to have the difference explained=E2=80=A6 Martin just said that tools normally skip extensions that are not = directed to them. Tools can do whatever they are designed to do, and = skip over ANY parts that are not important for the given task. 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 08:29:47 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 CEFBD1A88D8 for ; Wed, 29 Jul 2015 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 FkKStxyiSmAF for ; Wed, 29 Jul 2015 08:29:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172C01A88E4 for ; Wed, 29 Jul 2015 08:19:32 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id BEE75180E8F; Wed, 29 Jul 2015 17:19:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438183170; bh=yJpng7qZ6A9pnq8DWOCLbaki8ysC4RJ2NX1qRMDfq24=; h=From:Date:To; b=m35xrHtoItDv9Mm9g6ggB+mcNonIXnXasQzwdHoPlfz/hcuIykGbEmRxxO1p4aid0 +fHE1cU7l+ojsxYEXNaftgaNaF2VqsLCMSbNtMhWSxFdAbiPONtkwRsDMPeJAXaz4T m/NSZ8LXLp3HqON7YxXF93npHpeuZ9Wg+DUMxLHE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150729150935.GE14397@elstar.local> Date: Wed, 29 Jul 2015 17:19:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82E94198-B7F5-4569-8E83-135044A8B628@nic.cz> References: <20150728.234535.236342825744515088.mbj@tail-f.com> <20150729.093417.1237072433774489399.mbj@tail-f.com> <20150729102511.GA13635@elstar.local> <20150729114747.GA13893@elstar.local> <669241B4-F0AC-4E85-AD70-F141035DFEC8@nic.cz> <20150729141403.GA14223@elstar.local> <20150729150935.GE14397@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:29:47 -0000 > On 29 Jul 2015, at 17:09, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jul 29, 2015 at 08:00:20AM -0700, Andy Bierman wrote: >> Hi, >>=20 >> So why don't we make all the new YANG 1.1 statements like "action" >> into extensions? This is just as good, right? It seems like real = keywords >> are for feature you like, and extensions are for features you don't = like. >=20 > I guess we leave constructive communication here. Actually, Andy has a point. We could have saved a massive amount of time = by leaving action as an extension. Balazs could have already written a = draft about it, and it could be used with YANG 1.0, too. I really thought this wasn=E2=80=99t possible because of the non-binding = character of extensions. Lada >=20 >> IMO ephemeral state is much more fundamental than the action-stmt. >> Every YANG tool MUST understand any statements added for this = purpose. >=20 > Again, it remains unclear to me whether any changes to YANG are needed > to support ephemeral state and as long as this is case (there is no > agreement on the solution for ephemeral state) I am not that much > interested to further delay YANG 1.1. There was agreement when we > started work on YANG 1.1 that we want to finish this in a reasonable > amount of time (~ 1 year) and I hope this agreement still holds true > since this is what I am trying to achieve. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 29 08:50:58 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 E5FE81A87C6 for ; Wed, 29 Jul 2015 08:50:56 -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 451BWn5KRqhy for ; Wed, 29 Jul 2015 08:50: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 C20EA1A0041 for ; Wed, 29 Jul 2015 08:50:55 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id E1F6A1AE0491; Wed, 29 Jul 2015 17:50:53 +0200 (CEST) Date: Wed, 29 Jul 2015 17:50:53 +0200 (CEST) Message-Id: <20150729.175053.1703900717736836161.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <82E94198-B7F5-4569-8E83-135044A8B628@nic.cz> References: <20150729150935.GE14397@elstar.local> <82E94198-B7F5-4569-8E83-135044A8B628@nic.cz> 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] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 15:50:57 -0000 Ladislav Lhotka wrote: > > > On 29 Jul 2015, at 17:09, Juergen Schoenwaelder > > wrote: > > > > On Wed, Jul 29, 2015 at 08:00:20AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> So why don't we make all the new YANG 1.1 statements like "action" > >> into extensions? This is just as good, right? It seems like real > >> keywords > >> are for feature you like, and extensions are for features you don't > >> like. > > > > I guess we leave constructive communication here. > > Actually, Andy has a point. We could have saved a massive amount of > time by leaving action as an extension. Balazs could have already > written a draft about it, and it could be used with YANG 1.0, too. I am not sure how interesting this is, but yes, action could have been done as an extension statement. In fact, that's what we (and others) have been doing since 6020 was published. The difference here is that action has been around and used for several years, whereas we don't even have agreement that "config ephemeral" is the right solution to the problem. /martin From nobody Wed Jul 29 09:00:56 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 AE8ED1A1EEE for ; Wed, 29 Jul 2015 09:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gY4Bqaa1703Q for ; Wed, 29 Jul 2015 09:00:52 -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 085EE1A92FF for ; Wed, 29 Jul 2015 08:58:41 -0700 (PDT) Received: by lagw2 with SMTP id w2so9046109lag.3 for ; Wed, 29 Jul 2015 08:58:39 -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=7NNhKHZ+57xikTNCTI21MwJ+mw8URX+Um5Ge7vAWrBw=; b=jkY0+qtOOvH2f7VEQ+htZ2I0EeWNPPyvphjRMI/yYYV/MDQuzQNg3NpsJNz0Ept0vF mpb/oWpMyVuixewcPTh9IpweofNY3vW8BNIyrE9Fr4hOo9hcwu7hC0blu5o2WNpr1wBX ERJ6ZpH41H/c57XD39S8tjFvBgy3STwmkSa6eQCsMhMQ73qtR6JFB7UQtY3pHT1tZLvI IwQxpG54/IIB/Svkl6WV/V3EwWsG0fa5MfWAXqIhekwhJ3+p1MaVGp2LacNSd9VPggUf CStjbJZBsoAlDssPRmPCuYJCGn2oUGTwkhoeLtNTmOWP+QLxxpNet01SSfpf9g6GKM4l Gljg== X-Gm-Message-State: ALoCoQmTTcSuouvwNQ74UsMj60bM8dAu9Y91ELGe0AFGsbg3yFYO69wPl6uyLpGjhSz+pMYMIvco MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr39131661lab.38.1438185519495; Wed, 29 Jul 2015 08:58:39 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Jul 2015 08:58:39 -0700 (PDT) In-Reply-To: <20150729.175053.1703900717736836161.mbj@tail-f.com> References: <20150729150935.GE14397@elstar.local> <82E94198-B7F5-4569-8E83-135044A8B628@nic.cz> <20150729.175053.1703900717736836161.mbj@tail-f.com> Date: Wed, 29 Jul 2015 08:58:39 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0117690502d519051c05a954 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 16:00:54 -0000 --089e0117690502d519051c05a954 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 8:50 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > On 29 Jul 2015, at 17:09, Juergen Schoenwaelder > > > wrote: > > > > > > On Wed, Jul 29, 2015 at 08:00:20AM -0700, Andy Bierman wrote: > > >> Hi, > > >> > > >> So why don't we make all the new YANG 1.1 statements like "action" > > >> into extensions? This is just as good, right? It seems like real > > >> keywords > > >> are for feature you like, and extensions are for features you don't > > >> like. > > > > > > I guess we leave constructive communication here. > > > > Actually, Andy has a point. We could have saved a massive amount of > > time by leaving action as an extension. Balazs could have already > > written a draft about it, and it could be used with YANG 1.0, too. > > I am not sure how interesting this is, but yes, action could have > been done as an extension statement. In fact, that's what we (and > others) have been doing since 6020 was published. > > The difference here is that action has been around and used for > several years, whereas we don't even have agreement that "config > ephemeral" is the right solution to the problem. > > This is somewhat irrelevant since the I2RS work is still in progress, so the fact that there are still open issues is to be expected. There are brand new statements in YANG 1.1 (like complex if-feature logic) that have never been implemented or proven in deployment. The real difference is that extensions can be ignored by all YANG tools and real statements cannot be ignored. > > /martin > Andy --089e0117690502d519051c05a954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 29, 2015 at 8:50 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 29 Jul 2015, at 17:09, Juergen Schoenwaelder
> > <j.sch= oenwaelder@jacobs-university.de> wrote:
> >
> > On Wed, Jul 29, 2015 at 08:00:20AM -0700, Andy Bierman wrote:
> >> Hi,
> >>
> >> So why don't we make all the new YANG 1.1 statements like= "action"
> >> into extensions? This is just as good, right?=C2=A0 It seems = like real
> >> keywords
> >> are for feature you like, and extensions are for features you= don't
> >> like.
> >
> > I guess we leave constructive communication here.
>
> Actually, Andy has a point. We could have saved a massive amount of > time by leaving action as an extension. Balazs could have already
> written a draft about it, and it could be used with YANG 1.0, too.

I am not sure how interesting this is, but yes, action could have
been done as an extension statement.=C2=A0 In fact, that's what we (and=
others) have been doing since 6020 was published.

The difference here is that action has been around and used for
several years, whereas we don't even have agreement that "config ephemeral" is the right solution to the problem.


This is somewhat irrelevant since the I2RS work is s= till in progress,
so the fact that there are still open issues is= to be expected.
There are brand new statements in YANG 1.1 (like= complex if-feature logic)
that have never been implemented or pr= oven in deployment.

The real difference is that ex= tensions can be ignored by all
YANG tools and real statements can= not be ignored.

=C2=A0

/martin


An= dy
=C2=A0

--089e0117690502d519051c05a954-- From Ari.Sodhi@calix.com Wed Jul 29 09:43:48 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 9CF971ACD4D for ; Wed, 29 Jul 2015 09:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 m4x__ljGfPkA for ; Wed, 29 Jul 2015 09:43:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19581ACD4B for ; Wed, 29 Jul 2015 09:43:43 -0700 (PDT) Received: from SN2PR0501MB926.namprd05.prod.outlook.com (10.160.17.144) by SN2PR0501MB926.namprd05.prod.outlook.com (10.160.17.144) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 16:43:36 +0000 Received: from SN2PR0501MB926.namprd05.prod.outlook.com ([10.160.17.144]) by SN2PR0501MB926.namprd05.prod.outlook.com ([10.160.17.144]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 16:43:36 +0000 From: Ari Sodhi To: "netmod@ietf.org" Thread-Topic: Mail regarding draft-mansfield-netmod-uml-to-yang Thread-Index: AQHQyh22Uqyd0J/A30GczhkujIMBLg== Date: Wed, 29 Jul 2015 16:43:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [70.48.20.130] x-microsoft-exchange-diagnostics: 1; SN2PR0501MB926; 5:Trq432fqbxx0LuHrtTy2hgORtzlqVwhOLzE1xSmvtGiXvJmPuYEx65K1h4vx6hXaAPKzD36vPkdjxN1c6qHp/+iE6K322tbChmuRqKU84RsqmfEmWkBKPMwFxZpoXmxHD+3ctDfJpnfUPIws0XaY9Q==; 24:QntjoRisYrYLUxdqzWNG5LxckIzJZXOU5okjm4Uvs3rXpehinDjA4wgTEYqnF3mA/Dg/hnPymfnWVL/7UGaNves2e8dn6UWRcIXCTeETx3o=; 20:lvHelVUM9iE+3yUGOrNTAm8k7IqMVVOGVJ2lz4ClzaUGfjz/rLh9qI6BberdIFIqJoHfTGyKl9rsjQ6vS7tgTg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0501MB926; sn2pr0501mb926: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN2PR0501MB926; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB926; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(83506001)(46102003)(16236675004)(92566002)(122556002)(40100003)(5002640100001)(110136002)(229853001)(54356999)(77156002)(19580405001)(4001350100001)(77096005)(102836002)(189998001)(19580395003)(36756003)(86362001)(50986999)(2656002)(87936001)(107886002)(106116001)(450100001)(2351001)(62966003)(99286002)(2900100001)(2501003)(230783001)(5001960100002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0501MB926; H:SN2PR0501MB926.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1DE7AF7666F0arisodhicalixcom_" MIME-Version: 1.0 X-OriginatorOrg: calix.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 16:43:36.3371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0501MB926 Archived-At: Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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, 29 Jul 2015 16:54:08 -0000 --_000_D1DE7AF7666F0arisodhicalixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are some interesting ideas proposed. Here are some initial questions = and somewhat random comments based on a quick read of draft-mansfield-netmo= d-uml-to-yang-00. General questions on draft-mansfield-netmod-uml-to-yang: 1. Is the proposed mapping supposed to be bi-directional in nature? In o= ther words, is the intent to support a mapping between UML and YANG that en= ables IM UML -> DM YANG -> IM UML in a round trip manner. The text in this= section uses the term predictable. Should it not be deterministic? 2. Does there need to be a set of UML usages defined =96 similar to what= ONF did? Some of the UML concepts such as aggregation usually need definit= ion as even the OMG UML 2.5 spec says aggregation is open to some interpret= ation. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-y= ang but it seems ambiguous as both composition and aggregation map to conta= iner. The examples are not so clear =96 the first seems more like compositi= on to me as there is a lifecycle implication between instances of ClassA an= d ClassB. The second example =96 the list could also be a set of leafref to= the ClassD key. 3. Did the authors consider the use of UML stereotypes/annotations to he= lp support the mapping between UML and YANG? This may help remove potential= ambiguity in the mapping. comments on draft-mansfield-netmod-uml-to-yang: 1. Section 3 - What about UML packages and module/submodule relationship= . Modules can be a root package with submodules being sub-packages.Need to = enforce the semantics of include/import per RFC 6020. Any value in consider= ing relating YANG features to packages =96 ie. Represent yang Feature state= ments 2. Section 5.2 - UML abstract is stated to map to a container. Container= s either represent containment for organization reasons or with presence th= e container itself is configuration data. I do not get the mapping of abstr= act to this. Can you explain? 3. Section 5.2 =96 both support and condition map to =93if-feature=94 st= atement in yang. This seems ambiguous. How does one distinguish in YANG whi= ch is which? 4. Section 5.2 - =93must=94 statement =96 could this not map to OCL? 5. Section 5.2 =96 wrt objectCreationNotfication/objectDeletionNotificat= ion =96 in UML how are these represented -seems to rely on ONF OpenModelCas= s if I understand the source correctly? It seems like there are some assump= tions wrt to the Object Class. In YANG can these map to notification statem= ents. Is there some notification hierarchy in YANG/UML where these notifica= tions (objectCreationNotificaiton/objectDeletionNotification) exist? More c= urrent drafts of RFC 6020 (I.e. draft-ietf-netmod=96rfc6020bis=9606) propos= e notifications to be top level of a module or associated with data nodes (= container or list data nodes). This notion could be leveraged as the sour= ce of the notification in YANG =96 xpath to its source in containment model= . 6. Section 5.4.4 =96 a complex data type does not always map to grouping= IMO except if the grouping has a singular top level container. A grouping = is a reusable construct that gets "flattened out" in the context they are u= sed within. Groupings can also be refined/augmented to tailor their usage c= ontextually. 7. Section 5.5 =96The mapping is ambiguous as stated above. compositio= n is a stronger type of association then aggregation and infers ownership o= f lifecycle of the contained items. That is when the composing instance is = destroyed, the contained items are also destroyed. Its a is a part of relat= ionship. Aggregation can be used to mean a point of control for manipulatin= g the contained. It does not infer lifecycle control. 8. Section 5.5 - Its not clear how cleanly augment maps to inheritance. = Augment can apply to many things in YANG - container, list, leaf-list, uses= , choice =85. I can kind of see augment of a container mapping to inheritan= ce. Augments can also specify conditions as to when they apply - i.e. If if= type =3D=3D ethernetCsmacd 9. Section 5.6 =96 I don=92t see how UML interface maps to a container. = A UML interface represents a contract. A container either represents contai= nment for organization reasons or with presence the container itself is con= figuration data. This may need more discussion =96 or at least more explana= tion. 10. Section 5.11 =96 what does package map to? Is it module/submodule? Co= uld a conditional package not also map to module/submodule with if-feature = as a top-level entity? Ari Mark Sodhi System Engineer and Architect II T 707.766.3413 M 707.775.1379 E asodhi@calix.com Calix 1035 N. McDowell Boulevard Petaluma, CA 94954 T 707.766.3000 F 707.283.3100 --_000_D1DE7AF7666F0arisodhicalixcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

T= here are some interesting ideas proposed. Here are some initial questions a= nd somewhat random comments based on a quick read of draft-mansfield-netmod-uml-to-yang-00. 

 =

Genera= l questions on draft-mansfield-netmod-uml-to-yang:

  1. Is the= proposed mapping supposed to be bi-directional in nature? In other words, = is the intent to support a mapping between UML and YANG that enables IM UML= -> DM YANG -> IM UML in a round trip manner.  The text in this section uses the term predictable. Should i= t not be deterministic?
  2. Does t= here need to be a set of UML usages defined =96 similar to what ONF did? So= me of the UML concepts such as aggregation usually need definition as even = the OMG UML 2.5 spec says aggregation is open to some interpretation. This is touched on in section 5.5 of = draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both compositi= on and aggregation map to container. The examples are not so clear =96 the = first seems more like composition to me as there is a lifecycle implication between instances of ClassA and ClassB= . The second example =96 the list could also be a set of leafref to the Cla= ssD key. 
  3. Did the aut= hors consider the use of UML stereotypes/annotations to help support the ma= pping between UML and YANG? This may help remove potential ambigu= ity in the mapping. 

commen= ts on draft-mansfield-netmod-uml-to-yang:

  1. Section 3 - What about UML packages and modul= e/submodule relationship. Modules can be a root package with submodules bei= ng sub-packages.Need to enforce the semantics of include/import per RFC 6020. Any value in considering relating YANG fea= tures to packages =96 ie. Represent yang Feature statements<= /font>
  2. Sectio= n 5.2 - UML abstract is stated to map to a container. Containers either rep= resent containment for organization reasons or with presence the container = itself is configuration data. I do not get the mapping of abstract to this. Can you explain?
  3. Sectio= n 5.2 =96 both support and condition map to =93if-feature=94 statement in y= ang. This seems ambiguous. How does one distinguish in YANG which is which?=
  4. Sectio= n 5.2 - =93must=94 statement =96 could this not map to OCL?
  5. Section 5.2 =96 wrt objectCreationNotf= ication/objectDeletionNotification =96 in UML how are these represented -se= ems to rely on ONF OpenModelCass if I understand the source correctly? It seems like there are some assumptions wrt to the Obje= ct Class. In YANG can these map to notification statements. Is there some n= otification hierarchy in YANG/UML where these notifications (objectCreation= Notificaiton/objectDeletionNotification) exist? More current drafts of RFC 6020 (I.e. draft-ietf-netmod=96rfc6020bi= s=9606) propose notifications to be top level of a module= or associated with data nodes (container or list data nodes).   This notion could be leveraged as the source o= f the notification in YANG =96 xpath to its source in containment model.&nb= sp;
  6. Sectio= n 5.4.4 =96 a complex data type does not always map to grouping IMO except = if the grouping has a singular top level container. A grouping is a reusabl= e construct that gets "flattened out" in the context they are used within. Groupings can also be refined/augment= ed to tailor their usage contextually. 
  7. Sectio= n 5.5 - Its not clear how cleanly augment maps to inheritance. Augment can = apply to many things in YANG - container, list, leaf-list, uses, choice =85= . I can kind of see augment of a container mapping to inheritance. Augments can also specify conditions as to when th= ey apply - i.e. If if type =3D=3D ethernetCsmacd
  8. Sectio= n 5.6 =96 I don=92t see how UML interface maps to a container. A UML interf= ace represents a contract. A container either represents containment for or= ganization reasons or with presence the container itself is configuration data. This may need more discussion =96 = or at least more explanation. 
  9. Sectio= n 5.11 =96 what does package map to? Is it module/submodule? Could a condit= ional package not also map to module/submodule with if-feature as a top-lev= el entity?

 =

=

Ari Mark Sodhi

System E= ngineer and Architect II

T 707.766.3413

M 707.775.1379

E asodhi@calix.com

 

Calix

1035 N. = McDowell Boulevard

Petaluma= , CA 94954

T 707.766.3000

F 707.283.3100

 
--_000_D1DE7AF7666F0arisodhicalixcom_-- From nobody Wed Jul 29 10:44: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 A77E11B31FF for ; Wed, 29 Jul 2015 10:44:34 -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 Y8OlPL7fBAp6 for ; Wed, 29 Jul 2015 10:44:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5C1B31E8 for ; Wed, 29 Jul 2015 10:44:33 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 40C661AE0491; Wed, 29 Jul 2015 19:44:31 +0200 (CEST) Date: Wed, 29 Jul 2015 19:44:31 +0200 (CEST) Message-Id: <20150729.194431.2002520234234267282.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <82E94198-B7F5-4569-8E83-135044A8B628@nic.cz> <20150729.175053.1703900717736836161.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 17:44:34 -0000 Andy Bierman wrote: > The real difference is that extensions can be ignored by all > YANG tools and real statements cannot be ignored. Are you saying that a server that advertises both ietf-system and nacm is free to ignore the nacm statements in ietf-system, and for example by default provide read-access to /system/radius/server/udp/shared-secret? /martin From nobody Wed Jul 29 10:49:47 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 2BCA61B3213 for ; Wed, 29 Jul 2015 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 2vE2sh2Qq_Sf for ; Wed, 29 Jul 2015 10:49:44 -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 630AD1B3204 for ; Wed, 29 Jul 2015 10:49:32 -0700 (PDT) Received: by lbbst4 with SMTP id st4so11631068lbb.1 for ; Wed, 29 Jul 2015 10:49: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; bh=JX2gbxLQZ1k6aqNRFPlvvMu+pUkzdoh1HOePpad3GGA=; b=NRhkT64ArO6OuX5V8HgJb5VBK++hc6wBxYhbHFLjyl3rQgF6bPRDSBGoBnW8PpND/x Izw6w5F+N0thIz9gVqcv2ItTEWbmw399c0FYAHXlqU815NJr3Z/UPoFZMIJGoK5O+ixE TIPa4i6OMn2+2eTRkPwk9m2AlN9rYrUJNpSd/LYVTuByBP2y0XbIPd8LA6+yB1dy8FR3 66xH0rzfC7GFkeXgVR9DdtIcHRkUM9Tgd/61RtL7HdL26XkqvRWVL14/z3rK4GF558JS VmrPewpu4LeUchhkTSBWb8fJJL6STH1MjDfBnO6rroFMCbk54GQAZqXGdFOtV23b3+k1 6W9Q== X-Gm-Message-State: ALoCoQluvDEyNg77cPTA7x8xIJxw1BG+OyyE78H6p6edGhzc4l4JgFhIQN/CfKUT3AlZw6Dx8drB MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr40310038lbz.33.1438192170751; Wed, 29 Jul 2015 10:49:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Jul 2015 10:49:30 -0700 (PDT) In-Reply-To: <20150729.194431.2002520234234267282.mbj@tail-f.com> References: <82E94198-B7F5-4569-8E83-135044A8B628@nic.cz> <20150729.175053.1703900717736836161.mbj@tail-f.com> <20150729.194431.2002520234234267282.mbj@tail-f.com> Date: Wed, 29 Jul 2015 10:49:30 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1134946c74fcb1051c0735d0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 17:49:46 -0000 --001a1134946c74fcb1051c0735d0 Content-Type: text/plain; charset=UTF-8 Hi, I understand the intent is that an implementation of NACM has to understand these NACM extensions. I agree with Lada that the YANG text about MAY ignore extensions casts doubt whether this sort of NACM rule is enforceable or specified correctly. Andy On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > The real difference is that extensions can be ignored by all > > YANG tools and real statements cannot be ignored. > > Are you saying that a server that advertises both ietf-system and nacm > is free to ignore the nacm statements in ietf-system, and for example > by default provide read-access to > /system/radius/server/udp/shared-secret? > > > /martin > --001a1134946c74fcb1051c0735d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I understand the intent is that an = implementation of NACM
has to understand these NACM extensions.= =C2=A0 I agree with Lada
that the YANG text about MAY ignore exte= nsions casts doubt whether
this sort of NACM rule is enforceable = or specified correctly.


Andy
<= div>

On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> The real difference is that extensions can be ignored by all
> YANG tools and real statements cannot be ignored.

Are you saying that a server that advertises both ietf-system and nacm
is free to ignore the nacm statements in ietf-system, and for example
by default provide read-access to
/system/radius/server/udp/shared-secret?


/martin

--001a1134946c74fcb1051c0735d0-- From nobody Wed Jul 29 10:51:56 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 68C931B322D for ; Wed, 29 Jul 2015 10:51: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 wBjy3CyOJWm5 for ; Wed, 29 Jul 2015 10:51:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D133E1B3224 for ; Wed, 29 Jul 2015 10:51:52 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 190A91AE0491; Wed, 29 Jul 2015 19:51:52 +0200 (CEST) Date: Wed, 29 Jul 2015 19:51:51 +0200 (CEST) Message-Id: <20150729.195151.71742690632261308.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150729.194431.2002520234234267282.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 17:51:54 -0000 Andy Bierman wrote: > Hi, > > I understand the intent is that an implementation of NACM > has to understand these NACM extensions. I agree with Lada > that the YANG text about MAY ignore extensions casts doubt whether > this sort of NACM rule is enforceable or specified correctly. So do you agree that it would be a good idea to clarify this according to Juergen's suggestion? /martin > > > Andy > > > On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > The real difference is that extensions can be ignored by all > > > YANG tools and real statements cannot be ignored. > > > > Are you saying that a server that advertises both ietf-system and nacm > > is free to ignore the nacm statements in ietf-system, and for example > > by default provide read-access to > > /system/radius/server/udp/shared-secret? > > > > > > /martin > > From nobody Wed Jul 29 16:12:08 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 830671B2F93 for ; Wed, 29 Jul 2015 16:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Mu5QR5o5SIrC for ; Wed, 29 Jul 2015 16:12:06 -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 AD0AF1B2A57 for ; Wed, 29 Jul 2015 16:12:05 -0700 (PDT) Received: by lbbud7 with SMTP id ud7so12569064lbb.3 for ; Wed, 29 Jul 2015 16:12: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=nvlMeve/NQkp5l5x7glfTvHO6oUO2DSOedTS8+vkbo0=; b=dzI7vyodHH1f4gyPM/Ntt3/8E2pOPBku8UC/BgE38K9ofks3TNGWtyFP+vl3Z7qDjO gFf/8SDUAFA2jVeRq3VGIf5xOl/BYdPMTrxYUCyHwho6MzNGTbzl4Lglx6MEZR0nfzQB wmTK5mOIW3C3wr3rkbOa+lSF5VqRQdQ8hh+P7e3w4pNf37Ye7YtGPwjgjYMZ27YbR0KA 96tyht8cYu7focgOeJfu5d2mRg5wWFfQL+n9P4SZRGdTnC3m7FrfcxebHT9FwD06U7xN cLi4Np/cfZnetmG1gLzbQV+HSkuu92hpgChsT3m7OJh+hPCJhlEYTlsPh9F6eoDbmnkF WgPw== X-Gm-Message-State: ALoCoQmjrFTTZepABcYSZ0o6VTbXn1xN+N06a/cavcZlTdMZJxh5mh8yhv1cuaEBWYwf06firpTZ MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr41345084laj.123.1438211524031; Wed, 29 Jul 2015 16:12:04 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Jul 2015 16:12:03 -0700 (PDT) In-Reply-To: <20150729.195151.71742690632261308.mbj@tail-f.com> References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> Date: Wed, 29 Jul 2015 16:12:03 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158ba0a009a23051c0bb7aa Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 29 Jul 2015 23:12:07 -0000 --089e0158ba0a009a23051c0bb7aa Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I understand the intent is that an implementation of NACM > > has to understand these NACM extensions. I agree with Lada > > that the YANG text about MAY ignore extensions casts doubt whether > > this sort of NACM rule is enforceable or specified correctly. > > So do you agree that it would be a good idea to clarify this > according to Juergen's suggestion? > > > Not really. Pretending the extension is just another description-stmt does not really fix anything. A real YANG statement like config-stmt or a new statement called ephemeral-stmt can be modified with refine-stmt or deviate-stmt. This can never happen for an external statement. IMO ephemeral data support needs to be a real statement that can be used with refine-stmt and deviate-stmt. It is a real property of a data node. /martin > > > Andy > > > > > > Andy > > > > > > On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > The real difference is that extensions can be ignored by all > > > > YANG tools and real statements cannot be ignored. > > > > > > Are you saying that a server that advertises both ietf-system and nacm > > > is free to ignore the nacm statements in ietf-system, and for example > > > by default provide read-access to > > > /system/radius/server/udp/shared-secret? > > > > > > > > > /martin > > > > --089e0158ba0a009a23051c0bb7aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I understand the intent is that an implementation of NACM
> has to understand these NACM extensions.=C2=A0 I agree with Lada
> that the YANG text about MAY ignore extensions casts doubt whether
> this sort of NACM rule is enforceable or specified correctly.

So do you agree that it would be a good idea to clarify this
according to Juergen's suggestion?



Not really.
Pretending the e= xtension is just another description-stmt
does not really fix any= thing.

A real YANG statement like config-stmt or a= new statement
called ephemeral-stmt can be modified with refine-= stmt
or deviate-stmt. =C2=A0 This can never happen for
= an external statement.


IMO ephemera= l data support needs to be a real statement
that can be used with= refine-stmt and =C2=A0deviate-stmt.
It is a real property of a d= ata node.


/martin



=C2=A0Andy


>
>
> Andy
>
>
> On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > The real difference is that extensions can be ignored by all=
> > > YANG tools and real statements cannot be ignored.
> >
> > Are you saying that a server that advertises both ietf-system and= nacm
> > is free to ignore the nacm statements in ietf-system, and for exa= mple
> > by default provide read-access to
> > /system/radius/server/udp/shared-secret?
> >
> >
> > /martin
> >

--089e0158ba0a009a23051c0bb7aa-- From nobody Thu Jul 30 01:21: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 DA0DE1B2CD4 for ; Thu, 30 Jul 2015 01:21: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 bHNxmOtRo7AF for ; Thu, 30 Jul 2015 01:21: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 D9E3B1B2CC1 for ; Thu, 30 Jul 2015 01:21: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 EDB24180C for ; Thu, 30 Jul 2015 10:21: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 pjUwJK-FLjiA for ; Thu, 30 Jul 2015 10:21:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 30 Jul 2015 10:21:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F4F720046 for ; Thu, 30 Jul 2015 10:21:51 +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 cuym9LN_PDKY; Thu, 30 Jul 2015 10:22: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 3730620045; Thu, 30 Jul 2015 10:21:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F025735F59AB; Thu, 30 Jul 2015 10:21:46 +0200 (CEST) Date: Thu, 30 Jul 2015 10:21:46 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150730082144.GB16097@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] yang 1.1 virtual interim meetings 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: Thu, 30 Jul 2015 08:21:58 -0000 Hi, as discussed at the IEF 93 meeting, I plan to have weekly 1 hour YANG 1.1 editing meetings. The idea is to resolve any review comments in a timely fashion. The concrete proposal now is to hold these virtual interim meetings on Mondays at 17:00-18:00 CEST (that should be 08:00-09:00 California time). We would start on August 24th (due to vacation periods) and reserve all Mondays until the IETF 94 cutoff (2015-10-19), that is: 2015-08-24 2015-08-31 2015-09-07 2015-09-14 2015-09-21 2015-09-28 2015-10-05 2015-10-12 We will use the meeting slots as needed (i.e., we may skip slots if there is nothing to resolve anymore). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 30 02:30:03 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 B914C1B2DC1 for ; Thu, 30 Jul 2015 02:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 QIvcqlakGoPq for ; Thu, 30 Jul 2015 02:30:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1E11B2DBF for ; Thu, 30 Jul 2015 02:30:00 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 5C3BF18182E; Thu, 30 Jul 2015 11:29:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438248599; bh=3yJea5ztJ847m9UrdbLj/kNn0IPhCMk83v5SrbfHVws=; h=From:Date:To; b=jaYfrcxVVK/JW+UCwexA4bSRJ3y/5q4sp720VZtg9sbqutLpW9kdd8Fb7iPkdXK53 1m8iFg/ZhPZlYfPlWnc0VesjsSkh5IPDFOfA8z2ihOsN2X4dpjHqwCYSlXExp+/6vS 6iDVUcvuUW4BtEzEoUMNBttr0FOpHBXmK6uE8o4I= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 30 Jul 2015 11:30:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 09:30:02 -0000 > On 30 Jul 2015, at 01:12, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = wrote: > Andy Bierman wrote: > > Hi, > > > > I understand the intent is that an implementation of NACM > > has to understand these NACM extensions. I agree with Lada > > that the YANG text about MAY ignore extensions casts doubt whether > > this sort of NACM rule is enforceable or specified correctly. >=20 > So do you agree that it would be a good idea to clarify this > according to Juergen's suggestion? >=20 >=20 >=20 > Not really. > Pretending the extension is just another description-stmt > does not really fix anything. In fact, generic tools like pyang ignore what=E2=80=99s written in = descriptions. Lada >=20 > A real YANG statement like config-stmt or a new statement > called ephemeral-stmt can be modified with refine-stmt > or deviate-stmt. This can never happen for > an external statement. >=20 >=20 > IMO ephemeral data support needs to be a real statement > that can be used with refine-stmt and deviate-stmt. > It is a real property of a data node. >=20 >=20 > /martin >=20 >=20 >=20 > Andy >=20 >=20 >=20 > > > > > > Andy > > > > > > On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund = wrote: > > > > > Andy Bierman wrote: > > > > The real difference is that extensions can be ignored by all > > > > YANG tools and real statements cannot be ignored. > > > > > > Are you saying that a server that advertises both ietf-system and = nacm > > > is free to ignore the nacm statements in ietf-system, and for = example > > > by default provide read-access to > > > /system/radius/server/udp/shared-secret? > > > > > > > > > /martin > > > >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 30 03:42:14 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 7710B1A005B for ; Thu, 30 Jul 2015 03:42: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] 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 hiVETbFcIB5E for ; Thu, 30 Jul 2015 03:42:11 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7AD1A004D for ; Thu, 30 Jul 2015 03:42:11 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E06BD1CC0474 for ; Thu, 30 Jul 2015 12:42:11 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 30 Jul 2015 12:42:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] data tree 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, 30 Jul 2015 10:42:13 -0000 Hi, if we want to make YANG less NETCONF- and XML-centric, it is necessary to have a sound definition of the data tree, which we IMO currently don't have. Two issues to start with: 1. Consider container top { leaf-list a { type uint8; } leaf b { type uint8; } } Is a data tree corresponding to this fragment more alike to the XML/XPath model, i.e. top a: 1 a: 2 b: 3 or rather JSON-like? top a: [1,2] b: 3 The definition of leaf-list seems to indicate it is the latter ("array"). 2. Ordering of container's children - it is defined only in sec. 7.5.7 (XML Mapping Rules): "If the container defines RPC input or output parameters, these subelements are encoded in the same order as they are defined within the "container" statement. Otherwise, the subelements are encoded in any order." I assume this is true for the data tree as well. But in the first variant above we could have (if "top" is a non-RPC container) top a: 1 b: 3 a: 2 while this interleaving isn't possible with the second variant. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 30 04:31:09 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 85CE71A8822 for ; Thu, 30 Jul 2015 04:31: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 V3k8KzF1O0tJ for ; Thu, 30 Jul 2015 04:31: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 064691A879C for ; Thu, 30 Jul 2015 04:31:05 -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 397F9C4175C5; Thu, 30 Jul 2015 13:31:02 +0200 (CEST) To: Ladislav Lhotka , Andy Bierman References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> From: Jernej Tuljak Message-ID: <55BA0AF5.3040505@mg-soft.si> Date: Thu, 30 Jul 2015 13:31:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 11:31:08 -0000 Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >> On 30 Jul 2015, at 01:12, Andy Bierman wrote: >> >> >> >> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> I understand the intent is that an implementation of NACM >>> has to understand these NACM extensions. I agree with Lada >>> that the YANG text about MAY ignore extensions casts doubt whether >>> this sort of NACM rule is enforceable or specified correctly. >> So do you agree that it would be a good idea to clarify this >> according to Juergen's suggestion? >> >> >> >> Not really. >> Pretending the extension is just another description-stmt >> does not really fix anything. > In fact, generic tools like pyang ignore what’s written in descriptions. Where does RFC6020 say that description-stmt may be used for defining additional semantics? The only instance where I can find "description" and "semantics" or "meaning" in the same sentence, is in the section that describes module updates. This is what a YANG description is: The "description" statement takes as an argument a string that contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer; for the sake of interoperability, it is RECOMMENDED to choose a language that is widely understood among the community of network administrators who will use the module. A textual description for humans. A docstring. I don't see semantics being mentioned anywhere, so where is all this coming from? Jernej > > Lada > >> A real YANG statement like config-stmt or a new statement >> called ephemeral-stmt can be modified with refine-stmt >> or deviate-stmt. This can never happen for >> an external statement. >> >> >> IMO ephemeral data support needs to be a real statement >> that can be used with refine-stmt and deviate-stmt. >> It is a real property of a data node. >> >> >> /martin >> >> >> >> Andy >> >> >> >>> >>> Andy >>> >>> >>> On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund wrote: >>> >>>> Andy Bierman wrote: >>>>> The real difference is that extensions can be ignored by all >>>>> YANG tools and real statements cannot be ignored. >>>> Are you saying that a server that advertises both ietf-system and nacm >>>> is free to ignore the nacm statements in ietf-system, and for example >>>> by default provide read-access to >>>> /system/radius/server/udp/shared-secret? >>>> >>>> >>>> /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 Thu Jul 30 04:35: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 36E3A1A1AD9 for ; Thu, 30 Jul 2015 04:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 xfwAxU-3dOcz for ; Thu, 30 Jul 2015 04:35:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995001A0110 for ; Thu, 30 Jul 2015 04:35:41 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 30E86181810; Thu, 30 Jul 2015 13:35:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438256140; bh=qkToZuXxyl1uj1mPnNJj7mVGsgUmqI2hMEkq3m+wYzE=; h=From:Date:To; b=YQf3GpP4t2FTlA0kG10fIm6zoJOfXl4hWEVWXTLaZ4PQZIrwzb88Sc3w0x930t5IQ FnsbpNtJ+azF5+B7XP0IrMmQdkF/16uGz8uxq9+icu43XB/9ePGiBN8nsdItQ8Th2w HWwppfu4HGWoKjmMB9Wd1/e7E+x6V/XCzd2bbSTc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <55BA0AF5.3040505@mg-soft.si> Date: Thu, 30 Jul 2015 13:35:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> To: Jernej Tuljak X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 11:35:44 -0000 > On 30 Jul 2015, at 13:31, Jernej Tuljak wrote: >=20 > Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >>> On 30 Jul 2015, at 01:12, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = wrote: >>> Andy Bierman wrote: >>>> Hi, >>>>=20 >>>> I understand the intent is that an implementation of NACM >>>> has to understand these NACM extensions. I agree with Lada >>>> that the YANG text about MAY ignore extensions casts doubt whether >>>> this sort of NACM rule is enforceable or specified correctly. >>> So do you agree that it would be a good idea to clarify this >>> according to Juergen's suggestion? >>>=20 >>>=20 >>>=20 >>> Not really. >>> Pretending the extension is just another description-stmt >>> does not really fix anything. >> In fact, generic tools like pyang ignore what=E2=80=99s written in = descriptions. >=20 > Where does RFC6020 say that description-stmt may be used for defining = additional semantics? The only instance where I can find Nowhere. That=E2=80=99s why I also proposed to add the following = sentence to the section about =E2=80=9Cdescription=E2=80=9D statement: Constraints and rules stated in the text of a =E2=80=9Cdescription=E2=80=9D= statement are an integral and binding part of the data model. Lada > "description" and "semantics" or "meaning" in the same sentence, is = in the section that describes module updates. This is what a YANG = description is: >=20 > The "description" statement takes as an argument a string that > contains a human-readable textual description of this definition. > The text is provided in a language (or languages) chosen by the > module developer; for the sake of interoperability, it is = RECOMMENDED > to choose a language that is widely understood among the community = of > network administrators who will use the module. >=20 > A textual description for humans. A docstring. I don't see semantics = being mentioned anywhere, so where is all this coming from? >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> A real YANG statement like config-stmt or a new statement >>> called ephemeral-stmt can be modified with refine-stmt >>> or deviate-stmt. This can never happen for >>> an external statement. >>>=20 >>>=20 >>> IMO ephemeral data support needs to be a real statement >>> that can be used with refine-stmt and deviate-stmt. >>> It is a real property of a data node. >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>> On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund = wrote: >>>>=20 >>>>> Andy Bierman wrote: >>>>>> The real difference is that extensions can be ignored by all >>>>>> YANG tools and real statements cannot be ignored. >>>>> Are you saying that a server that advertises both ietf-system and = nacm >>>>> is free to ignore the nacm statements in ietf-system, and for = example >>>>> by default provide read-access to >>>>> /system/radius/server/udp/shared-secret? >>>>>=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 Thu Jul 30 04:38:34 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 57DDE1A1AFB for ; Thu, 30 Jul 2015 04:38:33 -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 LRs21YF6iZhp for ; Thu, 30 Jul 2015 04:38:31 -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 BA6571A1AE8 for ; Thu, 30 Jul 2015 04:38: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 092471845; Thu, 30 Jul 2015 13:38: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 3KeMIdh0F-zw; Thu, 30 Jul 2015 13:38:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 30 Jul 2015 13:38:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53A8420047; Thu, 30 Jul 2015 13:38:28 +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 yxk-17cyNrdJ; Thu, 30 Jul 2015 13: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 D260620046; Thu, 30 Jul 2015 13:38:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D7F635F5DDE; Thu, 30 Jul 2015 13:38:22 +0200 (CEST) Date: Thu, 30 Jul 2015 13:38:22 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20150730113821.GA16711@elstar.local> Mail-Followup-To: Jernej Tuljak , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> 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: <55BA0AF5.3040505@mg-soft.si> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Thu, 30 Jul 2015 11:38:33 -0000 On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tuljak wrote: > Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: > >>On 30 Jul 2015, at 01:12, Andy Bierman wrote: > >> > >> > >> > >>On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: > >>Andy Bierman wrote: > >>>Hi, > >>> > >>>I understand the intent is that an implementation of NACM > >>>has to understand these NACM extensions. I agree with Lada > >>>that the YANG text about MAY ignore extensions casts doubt whether > >>>this sort of NACM rule is enforceable or specified correctly. > >>So do you agree that it would be a good idea to clarify this > >>according to Juergen's suggestion? > >> > >> > >> > >>Not really. > >>Pretending the extension is just another description-stmt > >>does not really fix anything. > >In fact, generic tools like pyang ignore what’s written in descriptions. > > Where does RFC6020 say that description-stmt may be used for defining > additional semantics? The only instance where I can find "description" > and "semantics" or "meaning" in the same sentence, is in the section > that describes module updates. This is what a YANG description is: > > The "description" statement takes as an argument a string that > contains a human-readable textual description of this definition. > The text is provided in a language (or languages) chosen by the > module developer; for the sake of interoperability, it is RECOMMENDED > to choose a language that is widely understood among the community of > network administrators who will use the module. > > A textual description for humans. A docstring. I don't see semantics > being mentioned anywhere, so where is all this coming from? Seriously? Perhaps we have a different understanding of the word 'semantics'. Anyway, description statements (or DESCRIPTION clauses back in SMIv2) have always been used to provide semantics that are not expressable in machine readable form. Example: The ietf-yang-types:counter32 definition defines a counter type because of the text in the description statement. I would say there is lots of semantics in the description statement. Without the description statement, the ietf-yang-types:counter32 would not at all be a counter. I am absolutely surprised lately how little we seem to have a common understanding about basic YANG concepts. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 30 04:41:57 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 F39041A6F2A for ; Thu, 30 Jul 2015 04:41:55 -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 6RgF68Bw7Hw3 for ; Thu, 30 Jul 2015 04:41:54 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFA41A0110 for ; Thu, 30 Jul 2015 04:41:54 -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 6ADC1C4175C5; Thu, 30 Jul 2015 13:41:53 +0200 (CEST) To: Ladislav Lhotka References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> From: Jernej Tuljak Message-ID: <55BA0D80.5020302@mg-soft.si> Date: Thu, 30 Jul 2015 13:41:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 11:41:56 -0000 Ladislav Lhotka je 30.7.2015 ob 13:35 napisal: >> On 30 Jul 2015, at 13:31, Jernej Tuljak wrote: >> >> Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >>>> On 30 Jul 2015, at 01:12, Andy Bierman wrote: >>>> >>>> >>>> >>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: >>>> Andy Bierman wrote: >>>>> Hi, >>>>> >>>>> I understand the intent is that an implementation of NACM >>>>> has to understand these NACM extensions. I agree with Lada >>>>> that the YANG text about MAY ignore extensions casts doubt whether >>>>> this sort of NACM rule is enforceable or specified correctly. >>>> So do you agree that it would be a good idea to clarify this >>>> according to Juergen's suggestion? >>>> >>>> >>>> >>>> Not really. >>>> Pretending the extension is just another description-stmt >>>> does not really fix anything. >>> In fact, generic tools like pyang ignore what’s written in descriptions. >> Where does RFC6020 say that description-stmt may be used for defining additional semantics? The only instance where I can find > Nowhere. That’s why I also proposed to add the following sentence to the section about “description” statement: > > Constraints and rules stated in the text of a “description” statement are an integral and binding part of the data model. Wait, what? This would make a client broken if it chokes after receiving a message, where a container data node instance has a text value set and the container's description in the module claims: "This container MUST be treated as a leaf under X Y conditions". It is in this WG interest for YANG modules to be interpreted without human presence, right? Automation? If it isn't, it would be best to drop YANG and write human readable specifications instead. Models that cannot be consumed by machines are pointless, IMHO. Jernej > > Lada > >> "description" and "semantics" or "meaning" in the same sentence, is in the section that describes module updates. This is what a YANG description is: >> >> The "description" statement takes as an argument a string that >> contains a human-readable textual description of this definition. >> The text is provided in a language (or languages) chosen by the >> module developer; for the sake of interoperability, it is RECOMMENDED >> to choose a language that is widely understood among the community of >> network administrators who will use the module. >> >> A textual description for humans. A docstring. I don't see semantics being mentioned anywhere, so where is all this coming from? >> >> Jernej >> >>> Lada >>> >>>> A real YANG statement like config-stmt or a new statement >>>> called ephemeral-stmt can be modified with refine-stmt >>>> or deviate-stmt. This can never happen for >>>> an external statement. >>>> >>>> >>>> IMO ephemeral data support needs to be a real statement >>>> that can be used with refine-stmt and deviate-stmt. >>>> It is a real property of a data node. >>>> >>>> >>>> /martin >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>>> Andy >>>>> >>>>> >>>>> On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund wrote: >>>>> >>>>>> Andy Bierman wrote: >>>>>>> The real difference is that extensions can be ignored by all >>>>>>> YANG tools and real statements cannot be ignored. >>>>>> Are you saying that a server that advertises both ietf-system and nacm >>>>>> is free to ignore the nacm statements in ietf-system, and for example >>>>>> by default provide read-access to >>>>>> /system/radius/server/udp/shared-secret? >>>>>> >>>>>> >>>>>> /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 Thu Jul 30 04:50:40 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 879411A8764 for ; Thu, 30 Jul 2015 04:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 Wojn59b5VIU9 for ; Thu, 30 Jul 2015 04:50:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961811A8753 for ; Thu, 30 Jul 2015 04:50:36 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 485DC181846; Thu, 30 Jul 2015 13:50:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438257035; bh=IzCrR4WKxzr0UpPid/uLM241M4dePw30OMACIGMfcrs=; h=From:Date:To; b=bI4ihUZhBaY5MV/A26E/E9m3JNzxTf0tcNXsfcvC0jiENkKppRsksEi0542hyVali N6qh/idGZw1C9CgqZj/U00vjCzX/C5VhyjdApZup7ARoYvKSZWAZusscNkNVo0zAl9 cDJNlSTtDNNT7mTSmNfmrjW1pdDWpHJEdCRN0aso= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150730113821.GA16711@elstar.local> Date: Thu, 30 Jul 2015 13:50:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> <20150730113821.GA16711@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 11:50:38 -0000 > On 30 Jul 2015, at 13:38, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tuljak wrote: >> Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >>>> On 30 Jul 2015, at 01:12, Andy Bierman wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = wrote: >>>> Andy Bierman wrote: >>>>> Hi, >>>>>=20 >>>>> I understand the intent is that an implementation of NACM >>>>> has to understand these NACM extensions. I agree with Lada >>>>> that the YANG text about MAY ignore extensions casts doubt whether >>>>> this sort of NACM rule is enforceable or specified correctly. >>>> So do you agree that it would be a good idea to clarify this >>>> according to Juergen's suggestion? >>>>=20 >>>>=20 >>>>=20 >>>> Not really. >>>> Pretending the extension is just another description-stmt >>>> does not really fix anything. >>> In fact, generic tools like pyang ignore what=E2=80=99s written in = descriptions. >>=20 >> Where does RFC6020 say that description-stmt may be used for defining=20= >> additional semantics? The only instance where I can find = "description"=20 >> and "semantics" or "meaning" in the same sentence, is in the section=20= >> that describes module updates. This is what a YANG description is: >>=20 >> The "description" statement takes as an argument a string that >> contains a human-readable textual description of this definition. >> The text is provided in a language (or languages) chosen by the >> module developer; for the sake of interoperability, it is = RECOMMENDED >> to choose a language that is widely understood among the community = of >> network administrators who will use the module. >>=20 >> A textual description for humans. A docstring. I don't see semantics=20= >> being mentioned anywhere, so where is all this coming from? >=20 > Seriously? Perhaps we have a different understanding of the word > 'semantics'. Anyway, description statements (or DESCRIPTION clauses > back in SMIv2) have always been used to provide semantics that are not > expressable in machine readable form. Then it has to be mentioned in 6020bis, or perhaps added as an erratum = to 6020, too. And it also goes without saying that generic tools aren=E2=80=99t able = to figure out the semantics contained in descriptions. >=20 > Example: The ietf-yang-types:counter32 definition defines a counter > type because of the text in the description statement. I would say > there is lots of semantics in the description statement. Without > the description statement, the ietf-yang-types:counter32 would not > at all be a counter. >=20 > I am absolutely surprised lately how little we seem to have a common > understanding about basic YANG concepts. >=20 This is hardly surprising. Those with extensive experience in SNMP and = SMI have a different background than those who came to NETCONF and YANG = from the XML camp (like me). Lada > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 30 04:56:53 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 2F98C1A8F50 for ; Thu, 30 Jul 2015 04:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 QDvuhyq2ntr8 for ; Thu, 30 Jul 2015 04:56:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7865B1A8905 for ; Thu, 30 Jul 2015 04:56:48 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 2E19F181719; Thu, 30 Jul 2015 13:56:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438257407; bh=wvj8B5MZCG3cebxrTr7A2aZzz2T1H19Q8BNGvMIQwLw=; h=From:Date:To; b=edYQU89XpOR7KoySPkI211+l87JFiOVSRPxV0gyuajWkVtezcsoE9N/Hgh/OFLkPx V2lSMroMCTvokgm83l0segNyiIsVqNTOK7YtNkGCw5WdBFYqCaZ9i54BrSZYOcX1u7 tAhDlAXKpkpeSCXTeC22pe4fOmocNyEhQLSwoo84= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <55BA0D80.5020302@mg-soft.si> Date: Thu, 30 Jul 2015 13:56:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <268F61FC-F485-4F55-8A1C-1EECAA093C54@nic.cz> References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> <55BA0D80.5020302@mg-soft.si> To: Jernej Tuljak X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 11:56:51 -0000 > On 30 Jul 2015, at 13:41, Jernej Tuljak wrote: >=20 > Ladislav Lhotka je 30.7.2015 ob 13:35 napisal: >>> On 30 Jul 2015, at 13:31, Jernej Tuljak wrote: >>>=20 >>> Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >>>>> On 30 Jul 2015, at 01:12, Andy Bierman wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = wrote: >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I understand the intent is that an implementation of NACM >>>>>> has to understand these NACM extensions. I agree with Lada >>>>>> that the YANG text about MAY ignore extensions casts doubt = whether >>>>>> this sort of NACM rule is enforceable or specified correctly. >>>>> So do you agree that it would be a good idea to clarify this >>>>> according to Juergen's suggestion? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Not really. >>>>> Pretending the extension is just another description-stmt >>>>> does not really fix anything. >>>> In fact, generic tools like pyang ignore what=E2=80=99s written in = descriptions. >>> Where does RFC6020 say that description-stmt may be used for = defining additional semantics? The only instance where I can find >> Nowhere. That=E2=80=99s why I also proposed to add the following = sentence to the section about =E2=80=9Cdescription=E2=80=9D statement: >>=20 >> Constraints and rules stated in the text of a =E2=80=9Cdescription=E2=80= =9D statement are an integral and binding part of the data model. >=20 > Wait, what? This would make a client broken if it chokes after = receiving a message, where a container data node instance has a text = value set and the container's description in the module claims: "This = container MUST be treated as a leaf under X Y conditions=E2=80=9D. Or this: description =E2=80=9CThis leaf is only valid on Friday=E2=80=9D; My understanding is that it is only the server that=E2=80=99s supposed = to validate data (BTW, I don=E2=80=99t like this assumption), and the = server software has to be coded so that constraints expressed in = descriptions are checked, too. Lada >=20 > It is in this WG interest for YANG modules to be interpreted without = human presence, right? Automation? If it isn't, it would be best to drop = YANG and write human readable specifications instead. Models that cannot = be consumed by machines are pointless, IMHO. >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> "description" and "semantics" or "meaning" in the same sentence, is = in the section that describes module updates. This is what a YANG = description is: >>>=20 >>> The "description" statement takes as an argument a string that >>> contains a human-readable textual description of this definition. >>> The text is provided in a language (or languages) chosen by the >>> module developer; for the sake of interoperability, it is = RECOMMENDED >>> to choose a language that is widely understood among the community = of >>> network administrators who will use the module. >>>=20 >>> A textual description for humans. A docstring. I don't see semantics = being mentioned anywhere, so where is all this coming from? >>>=20 >>> Jernej >>>=20 >>>> Lada >>>>=20 >>>>> A real YANG statement like config-stmt or a new statement >>>>> called ephemeral-stmt can be modified with refine-stmt >>>>> or deviate-stmt. This can never happen for >>>>> an external statement. >>>>>=20 >>>>>=20 >>>>> IMO ephemeral data support needs to be a real statement >>>>> that can be used with refine-stmt and deviate-stmt. >>>>> It is a real property of a data node. >>>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Andy >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Jul 29, 2015 at 10:44 AM, Martin Bjorklund = wrote: >>>>>>=20 >>>>>>> Andy Bierman wrote: >>>>>>>> The real difference is that extensions can be ignored by all >>>>>>>> YANG tools and real statements cannot be ignored. >>>>>>> Are you saying that a server that advertises both ietf-system = and nacm >>>>>>> is free to ignore the nacm statements in ietf-system, and for = example >>>>>>> by default provide read-access to >>>>>>> /system/radius/server/udp/shared-secret? >>>>>>>=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 30 07:21: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 926F91A8A66 for ; Thu, 30 Jul 2015 07:21:11 -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 Wq09wLhqylwv for ; Thu, 30 Jul 2015 07:21:10 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCFA1A8A77 for ; Thu, 30 Jul 2015 07:20:58 -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 80648C4175C5; Thu, 30 Jul 2015 16:20:57 +0200 (CEST) To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> <20150730113821.GA16711@elstar.local> From: Jernej Tuljak Message-ID: <55BA32C8.9030108@mg-soft.si> Date: Thu, 30 Jul 2015 16:20:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150730113821.GA16711@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 14:21:11 -0000 Juergen Schoenwaelder je 30.7.2015 ob 13:38 napisal: > On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tuljak wrote: >> Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: >>>> On 30 Jul 2015, at 01:12, Andy Bierman wrote: >>>> >>>> >>>> >>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: >>>> Andy Bierman wrote: >>>>> Hi, >>>>> >>>>> I understand the intent is that an implementation of NACM >>>>> has to understand these NACM extensions. I agree with Lada >>>>> that the YANG text about MAY ignore extensions casts doubt whether >>>>> this sort of NACM rule is enforceable or specified correctly. >>>> So do you agree that it would be a good idea to clarify this >>>> according to Juergen's suggestion? >>>> >>>> >>>> >>>> Not really. >>>> Pretending the extension is just another description-stmt >>>> does not really fix anything. >>> In fact, generic tools like pyang ignore what’s written in descriptions. >> Where does RFC6020 say that description-stmt may be used for defining >> additional semantics? The only instance where I can find "description" >> and "semantics" or "meaning" in the same sentence, is in the section >> that describes module updates. This is what a YANG description is: >> >> The "description" statement takes as an argument a string that >> contains a human-readable textual description of this definition. >> The text is provided in a language (or languages) chosen by the >> module developer; for the sake of interoperability, it is RECOMMENDED >> to choose a language that is widely understood among the community of >> network administrators who will use the module. >> >> A textual description for humans. A docstring. I don't see semantics >> being mentioned anywhere, so where is all this coming from? > Seriously? Perhaps we have a different understanding of the word > 'semantics'. Anyway, description statements (or DESCRIPTION clauses > back in SMIv2) have always been used to provide semantics that are not > expressable in machine readable form. > > Example: The ietf-yang-types:counter32 definition defines a counter > type because of the text in the description statement. I would say > there is lots of semantics in the description statement. Without > the description statement, the ietf-yang-types:counter32 would not > at all be a counter. This does not change "semantics" as I understand them or as Ladislav implied them. I was thinking "YANG language semantics", which is what extensions are used for - extending YANG language with new keywords that hold special meaning for a YANG processor (humans included). In a NETCONF message, ietf-yang-types:counter32 value will always be an integer on the wire, regardless of what the description text says, right? I also cannot magically turn all containers into leaves using text in a module description, saying "All container definitions in this module are actually leaf definitions", right? An extension could, however, be used for such a thing - a sort of YANG pre-processor directive (which any sensible YANG tool would ignore). I disagree with the interpretation that an extension is just a formalized description statement. I also disagree with the notion that a description text may alter, augment or define YANG language semantics, unless it describes an extension keyword. This is of key importance for generic tools, so that at the very least they can support standard extensions, such as "annotation". Having to parse human text would render such tools completely useless. Jernej > > I am absolutely surprised lately how little we seem to have a common > understanding about basic YANG concepts. > > /js > From nobody Thu Jul 30 07:44:48 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 4E33F1A1A6A for ; Thu, 30 Jul 2015 07:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 fblslzWc7TrV for ; Thu, 30 Jul 2015 07:44:39 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A69E1A1A39 for ; Thu, 30 Jul 2015 07:44:38 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail31.telekom.de with ESMTP; 30 Jul 2015 16:44:36 +0200 X-IronPort-AV: E=Sophos;i="5.15,577,1432591200"; d="png'150?scan'150,208,217,150";a="303253074" Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 30 Jul 2015 16:44:28 +0200 Received: from HE111649.emea1.cds.t-internal.com ([169.254.3.40]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 30 Jul 2015 16:44:27 +0200 From: To: Date: Thu, 30 Jul 2015 16:44:26 +0200 Thread-Topic: Mail regarding draft-mansfield-netmod-uml-to-yang Thread-Index: AQHQyh22Uqyd0J/A30GczhkujIMBLp3ytUsA Message-ID: References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/related; boundary="_004_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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, 30 Jul 2015 14:44:46 -0000 --_004_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_ Content-Type: multipart/alternative; boundary="_000_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_" --_000_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hallo, Thanks for sharing your questions and comments; some initial responses are = provided below in line. Note that we have made some further progress that we plan to reflect in an = update of this draft which of course will take into account the netmod disc= ussions and input including this e-mail thread. Regards Bernd Deutsche Telekom AG Europe & Technology Standardization Services Bernd Zeuner Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Germany +49 6151 58-12086 (phone) E-Mail: b.zeuner@telekom.de www.telekom.com Life is for sharing. Deutsche Telekom AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: Timotheus H=F6ttges (Chairman), Reinhard Clemens, Niek Jan van Damme, Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn, Germany VAT identification no. DE 123475223 Big changes start small - conserve resources by not printing every e-mail. From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ari Sodhi Sent: Wednesday, July 29, 2015 6:44 PM To: netmod@ietf.org Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang There are some interesting ideas proposed. Here are some initial questions = and somewhat random comments based on a quick read of draft-mansfield-netmo= d-uml-to-yang-00. General questions on draft-mansfield-netmod-uml-to-yang: 1. Is the proposed mapping supposed to be bi-directional in nature? In ot= her words, is the intent to support a mapping between UML and YANG that ena= bles IM UML -> DM YANG -> IM UML in a round trip manner. [Bernd] The inten= t was UML -> YANG; but YANG -> UML is also possible. The text in this secti= on uses the term predictable. Should it not be deterministic?[Bernd] Yes, a= greed. 2. Does there need to be a set of UML usages defined - similar to what ON= F did? Some of the UML concepts such as aggregation usually need definition= as even the OMG UML 2.5 spec says aggregation is open to some interpretati= on. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang= but it seems ambiguous as both composition and aggregation map to containe= r. The examples are not so clear - the first seems more like composition to= me as there is a lifecycle implication between instances of ClassA and Cla= ssB. The second example - the list could also be a set of leafref to the Cl= assD key. [Bernd] You are right. Some statements (to be verified): =B7 UML composition association is mapped to container/list within = a container/list; the reference is "passed by value" =B7 UML aggregation association is mapped to a leafref within a con= tainer/list; the reference is "passed by reference". 1. Did the authors consider the use of UML stereotypes/annotations to hel= p support the mapping between UML and YANG? This may help remove potential = ambiguity in the mapping. [Bernd] We did not add YANG specific UML stereoty= pes because the intent was that the UML be agnostic to any data schema (DM)= . comments on draft-mansfield-netmod-uml-to-yang: 1. Section 3 - What about UML packages and module/submodule relationship.= Modules can be a root package with submodules being sub-packages.Need to e= nforce the semantics of include/import per RFC 6020. Any value in consideri= ng relating YANG features to packages - ie. Represent yang Feature statemen= ts [Bernd] The mapping of UML packages to YANG modules/submodules is an identi= fied open issue which is under discussion. You raise some good points to co= nsider. 1. Section 5.2 - UML abstract is stated to map to a container. Containers= either represent containment for organization reasons or with presence the= container itself is configuration data. I do not get the mapping of abstra= ct to this. Can you explain? [Bernd] The current thinking is to map abstract superclasses to "grouping" = statements. This allows also to map multiple inheritance. Note: This is als= o the mapping that we have used for the Link object class in draft-lam-teas= -usage-info-model-net-topology-01. 1. Section 5.2 - both support and condition map to "if-feature" statement= in yang. This seems ambiguous. How does one distinguish in YANG which is w= hich? [Bernd] Support and condition belong together. If the "support" is conditio= nal, then the "condition" explains the conditions under which the class has= to be supported. 1. Section 5.2 - "must" statement - could this not map to OCL? [Bernd] Good idea; we are still discussing this point as a general place fo= r mapping UML constraints. YANG seems to have here constraints between attr= ibute values in mind. 1. Section 5.2 - wrt objectCreationNotfication/objectDeletionNotification= - in UML how are these represented -seems to rely on ONF OpenModelCass if = I understand the source correctly? [Bernd] Yes, you are right. This is an a= dditional class property defined in the OpenModel profile. It defines that = a notification has to be sent when an instance of this class is instantiate= d or deleted. It seems like there are some assumptions wrt to the Object Cl= ass. In YANG can these map to notification statements. [Bernd] Meanwhile we= have mapped this to the "notification" statement which goes beyond the sim= ple "a notification has to be sent". Is there some notification hierarchy i= n YANG/UML where these notifications (objectCreationNotificaiton/objectDele= tionNotification) exist? [Bernd] Not now; but will be in the future. More c= urrent drafts of RFC 6020 (I.e. draft-ietf-netmod-rfc6020bis-06) propose no= tifications to be top level of a module or associated with data nodes (cont= ainer or list data nodes). This notion could be leveraged as the source o= f the notification in YANG - xpath to its source in containment model. 2. Section 5.4.4 - a complex data type does not always map to grouping IM= O except if the grouping has a singular top level container. A grouping is = a reusable construct that gets "flattened out" in the context they are used= within. Groupings can also be refined/augmented to tailor their usage cont= extually. [Bernd] We define complex data types in a separate UML package (TypeDefinit= ions). They can always be reused as the type of class attributes or operati= on parameters. 1. Section 5.5 -The mapping is ambiguous as stated above. composition i= s a stronger type of association then aggregation and infers ownership of l= ifecycle of the contained items. That is when the composing instance is des= troyed, the contained items are also destroyed. Its a is a part of relation= ship. Aggregation can be used to mean a point of control for manipulating t= he contained. It does not infer lifecycle control. [Bernd] That's completely true. See our answer to General::2. 1. Section 5.5 - Its not clear how cleanly augment maps to inheritance. A= ugment can apply to many things in YANG - container, list, leaf-list, uses,= choice .... I can kind of see augment of a container mapping to inheritanc= e. Augments can also specify conditions as to when they apply - i.e. If if = type =3D=3D ethernetCsmacd [Bernd] True. In recent discussions we concluded that augment is more appro= priate for mapping to conditional composition then inheritance. We see the = "grouping" statement as the main mapping for inheritance. The "extension" s= tatement is no longer used here. 1. Section 5.6 - I don't see how UML interface maps to a container. A UML= interface represents a contract. A container either represents containment= for organization reasons or with presence the container itself is configur= ation data. This may need more discussion - or at least more explanation. [Bernd] We use the UML Interface artifact as a grouping of operations. A co= ntainer can be used to group actions. [cid:image001.png@01D0CA3E.1F2ED390] 1. Section 5.11 - what does package map to? Is it module/submodule? [Bern= d] Regarding the mapping of packages see our answer to Comments::1 above. C= ould a conditional package not also map to module/submodule with if-feature= as a top-level entity?[Bernd] That's possible but we see the conditional P= acs closer to the object class. They provide the attributes for an object c= lass on a conditional basis. This pattern is used e.g., to enhance a techno= logy agnostic object class with technology specific attributes. Ari Mark Sodhi System Engineer and Architect II T 707.766.3413 M 707.775.1379 E asodhi@calix.com Calix 1035 N. McDowell Boulevard Petaluma, CA 94954 T 707.766.3000 F 707.283.3100 --_000_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hallo,

 

Thanks for= sharing your questions and comments; some initial responses are provided b= elow in line.

Note that we have ma= de some further progress that we plan to reflect in an update of this draft= which of course will take into account the netmod discussions and input in= cluding =A0this e-mail thread.

 

Regards

Bernd

Deutsche Telekom AG
Europ= e & Technology
Standardization Services
Bernd Zeuner
He= inrich-Hertz-Str. 3-7, 64295 Darmstadt, Germany
+49= 6151 58-12086 (phone)
E-Mail: b.zeuner@tele= kom.de
www.= telekom.com

Life is for sharing.

Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Ch= airman)
Board of Management: Timotheus H=F6ttges (Chairman),
Reinhar= d Clemens, Niek Jan van Damme,
Thomas Dannenfeldt, Dr. Thomas Kremer, Cl= audia Nemat
Commercial register: Amtsgericht Bonn HRB 6794
Registered= office: Bonn, Germany
VAT identification no. DE 12= 3475223

Big changes start small – conserve resources by not printin= g every e-mail.

From: netmod [mailto:ne= tmod-bounces@ietf.org] On Behalf Of Ari Sodhi
Sent: Wednes= day, July 29, 2015 6:44 PM
To: netmod@ietf.org
Subject:= [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang

 =

There are some = interesting ideas proposed. Here are some initial questions and somewhat ra= ndom comments based on a quick read of draft-mansfield-netmod-uml-to-y= ang-00. 

 

General questions on draft-mansfield-netmod-uml-to-yang:=

  1. Is the proposed mapping sup= posed to be bi-directional in nature? In other words, is the intent to supp= ort a mapping between UML and YANG that enables IM UML -> DM YANG -> = IM UML in a round trip manner.  [Ber= nd] The intent was UML -> YANG; but Y= ANG -> UML is also possible. The= text in this section uses the term predictable. Should it not be determini= stic?[Bernd]= Yes, agreed.<= o:p>
  2. Does there need to be a set of UML usage= s defined – similar to what ONF did? Some of the UML concepts such as= aggregation usually need definition as even the OMG UML 2.5 spec says aggr= egation is open to some interpretation. This is touched on in section 5.5 o= f draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both co= mposition and aggregation map to container. The examples are not so clear &= #8211; the first seems more like composition to me as there is a lifecycle = implication between instances of ClassA and ClassB. The second example R= 11; the list could also be a set of leafref to the ClassD key.

[Bernd] You are right. Some statements (to be verified):

=B7  &n= bsp;      UML composition association is mapped to container/list within a= container/list; the reference is “passed by value”<= /span>

=B7 &nb= sp;       UML aggregation association is mapped to a leafref within a= container/list; the reference is “passed by reference”.

  1. Did the authors consider the use of UML stereotypes/annotati= ons to help support the mapping between UML and YANG? This may help remove&= nbsp;potential ambiguity in the mapping. [Bernd] We did no= t add YANG specific UML stereotypes because the intent was that the UML be = agnostic to any data schema (DM).

 <= /span>

comments on dra= ft-mansfield-netmod-uml-to-yang:

  1. Section 3 - What about U= ML packages and module/submodule relationship. Modules can be a root packag= e with submodules being sub-packages.Need to enforce the semantics of inclu= de/import per RFC 6020. Any value in considering relating YANG features to = packages – ie. Represent yang Feature statements

= [Bernd] The mapping of UML packages t= o YANG modules/submodules is an identified open issue which is under discus= sion. You raise some good points to consider.

  1. Section 5.2 - UML abstract is stated to map to a container. C= ontainers either represent containment for organization reasons or with pre= sence the container itself is configuration data. I do not get the mapping = of abstract to this. Can you explain?

[Bernd] The current thinking is to map abstract superclasses to “group= ing” statements. This allows also to map multiple inheritance. Note: = This is also the mapping that we have used for the Link object class in dra= ft-lam-teas-usage-info-model-net-topology-01.

  1. Section 5= .2 – both support and condition map to “if-feature” state= ment in yang. This seems ambiguous. How does one distinguish in YANG which = is which?

[Bernd] Support and condition belong together. If the “support” is c= onditional, then the “condition” explains the conditions under = which the class has to be supported.

  1. Section 5.2 - “must” statement &= #8211; could this not map to OCL?

[Bernd] <= /i>Good idea; we are still discussing this point as= a general place for mapping UML constraints. YANG seems to have here const= raints between attribute values in mind.

  1. Section 5.2 – wrt objectCreationNotfication/objectDeletionNotifi= cation – in UML how are these represented -seems to rely on ONF OpenM= odelCass if I understand the source correctly? [Bernd] Yes, you = are right. This is an additional class property defined in the OpenModel pr= ofile. It defines that a notification has to be sent when an instance of th= is class is instantiated or deleted. <= /span>It seems like there are some assumptions wrt to the Object Class. In = YANG can these map to notification statements. [Bernd] Meanwhile we h= ave mapped this to the “notification” statement which goes beyo= nd the simple “a notification has to be sent”. Is there some notification hierarchy in YANG/UM= L where these notifications (objectCreationNotificaiton/objectDeletionNotif= ication) exist? [Bernd] = Not now; but will be in the future. More current drafts of RFC 6020 (I.e. dr= aft-ietf-netmod–rfc6020bis–06) propose notifications to be top = level of a module or associated with data nodes (container or list data nod= es).   This notion could be leveraged as the source of the notificatio= n in YANG – xpath to its source in containment model. 
  2. Section 5.4.4 – a complex data = type does not always map to grouping IMO except if the grouping has a singu= lar top level container. A grouping is a reusable construct that gets "= ;flattened out" in the context they are used within. Groupings can als= o be refined/augmented to tailor their usage contextually. 

[Bernd] We define complex= data types in a separate UML package (TypeDefinitions). They can always be= reused as the type of class attributes or operation parameters.=

  1.  Section 5.5= –The mapping is ambiguous as stated above.  composition is a st= ronger type of association then aggregation and infers ownership of lifecyc= le of the contained items. That is when the composing instance is destroyed= , the contained items are also destroyed. Its a is a part of relationship. = Aggregation can be used to mean a point of control for manipulating the con= tained.  It does not infer lifecycle control. <= /li>

[Bernd] = That’s completely true. See our answer to Gen= eral::2.

  1. Section 5.5 - Its not clear how cleanly augment maps to inheritance. Au= gment can apply to many things in YANG - container, list, leaf-list, uses, = choice …. I can kind of see augment of a container mapping to inherit= ance. Augments can also specify conditions as to when they apply - i.e. If = if type =3D=3D ethernetCsmacd

[Bernd] <= /b>True. In recent discussions we concluded that augmen= t is more appropriate for mapping to conditional composition then inheritan= ce. We see the „grouping” statement as the main mapping for inh= eritance. The “extension” statement is no longer used here.

  1. Section 5.= 6 – I don’t see how UML interface maps to a container. A UML in= terface represents a contract. A container either represents containment fo= r organization reasons or with presence the container itself is configurati= on data. This may need more discussion – or at least more explanation= .

[Bernd] We u= se the UML Interface artifact as a grouping of operations. A container can = be used to group actions.
=3D"cid:image001.png@01D0CA3E.1F2ED390"

 

  1. Section 5.11 ̵= 1; what does package map to? Is it module/submodule? [Bernd] Regarding the mapping= of packages see our answer to Comments::1 above. Could a cond= itional package not also map to module/submodule with if-feature as a top-l= evel entity?= [Bernd] That’s possible but we see= the conditional Pacs closer to the object class. They provide the attribut= es for an object class on a conditional basis. This pattern is used e.g., t= o enhance a technology agnostic object class with technology specific attri= butes.

 

 

 

Ari Mark Sodhi=

System Engineer and Architect= II

T 707.766.3413

M 707.775.1379

E<= /span> asodhi@calix.com=

 =

C= alix

1035 N.= McDowell Boulevard

= Petaluma, CA 94954

T 707.766.3000=

F 707.283.3= 100

 =

 

= --_000_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_-- --_004_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=7816; creation-date="Thu, 30 Jul 2015 14:44:27 GMT"; modification-date="Thu, 30 Jul 2015 14:44:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAQMAAABzCAIAAAAT5vDpAAAAAXNSR0IArs4c6QAAHkJJREFUeF7t XQdcVMfWH2xJ1CTPlBelqUgJaBLfUxGlSQAjGDC2l8SCCqJIKIJ+goAIRlSMikKCWJBiiT7RQPSJ Cqg0KTE9qFRpi74Uk5fEXvY7M/fu7r3b2F3WKLtzf/OD2XPPnDnnP+WcuTuz10AoFCJ6UQT0HoEe eo8ABYAigBGgI4H2A4oAQQCiI+YaOXIkhYQioD8IQIcXd37IGIjXCQYGBg8fPtQfIKileo5Ajx49 uItkGh3peX+g5rMI8HzCgwcPKDAUAT1BoGfPnlyfwBsJ9+lI0JNeQM1EqBd/JNDoiHYKioDMU1Tu UprmVUOgOd2jJ8wuvTzSm1UroIzr7Aqtieq6MrouQWoC4EVH9+7fp/OD+gici+i10arxhO9guUWV 3+UWAU43VHg/cYL6KtAS6iPQu1cvhc+OYOMFTRogQL6WUZiU3+UWRGii5RDaBH8RAlJjR2qdAHuQ aFIXAQZSKHUusrfnnj0r+vTuBWnynmZCcduCTgeY9+oTcQ7ztKRPJnf79F5RLCoSGeFJKCwnKSgs jmDYRAUxc/OeySwxspgoKS1NXc31nJ83FngjQYPpUB+LtOyZ3HvynpaWPZ69oXtjBJihgDOnA2o9 79y9d6cgvGBxarHQef3dwjA0Ma3h3p0NzkLo3uZHpkMeM6CN6S1Mke8tUzFFxHl8wWCgO20gbEDc snFPCwiH6syPTGsgxHvrnYAiI+1cRJ/eEcVAx+r9RTNr9+0Ayn2C+tGW3pUojjSvXXE3FS0JRNvv bXCWsn9iWiAhOXuGoR8aW/l3Wxt/wP6h91N9ej/lvqWgDuZ+uCZOd5O3wiiOwGx93JIYGa1FRwrC V3DXIrLSnBPvNFhtnNwYiNWbnCFVu961lHoG0+hIzQih+ESSOwTzV2oL1CzIhp3hBXfv3mHSBieF sWhr+tvuiHA2pLmLK2JiMG6SJ60gpwiPgdO1VzTTUH9K0eioKw8GnDbcTkWBfTZa1q+oNe8TCcE+ iY2YIEGckU80GTYCQazTyl8lS8IYSfErdQXulqYgs6XwSAFhMHGb5s4vKyutOPIp87rld0CxJcLU uySCoknZkwzuUKDfrKnnQzG3qe+xO/9ZYOq8/g70ttaMt92TUMGSQIjM5V7Ok8IKllj0eRoGDXJe X5+GAsyffqoPTpii4HIK3I4CrIAnsG6EO8NjuuB4wQhR2ZUlQJGRBqMUliNAx+qpb5d+l+B9n3Dr 9h39RoNar0cIPPP0Uwr3Hd2kI0GPeoK+m9pX2Ui4dVvf4aH26w0CfZ95WqFPuEFHgt70A2poP2Uj 4eYtChBFQE8Q6Nf3GYU+4U86EvSkF1AzEerPHwn0KSrtFBQBjIDUviNd35OuNfuKo/o+039lsZS8 lkyv/n29MmE/UecXSFDEydxqyfR+Buat/t4ZKslTXmPJSq2J6ty07sEhNQHwRwLdiaoyAgi5udVs ymrlbn4o2RFYyOCryo4FJZzMV2k+eSdDkNvHKfNN5Assie7nzVdAUb0l0ZO2hpy8+XueIlEqKayK Ud2IR9lIoG5SLQRshqPcs5xtbqUnk0OXhqgl4q9jdrOUf5Dor9PgCa9Jb3xCa+bUfn2fIymmlJkC S2JgTi1l6VOzWtn5TMIZBXsaWLasKKasmA3a1SJguU1gGuGB1Jq16YeUgEkShyCnRiQUEadmNcnj ZGqUeBURD1GVpwNQJiWjwiDrvs9FlWAF5KkdE+VN1GY5GeVLolgc2IKM8lP44EhL00GnodQn6MyO rZbMaf28s1tasqf0XQX9RFiyyjpweP6N//15438XU2smwS3mVEFh8Ca0jRBRYBAhAufRdy4Sznxh UiZs8ydstZMIJbQocHup5ESC48TQraexfDg0cyYXTXOBOAZ3XkU1StTYJjyaLOGUrZE97iCSJquD 44d/4tgpBVRNcFSkdo1lClZbxHnUxwR0c0wg1gFx2yZiMqD0au7US4R440MHeSCUrHy+38pSAAej qivb+vhDQSd9QmmMTW3YnynCkGBh8o010E9am2pQ6ETIQAcznRcWWlhHergQuSUnzzPmEjFnYbBN v+f793veY1tRHTQ7YVvsiDOOHsGopomzNnBYnFqzGWJ1VLoj0GYZEcUkuTUC0S3Vn6hhPG95sIRT tkbZOVihDqLq5Kg9xQX2s8qIKo3C1vUHR8Goeja3MDRsHodTFgTHdb9dtEp6p8kfozpFtcXJk+5G 9GDFXJqf4mZlilrqyfKV6QqSUITzkcGCiW1gBDB5hEKP/XnjVyYl4AHAYZPkWaKpyxR09GxpVlIN 28XFzIpqFHdNDqfCGrnSuLaIVOUaqJLawtas6R6IGHgp2U1ssnSvlQWBuMajZFlUWM/OI096X1e+ fFc2EnRkM7tDwq/bhGH9N1nULKu36RcL0YvJUBu0TRTGZG7dFjoRxwAAVGHeGXLMseVMXiEhEs6t OCjixAC434k+ivNsxmRu+PAQj0D0zgQT7hkFuTUCsTBwF4mm2jI3pTASlNcoXR3/GIT4rupqN9cW weKZNZlRYMIUN77JstJKogbY1C79A/AMhmhyDYNed0/8oaCT0REOgQ7/kTvH1DH+jz/jcTTiGF/z yUXP/gOe7T9g+GfeNQn2rCtws64LIcQPrE8wRMyJgmwwEVJ0aeePBR0Xb3MLXcqNLkRyZGp0jD8R mkLUCENTg1gdFNXYmj3VIwUVhoTi6EueGo4TQwpDhjNKqqw2aIs+eB1MC62zdmPEms75LN9aZPIq /DhBRppjwvU/AB/AE1Dt3q5AyieLhwPvfML13/+Qchk6/bE09rktFjWfzWWWufTSMwReeO5Zxb93 JH/u0ZE5QHZalQrlO5/+9Qwf3QZED9YJqsev3AWA6qUop24gwB8KvOjo5//9rmcekpqrvwi89Pxz Cndl69hIWPvZd83tMLYNyCMSA/zPAH9gPAFzDTV+Nmbq6/rbHfTYcmUj4aff/qdLyCxMKU9eBL8p pOwK3lmcHuygS1ZTW1RE4OW/Pa8vb5d6+ODhU316Qvq6SQB/nVfnMElMgQx6KP7qTEUAKZtuIqDL 5xOgxXr17FF5uXVpVgVkLmx8HyjwF/JAATpkSKTU6dW6b/rzMIW8PB22sHX5Ko3RkqjS1aDSKtgG Jb6AMm2fFlTsso3dQYDSZ0c6N9p79TSATv/N5lmQgUTGBs4AhQwPZtXQ6WUyO+d4IHJNSoItbHKv srgB0/e3dSoHGMrivFICj/32Y44iUaoIEfO4ulx8O65MrSKUWT4COu4TevfssXXeuJHLDkAGEmDA ZIACdIaiZP4qXzV9v2iKxfgpZlV+l1sOIVcLU+3MmVCp99LkS1uz20TyVFdDBQ1a989YVa4CXzdl 0SefIBT27mngOdqcdHqD4Uv3gfHwF/JAATpkHipaJ5THvvLCgIK3cmZJe4Gy+BdmHNiL70J6by84 AqB4paKisDcGvBJL5ue2ve+Ru6+8EHsef8ZF4mNnEArLSQqi87EMm6ggKXxgJkuMLyeNJS2N34Km c0OsQ5YTadxLRjJRu5xVDCS372X0YUyQW5HJrMMTC3i66bI/0e33Jzzs2cMAkpetBfxt/MSHSWIK ZMh8xt9L1rr3XWj+UxOv/fJr7HjOLfE2POj09fjutbzgs6G7yoUOsb8cW4Jct3zz67V4B6GwLO6N PC/IYwa0Dc/X8CV90UXzJEwRcX46B2/YGxdP2ID48db9sNlb2LZ/+ut5Xt8RIlO7PGlihYlK4+KP vRoaRoqT3QDkroxkrEPYFvQRUTvVa8AyIdGHNUFRRWDar9fcT8OAiYP9SN1/053UvkruyNbtX41H 3nGfe8cd84o7Js5AnnyEv3DrcwOZrSTnd4ecg269ULRJT7KtG4dHBDvRXYeJS9DF5jb+xu22pkuo KHzkgIEvDhg4JeVcA/PDwa7eE5jDC8wl2sdQtgqzvei1nSG2nf38bFDIXMkxByRHmuy2bvvVedbh u8XLBcIgJZlRO2mOMdzCaov0EZugpCKHhVtc0PYpq87r2rYbnovT0b2ook63P9Jzf6THgUgPcQby 5CP8hVuenF7JtvO4+OtXf9kiDHth4IuxEJ5w+53sUQdxca4chIKO/AJCSIq3lzodIeGEsGcKIpzf bnaRf46ClJWWJquS0MF/c41XPBkL+G5nkvnaiquWraht/wzAIVyYBEquGadb266kQj2+T9CxLVcq hrVyrIYQ+frVn98qfHHmAfGWaAW9XroLG5tZo49TIPjmipXb9Vrqz7nA4hnel3Pu2FnSy4wneLnw y8qVJmcomMzasu3SFOJb4K6sZIXDUeSi5FTUdmBGONoCOByexfFSuuMY+N1DyifoVCgIls5JzFee SM9RZPX4VT//+30cz7cemAmdrGhZeHYbeohwYoqI8+NdPyha9o8XBq2GowLjV329FS19Y9BLL+CE KXKLCIX2Czej0DHAE15v7cLINH7/cJ61qOwaeHAjR5pYW65YodBkzsatLqxuciQr0IFjgozaoAxj vm4mqXmStwNP8NMvKk6j3YJtcUrZvggP5arCONlBd1t0i+bUtpJGL7+oL7sttA0dlafLCPB8QvuP P+uSrZtOXG5o6sTLmZu9uNzzVV2ymtqiIgLGf39J4a5sHRsJKiJC2fQTAWUjoU23fIJ+NjC1WkUE TPg+QbKVBsqPGw9fJ9GLIqAvCHB3TPHWCa3//UlfMKB26j0Cpq+8rHCd0HLtR73HhwKgLwgMHvh3 +hRVXxqb2qk6ArzoqPnqf1UvSTkpAt0agSGDXqE+oVu3IFX+kSDA8wlXOq49kkqoUIrAk4fAUMOB ClfMTXQkPHkNRjV6RAiY8UcCfQvtI8KZiu1mCPCio0bB1W6mPlWXIqApAsOMBtEVs6bg0XK6iwDP JzS0U5+gu01NLeMjYG7M8wlSI6GDwkUR0BMEzI0NFT47qm+jI0FPugE1E1mY8EYCfXZE+wRFACPA i47q2wQUFYqAniBgYWKkMDqqa6UjQU+6ATUTWZryRgKNjmifoAjIREe1Le0UFYqAniBgNdhYYXR0 mY4EPekF1EyEXuWPBN45Zls7+OlLelEE9AUBheeYLzWr9FoYfcGJ2qnTCFgPgV+6lLxlj/cU9dIV +DlcelEE9AIB66H41UZiU3kj4SIdCXrRB6iRGAEb/khQ7ylqaNZlm7mbwjPqKJYUAR1DQKU3DoZk X7Tx2QaupKDoeGlK2MmiHMjbzNkcnlX/+N42V/HRUFObdRVSCggOzrUZOjenXRW9QIIiTv6tirUw fzDJ/6D47X6qVKEOT/un/qpqro7YJ4RXM+sw8tJthJt4XUXVuq62hdRI7vydOuFZtYWFx89sChg+ d0tm9MLb91DG6uDhPklntoScLMhdmtX4uF4/gpCzfW3qEQH31RaVB1YWMxaqopUSTsmtyoThs2rX lLb80ASp/K18+0WH2lURrhpP5SYzH9YEo/d2NGVPM1JJc9WEP3ZRXbGu/cj8wcPPogVSrSk4GJfv eXql3ZiV0BZR/NZXz15lI0GuvwM/cHx96M27wv8kBrzYr+/tW/cHPtMrf33wjbsPjiV+UFCU+xi9 pKUVOlXG+TawsijDfxGDnZau9qNpOxccwB2UXMbTEhLRyqxqLUmnYhQjYDwts+WHla5SDB1lJ5CH gyHTFgFWsdmV2sKwc5/wbfYy78iUW7d73LzZI6/0y8/Lq3OKL/xx+/6N28IpkanfZy9TdX4SHFxs NngESZsqmeFL5oxKlr5YPNdKOBOgz7FshxKYshI2hIb4BFqQfkmktR9Jq433cZXoI6dGJBQRFx9q lsfJ1ChKgrJTJYsc7TgUI4eJTrWwU1Et5Tet9xlhhiVXr2cRGLG+kkh4NwMVxzoOFn0U+QdFWMkD QTX8YYrlm8Yzs0tN8xda116RjyY6GLMmmwyzr22GrXKqISDNptQnyLxGaHlW/Ws+m9cGLvj99v1T X36FhPd2/edCT2Rw+sKFu7cerA/we21e0rK9DXLeP9R+MMDM52h7+9H5gzdXwAuKKjY7Rljsb/6+ sfn7ksT6WXCLvLUIFa9OQ7GEiFZGESJwnphYQjj3o/RD7Sxb05uEsqh8ZdYXjJ44Bhrr5L+zBMuH gVB2GnnaGTJ0RTVK1IhFJzIlnLI1MkIQchoGG7V4L6NFxVda1VO+3mzd941RY4TCMZHErsaD83el Hm0fuwwyyDkejI0cK7JIKVZSIFQkvGaW8AUghqFW/hYoJsiQy9PVpnlU1klaWax225USKzhWwBpi ONiipFGg8buv+EOhE59wquj4Ov/56AH6+fqdhw/vZ+R/Xbxu2s5TlT0eGAh+u3P/gXCd34LTp3Nl BmXlZqdG38Z1wpgo4drmcJhTBS11SDS5Gr3r6198hbySD2L9uLXvDoI2EhMxZ/FqpyGvDRvy2uyd 5U3MS16d4+ba4Vrs3pyPamHLrPgNeqPnJtbtOAQTQ/XeCIvFWBRucUhyawSiU+J7ZI4f9K8l8yWc sjWKppCSRgi/+AY6DzFRT3l3eyNWQuU6bNew92AQMhRWW25eCVZSINhFfVcybPeClvcw1PPkB82C Q4txjfarS3b64syQzaxDFvu9rjbNo7JOBh8puITIZIgT2xk0cAvKfIKsOA/3t6N2Zzf/fPP6zVsG QrRg8j9doo74edg+7NHz9xt3m3+9EbU7w/0tb+mClWcyYSpFMIIlLc1UrLD5kaCtVnx3UXpj87dM iiQDQG6PYYgQrqATlZWH0mvZLi5mllsjl8jhVFAjjoV2lnC7jqDsNExLonWtyCLVlBccCpiNiGnl cU7K0OgMKx4gqOREJd5Nz04u0m1h9O52tkbWxjBusCfCVgtN82isk+n93LmDuAhNnzEoGwmy3nPD 7GHfZoTuPHLoxzs30dPw7bSB3+QxCPVAfV66dvtu+uHD32aGbpplLl1w7MpvPxSuGZY6tDjgitOQ LRC9GJpaIHEYczB9l7/TWDbAOA1LXhzblJ4uIUTCyQZFYscHTS+bZ4mGUxdZxs2OQJPs4YQ2iTHI X7k1ArEk4lMSTV09lJrF4VRQIwj3z5qdcIGtvWKLUwRa5zOarahYPeVbG847meFYCxsrskjWNIVY yYBQkfCGU4NfA4C8En14JZyBVFHiVsTl0VbTaN06bmuyChsPdbrcJo4D25vrGTw1S2pFR9Ct3liw zdtz8m9/Prh+59ZvD//+E/rbr8KXrt+9d/3GrXc8PUcuSJbvmIzeTW3IesfILqzhCpmE7MKKN9TP GfqG+dA3nE+4F0eNYmcjJ4umKEKMtNjHEDEninLAREgbYGUpL4TgEu3mrXby9/0XG4GIpje5NdqF 7fPPImqsQZ7zWB+ltEa7qG/2IT9GGfP30b4rqZKK1FQe9ESRk0DOqkYLJ8YB2jkuLIlzljJTEVaS II21EXRrANAAZIBa+cLR6J09LOYy7aWlptGydYKjvhjwLETw8T0ER+yFyGjsJHS6XMCa0NZ43nLw QC2tmHm7Lb6pb5JyGfAxOOuH0nOFLi7uxWdP2Tu59e7Z+57wQem5c64TnIuKz7q5eWKfoOFVmWSR NuRc5lT2GaWGUh5TsW6tfKeYPanWCQ4FxqBVGbAgFHy2IBqt1bzzjLQwU/jLX3Jn9+R5I2ztnM+e LfoyI7y05Mzvd2+VFxV9nRFUdPaMu5vXR7PMNVis0CIUAQ0RMHo32iPfI7Hyi0TH+FcDOvOEyvyk eusEJgLbsWjk13uCITPJdeqF8vNuk7wh/3VGyMb3h2gYokmCfuLnNYvzHnspJmp77Go8IgWeVOsM Z2Z8vWLs6BWN8LdL4POHAi86+qqusVOvSRkoArqBwD8th9HfRdWNpqRWaBMBnk/4srZBm7KpLIrA E4zAKCtzzX1C5KdNo/ySo/c3P8EGUtUoApogoNL5hIiDDaMWbpc6nzDKNyX605bHt/u9cquV+ajE SikFrh6eP8pqfq5K5xNAgiJO/q2qDTB/MCnosEqiNYGl/VCQqpprIv4xl9HEuvZcPxb2rVUS9XET J1ZeSOxqWyh9diRvLEV/eoU5nzDa72Px+YTRCz9hzies/PQx/giAw7i6tDzez/ZVHYop02RCUFKm OnG0z+VVRfUXLkM653ZyQnCOFn8psGrbqwtYE4z+lXI5Y0q3/GpFEXxds666HMUT2LMX7vVJ/JKp RPDvhJMex1eMHbUC2iKG3/pdavnOfUKn5xMe02SDzTa3RIUVsBlRdFWd3evrN5d5tNn5JXpMKIdT fEuQu3P33Kw93vhnleEy9I5PQDF7YTOsli4lOmiphscppmvWjZnJwj5mwlx0uY20cwdsy55kj18f C23hb/Xhfo6zUNNStX1C1a4gJecTvtgVpOpI7DgcYm05hqRk9qhLdbK1b141Sw85IvrNegln4gUs nbAdSWTKStgQGjw7wDxmL+GBqyNvV23MbBeJPnJqBC5xdS3yOJkaRVdHeVGZ33hbDsXQ3tWhVoA1 VUP55I98x1hjyRc+YhEY8xE+rZBsPWcvKlvrain66JvHYKAIK3kgqIZ/R54/3zSemV1qmkduXUdL g4OHLT6e01F9ErmOIwd14DI2G1fXoq2X30j5BOlvKmIOto7x/1jJ+YQxi1Kj/w1He2W+4hAAuL65 go7chZbbquBu9TbX6GGZddUX66oLExrmwS1m/3/Z2p0okhBRTAwhAmf+m4WEMxNl53SwbE0uhOJX AV2fqQ7vt7cd75tejuXDNuzyIqHHmEEMXVGNEjUihfl7JZyyNbIWIXsz8X54kZll8LtQainfMHRt 9cWIUUI0ajmx6+K+OXvScgW2wZBBDtFg7HJbkUVKsZICoQpmh8QLgBiGuvNvmRR8DdjVpnlU1rGd qiM3NnrYwpkD8cf25jIrI2hi5tagwcPKmmATkmZfLSr3CdJfgat4PkFmE1RlsluTz8U1aHUMiq8N sRWijpZG5GcPGWgNwxk+vmUt+DDwQwT9IH4G7r1iIuYsS3CztLWxtJ2fXoF/eIawzYI9sEJk6zwH 1bZ3MGXhEo6aldC46/BVJPzyQPQwfxDF0uXXCMLtE2YSNQZNXzSHSCCcsjWSW3CVN3XwvrPHysDv CKql/Jvj8BEMnKoTsV02c/YxVYu15eaVYCUFgu2K6kKzbP+WmRhq8CfydjB0HA7FNU5IKE9fgjPg kPlsXW6aR2UdQezLTRMSrLJxF5KGCyiGg+2ZzqBZ4o2FTk7qaHg+obp4H0ylqL2lnG1wZj8p0/jc PIcoaK9lGRDy236xtopJy2GrsdKyhuPeRPnV1TnZtdDFFQmXSFCghoIaQbh9enk1B+mOijPlVsaG vIqESDXlO3JC5yNi2ploe7GxymHpRHMMTnl+NY6pYHKR1yMMZ2xla2RtDCYocZN2muYRWHf1iN8S lM30AameQz5CB2PbQoOhoNQnyMiLm2FSlbZEyfmEqh1L1k43lYZ2zIqqOLTBZufggkUtblYpVXBC zGQYwmEM5hTkZO/xsydTPLTfmfPkBJoAehghEs5seD4j1VZcMMSo4IyR90KrhPnR6K1x4EDZHgoZ uTUCsTz6MFHjWs5OPDGLOBXUCML99s3f+BVbe1WKWzRaM/ufbEVqKt/WVEFiLWIsp22lTFOIFaf/ MppXbRwLvrcGQI5FcbXBDKSKkngekmLQVtM8AuumnPTIWwabi8RGGWMnID65LGhrZPDULPGHgpRP kBNxjQ3YruR8gl1Amvw4zXB6Us1uL0PboJrLQTgGtg0qWFu/wGrscKux7vkuBf/3DxzdgQkOZldi CTHaLIMhYs6HsW9iIqRNVSIzxQc3oBRTlsnAYmFWlL3v3OlMPC+my63RNijDdx9RYx2aNJuVoLRG 2/+rzBAuYZQZ7iPMuJwkqUhN5UFPFD0F5MQ1mtkzytuOX1CW4C5lpiKsRPaKbQTdagA0ABmgVh4t G3rtZOCVTVpqGi1b1563Ox2VE7hIgqAOYujRb8HTQtFRnfbGCkuTVzRcJuBpmHvxdltU/HBZ6jZ8 XHGwTvn5hA/BJ2h4VX88Yqfp6d3eoocBGop5PMW6tfKdQvakWteRszQeRe6YMRAJPl+8Gq3WvPOM G/GqerstNr5nyZxPKE8LEp9PqEhbxJxP6MIw6LQxKANFQAYBwxmRb52curn6q82u6y0XaXEO5fmE 899fUo79mpxrJ4uOTXSfHDdNK9N49Sev7TI9tctLK8L+6m7TrZXvFCzdtg6bP/41a65PUG8kdIof ZaAIdBcEpEZC57+Bp9m6nJaiCDzhCChbMZd9d7G7DGiqJ0Wgiwg4vG6j3oq5i/XR4hSB7oGAeANf /2ef7R4aUy0pAtpAADo8d/eqZMWsDeFUBkWguyKg3tuluquVVG+KQGcI/D+o6iKlPXlcbQAAAABJ RU5ErkJggg== --_004_EBDD2E088274B14BA201104F444C8E4E9CC1830A26HE111649emea1_-- From nobody Thu Jul 30 08:01:42 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 211221A9036 for ; Thu, 30 Jul 2015 08:01: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 aHQzyov4MMyc for ; Thu, 30 Jul 2015 08:01:37 -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 B7D681A903D for ; Thu, 30 Jul 2015 08:01:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B18BF167C; Thu, 30 Jul 2015 17:01:31 +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 lkJnt-IG3kIo; Thu, 30 Jul 2015 17:01: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; Thu, 30 Jul 2015 17:01:30 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBD7320047; Thu, 30 Jul 2015 17:01:33 +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 udkIQPx3FV5t; Thu, 30 Jul 2015 17:01: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 16B5620046; Thu, 30 Jul 2015 17:01:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E443F35F6375; Thu, 30 Jul 2015 17:01:27 +0200 (CEST) Date: Thu, 30 Jul 2015 17:01:27 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20150730150127.GA17343@elstar.local> Mail-Followup-To: Jernej Tuljak , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> <20150730113821.GA16711@elstar.local> <55BA32C8.9030108@mg-soft.si> 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: <55BA32C8.9030108@mg-soft.si> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Thu, 30 Jul 2015 15:01:41 -0000 On Thu, Jul 30, 2015 at 04:20:56PM +0200, Jernej Tuljak wrote: > Juergen Schoenwaelder je 30.7.2015 ob 13:38 napisal: > >On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tuljak wrote: > >>Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: > >>>>On 30 Jul 2015, at 01:12, Andy Bierman wrote: > >>>> > >>>> > >>>> > >>>>On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > >>>>wrote: > >>>>Andy Bierman wrote: > >>>>>Hi, > >>>>> > >>>>>I understand the intent is that an implementation of NACM > >>>>>has to understand these NACM extensions. I agree with Lada > >>>>>that the YANG text about MAY ignore extensions casts doubt whether > >>>>>this sort of NACM rule is enforceable or specified correctly. > >>>>So do you agree that it would be a good idea to clarify this > >>>>according to Juergen's suggestion? > >>>> > >>>> > >>>> > >>>>Not really. > >>>>Pretending the extension is just another description-stmt > >>>>does not really fix anything. > >>>In fact, generic tools like pyang ignore what’s written in > >>>descriptions. > >>Where does RFC6020 say that description-stmt may be used for defining > >>additional semantics? The only instance where I can find "description" > >>and "semantics" or "meaning" in the same sentence, is in the section > >>that describes module updates. This is what a YANG description is: > >> > >> The "description" statement takes as an argument a string that > >> contains a human-readable textual description of this definition. > >> The text is provided in a language (or languages) chosen by the > >> module developer; for the sake of interoperability, it is RECOMMENDED > >> to choose a language that is widely understood among the community of > >> network administrators who will use the module. > >> > >>A textual description for humans. A docstring. I don't see semantics > >>being mentioned anywhere, so where is all this coming from? > >Seriously? Perhaps we have a different understanding of the word > >'semantics'. Anyway, description statements (or DESCRIPTION clauses > >back in SMIv2) have always been used to provide semantics that are not > >expressable in machine readable form. > > > >Example: The ietf-yang-types:counter32 definition defines a counter > >type because of the text in the description statement. I would say > >there is lots of semantics in the description statement. Without > >the description statement, the ietf-yang-types:counter32 would not > >at all be a counter. > > This does not change "semantics" as I understand them or as Ladislav > implied them. I was thinking "YANG language semantics", which is what > extensions are used for - extending YANG language with new keywords that > hold special meaning for a YANG processor (humans included). > > In a NETCONF message, ietf-yang-types:counter32 value will always be an > integer on the wire, regardless of what the description text says, > right? I also cannot magically turn all containers into leaves using > text in a module description, saying "All container definitions in this > module are actually leaf definitions", right? An extension could, > however, be used for such a thing - a sort of YANG pre-processor > directive (which any sensible YANG tool would ignore). There are many ways to write nonsense definitions. typedef foo { type int; description "contains one of the strings 'one' or 'uno'" } Obvious nonsense written in plain YANG. I fail to see why extensions are in any way different or more problematic. > I disagree with the interpretation that an extension is just a > formalized description statement. Well, at the end every YANG language construct is a "formalized description statement". If I were to define a meta language to define YANG, it would not have much else than this statement { description "" } All we do is agreeing on certain constructs to be generally useful and so we can write shortcuts that have well defined meanings. This is why we have a language and do not write everything in prose. It is more compact and more efficit. A welcome side effect is that tools can read _some_ of the semantics and help us getting things well defined and implemented. > I also disagree with the notion that a description text may alter, > augment or define YANG language semantics, unless it describes an > extension keyword. This is of key importance for generic tools, so that > at the very least they can support standard extensions, such as > "annotation". Having to parse human text would render such tools > completely useless. As long as you are willing to accept that description text are part of the semantics of a definition, we are likely in agreement. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 30 08:27:08 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 BF3501A87A8 for ; Thu, 30 Jul 2015 08:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ahr6xGf0Augv for ; Thu, 30 Jul 2015 08:27:00 -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 A465E1A9063 for ; Thu, 30 Jul 2015 08:26:59 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id B4756F9EB4E01; Thu, 30 Jul 2015 15:26:54 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t6UFQrRf008302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 15:26:55 GMT Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.242]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 11:26:54 -0400 From: "Lam, Hing-Kam (Kam)" To: "B.Zeuner@telekom.de" , "netmod@ietf.org" Thread-Topic: Mail regarding draft-mansfield-netmod-uml-to-yang Thread-Index: AQHQyh22Uqyd0J/A30GczhkujIMBLp3ytUsAgAFotuA= Date: Thu, 30 Jul 2015 15:26:53 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C7775858F25EE4D@US70TWXCHMBA12.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/related; boundary="_004_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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, 30 Jul 2015 15:27:08 -0000 --_004_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_ Content-Type: multipart/alternative; boundary="_000_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_" --_000_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Additional responses inline below. Regards, Kam From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of B.Zeuner@telekom= .de Sent: Thursday, July 30, 2015 10:44 AM To: netmod@ietf.org Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang Hallo, Thanks for sharing your questions and comments; some initial responses are = provided below in line. Note that we have made some further progress that we plan to reflect in an = update of this draft which of course will take into account the netmod disc= ussions and input including this e-mail thread. Regards Bernd Deutsche Telekom AG Europe & Technology Standardization Services Bernd Zeuner Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Germany +49 6151 58-12086 (phone) E-Mail: b.zeuner@telekom.de www.telekom.com Life is for sharing. Deutsche Telekom AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: Timotheus H=F6ttges (Chairman), Reinhard Clemens, Niek Jan van Damme, Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn, Germany VAT identification no. DE 123475223 Big changes start small - conserve resources by not printing every e-mail. From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ari Sodhi Sent: Wednesday, July 29, 2015 6:44 PM To: netmod@ietf.org Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang There are some interesting ideas proposed. Here are some initial questions = and somewhat random comments based on a quick read of draft-mansfield-netmo= d-uml-to-yang-00. General questions on draft-mansfield-netmod-uml-to-yang: 1. Is the proposed mapping supposed to be bi-directional in nature? In o= ther words, is the intent to support a mapping between UML and YANG that en= ables IM UML -> DM YANG -> IM UML in a round trip manner. [Bernd] The inte= nt was UML -> YANG; but YANG -> UML is also possible. The rationale o= f UML --> YANG being the intent is that we start with protocol-neutral mode= ling using UML first. The I-D draft-betts-netmod-framework-data-schema-uml = contains more details of this approach. Now given so many YANG drafts have = been created, in some cases it might be helpful to revert (YANG --> UML) en= gineer the YANG drafts to UML so that comparison/analysis can be made. The text in this section uses the term predictable. Should it not be de= terministic?[Bernd] Yes, agreed. 2. Does there need to be a set of UML usages defined - similar to what O= NF did? The referenced ONF TR-514 UML guidelines, which is publicly a= vailable, described the usages. Some of the UML concepts such as agg= regation usually need definition as even the OMG UML 2.5 spec says aggregat= ion is open to some interpretation. This is touched on in section 5.5 of dr= aft-mansfield-netmod-uml-to-yang but it seems ambiguous as both composition= and aggregation map to container. The examples are not so clear - the firs= t seems more like composition to me as there is a lifecycle implication bet= ween instances of ClassA and ClassB. The second example - the list could al= so be a set of leafref to the ClassD key. [Bernd] You are right. Some statements (to be verified): =B7 UML composition association is mapped to container/list within = a container/list; the reference is "passed by value" =B7 UML aggregation association is mapped to a leafref within a con= tainer/list; the reference is "passed by reference". 1. Did the authors consider the use of UML stereotypes/annotations to he= lp support the mapping between UML and YANG? This may help remove potential= ambiguity in the mapping. [Bernd] We did not add YANG specific UML stereot= ypes because the intent was that the UML be agnostic to any data schema (DM= ). Hi Ari, I am not sure I understand your question correctly? Do you= mean applying the lifecycle stereotypes to qualify the status of the mapp= ing rules? I.e., some of the mapping rules may be preliminary at the moment= , etc.?. comments on draft-mansfield-netmod-uml-to-yang: 1. Section 3 - What about UML packages and module/submodule relationship= . Modules can be a root package with submodules being sub-packages.Need to = enforce the semantics of include/import per RFC 6020. Any value in consider= ing relating YANG features to packages - ie. Represent yang Feature stateme= nts [Bernd] The mapping of UML packages to YANG modules/submodules is an identi= fied open issue which is under discussion. You raise some good points to co= nsider. 1. Section 5.2 - UML abstract is stated to map to a container. Container= s either represent containment for organization reasons or with presence th= e container itself is configuration data. I do not get the mapping of abstr= act to this. Can you explain? [Bernd] The current thinking is to map abstract superclasses to "grouping" = statements. This allows also to map multiple inheritance. Note: This is als= o the mapping that we have used for the Link object class in draft-lam-teas= -usage-info-model-net-topology-01. 1. Section 5.2 - both support and condition map to "if-feature" statemen= t in yang. This seems ambiguous. How does one distinguish in YANG which is = which? [Bernd] Support and condition belong together. If the "support" is conditio= nal, then the "condition" explains the conditions under which the class has= to be supported. 1. Section 5.2 - "must" statement - could this not map to OCL? [Bernd] Good idea; we are still discussing this point as a general place fo= r mapping UML constraints. YANG seems to have here constraints between attr= ibute values in mind. 1. Section 5.2 - wrt objectCreationNotfication/objectDeletionNotificatio= n - in UML how are these represented -seems to rely on ONF OpenModelCass if= I understand the source correctly? [Bernd] Yes, you are right. This is an = additional class property defined in the OpenModel profile. It defines that= a notification has to be sent when an instance of this class is instantiat= ed or deleted. It seems like there are some assumptions wrt to the Object C= lass. In YANG can these map to notification statements. [Bernd] Meanwhile w= e have mapped this to the "notification" statement which goes beyond the si= mple "a notification has to be sent". Is there some notification hierarchy = in YANG/UML where these notifications (objectCreationNotificaiton/objectDel= etionNotification) exist? [Bernd] Not now; but will be in the future. More = current drafts of RFC 6020 (I.e. draft-ietf-netmod-rfc6020bis-06) propose n= otifications to be top level of a module or associated with data nodes (con= tainer or list data nodes). This notion could be leveraged as the source = of the notification in YANG - xpath to its source in containment model. 2. Section 5.4.4 - a complex data type does not always map to grouping I= MO except if the grouping has a singular top level container. A grouping is= a reusable construct that gets "flattened out" in the context they are use= d within. Groupings can also be refined/augmented to tailor their usage con= textually. [Bernd] We define complex data types in a separate UML package (TypeDefinit= ions). They can always be reused as the type of class attributes or operati= on parameters. 1. Section 5.5 -The mapping is ambiguous as stated above. composition = is a stronger type of association then aggregation and infers ownership of = lifecycle of the contained items. That is when the composing instance is de= stroyed, the contained items are also destroyed. Its a is a part of relatio= nship. Aggregation can be used to mean a point of control for manipulating = the contained. It does not infer lifecycle control. [Bernd] That's completely true. See our answer to General::2. 1. Section 5.5 - Its not clear how cleanly augment maps to inheritance. = Augment can apply to many things in YANG - container, list, leaf-list, uses= , choice .... I can kind of see augment of a container mapping to inheritan= ce. Augments can also specify conditions as to when they apply - i.e. If if= type =3D=3D ethernetCsmacd [Bernd] True. In recent discussions we concluded that augment is more appro= priate for mapping to conditional composition then inheritance. We see the = "grouping" statement as the main mapping for inheritance. The "extension" s= tatement is no longer used here. 1. Section 5.6 - I don't see how UML interface maps to a container. A UM= L interface represents a contract. A container either represents containmen= t for organization reasons or with presence the container itself is configu= ration data. This may need more discussion - or at least more explanation. [Bernd] We use the UML Interface artifact as a grouping of operations. A co= ntainer can be used to group actions. [cid:image001.png@01D0CA3E.1F2ED390] 1. Section 5.11 - what does package map to? Is it module/submodule? [Ber= nd] Regarding the mapping of packages see our answer to Comments::1 above. = Could a conditional package not also map to module/submodule with if-featur= e as a top-level entity?[Bernd] That's possible but we see the conditional = Pacs closer to the object class. They provide the attributes for an object = class on a conditional basis. This pattern is used e.g., to enhance a techn= ology agnostic object class with technology specific attributes. Ari Mark Sodhi System Engineer and Architect II T 707.766.3413 M 707.775.1379 E asodhi@calix.com Calix 1035 N. McDowell Boulevard Petaluma, CA 94954 T 707.766.3000 F 707.283.3100 --_000_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Additional responses inline belo= w.

 <= /p>

Regards,

Kam

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of B.Zeuner@telekom.de
Sent: Thursday, July 30, 2015 10:44 AM
To: netmod@ietf.org
Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-y= ang

 

Hallo,<= /p>

 <= /p>

Thanks for sharing your q= uestions and comments; some initial responses are provided below in line.

Note that we have made so= me further progress that we plan to reflect in an update of this draft whic= h of course will take into account the netmod discussions and input including  this e-mail thread.

 <= /p>

Regards=

Bernd

Deutsche Telekom AG
Europe & Technology
Standardization Services
Bernd Zeuner
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Germa= ny
+49 6151 58-12086 (phone)
E-Mail: b.zeuner@telekom.de=
www.telekom.com

Life is for sharing.

Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: Timotheus H=F6ttges (Chairman),
Reinhard Clemens, Niek Jan van Damme,
Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn, Germany
VAT identification no. DE 123475= 223

Big change= s start small –= conserve resources by not printing = every e-mail.

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Ari Sodhi
Sent: Wednesday, July 29, 2015 6:44 PM
To: netmod@ietf.org
Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang<= o:p>

 

There are some interesting = ideas proposed. Here are some initial questions and somewhat random comment= s based on a quick read of draft-mansfield-netmod-uml-to-yang-00. = ;

 

General questions on d= raft-mansfield-netmod-uml-to-yang:<= /o:p>

  1. Is the proposed mapping supposed to be bi-directional in nature? In= other words, is the intent to support a mapping between UML and YANG that enables IM UML -> DM YANG -> IM UML in a round trip ma= nner.  [Bernd] The intent was UML -> YANG; bu= t YANG -> UML is also possible. <Kam> The rationale of UML =E0= YANG being the intent is that we start with = protocol-neutral modeling using UML first. The I-D draft-betts-netmod-frame= work-data-schema-uml contains more details of this approach. Now given so many YANG drafts have= been created, in some cases it might be helpful to revert (YANG =E0= UML) engineer the YANG drafts to UML so that= comparison/analysis can be made.  </Kam> The text in this section uses the term predictable. Sho= uld it not be deterministic?= [Bernd] Yes, agreed.
  2. <= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-s= erif";color:black">Does there need to be a set of UML usages defined &= #8211; similar to what ONF did? <Kam> The referenced ONF TR-514 UML guidelines, which is publicly available, = described the usages. </Kam> Some of the UML concepts such as aggregatio= n usually need definition as even the OMG UML 2.5 spec says aggregation is = open to some interpretation. This is touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang but it seems ambiguous as b= oth composition and aggregation map to container. The examples are not so c= lear – the first seems more like composition to me as there is a life= cycle implication between instances of ClassA and ClassB. The second example – the list could also be a set of lea= fref to the ClassD key.

[Bernd] You are right. Some statements (t= o be verified):

=B7         UML composition a= ssociation is mapped to container/list within a container/list; the referen= ce is “passed by value”

=B7         UML aggregation a= ssociation is mapped to a leafref within a container/list; the reference is= “passed by reference”.

  1. Did the authors consider the use of UML stereotypes/annotation= s to help support the mapping between UML and YANG? This may help remove&nb= sp;potential ambiguity in the mapping. [Bernd] We did not add YANG specific UML stereotypes because the intent = was that the UML be agnostic to any data schema (DM). <Kam> Hi Ari, I am not sure I understan= d your question correctly? Do you mean applying the lifecycle stereotypes&n= bsp; to qualify the status of the mapping rules? I.e., some of the mapping rules may be preliminary at the moment, etc.?. </Kam>=

 

comments on draft-mansfield= -netmod-uml-to-yang:

  1. Section 3 - What abou= t UML packages and module/submodule relationship. Modules can be a root pac= kage with submodules being sub-packages.Need to enforce the semantics of include/import per RFC 6020. Any value in considering relatin= g YANG features to packages – ie. Represent yang Featu= re statements

[Bernd] The mapping of UML packages to YANG modules/submod= ules is an identified open issue which is under discussion. You raise some = good points to consider.

  1. Section 5.2 - UML abstract is stated to map to a container. Contain= ers either represent containment for organization reasons or with presence the container itself is configuration data. I do not get = the mapping of abstract to this. Can you explain?

[Bernd] The current thinking is to map ab= stract superclasses to “grouping” statements. This allows also = to map multiple inheritance. Note: This is also the mapping that we have used for the Link object class in draft-lam-teas-usage-info-model-net= -topology-01.

  1. Section 5.2 – both support and condition map to “if-fea= ture” statement in yang. This seems ambiguous. How does one distingui= sh in YANG which is which?

[Bernd] Support and condition belong toge= ther. If the “support” is conditional, then the “conditio= n” explains the conditions under which the class has to be supported.

  1. Section 5.2 - “must” statement – could this not m= ap to OCL?

[Bernd] Good idea; we are still discussin= g this point as a general place for mapping UML constraints. YANG seems to = have here constraints between attribute values in mind.

  1. Section 5.2 – w= rt objectCreationNotfication/objectDeletionNotification – in UML how = are these represented -seems to rely on ONF OpenModelCass if I underst= and the source correctly? [Bernd] <= /i>Yes, you are right. This is an additio= nal class property defined in the OpenModel profile. It defines that a noti= fication has to be sent when an instance of this class is instantiated or deleted. It seems like there are some assumptions wrt to the Object Class. In YANG c= an these map to notification statements. [Bernd] Meanwhile we have mapped this to the “notification̶= 1; statement which goes beyond the simple “a notification has to be s= ent”. Is there some notification hierarchy in YANG/UML where these notific= ations (objectCreationNotificaiton/objectDeletionNotification) exist? [Bernd] Not now; but will be in the future. More current drafts of RFC 6020 (I.e. draft-ietf-netmod–rfc602= 0bis–06) propose notifications to be top level of a module or associa= ted with data nodes (container or list data nodes).   This notion coul= d be leveraged as the source of the notification in YANG – xpath to its source in containment model. 
  2. Section 5.4.4 – a complex data type does not alwa= ys map to grouping IMO except if the grouping has a singular top level cont= ainer. A grouping is a reusable construct that gets "flattened out" in = the context they are used within. Groupings can also be refined/augmented t= o tailor their usage contextually. 

[Bernd] We define complex data types in a= separate UML package (TypeDefinitions). They can always be reused as the t= ype of class attributes or operation parameters.

  1.  Section 5.5 –The mapping is ambiguous as stated above. =  composition is a stronger type of association then aggregation and in= fers ownership of lifecycle of the contained items. That is when the composing = instance is destroyed, the contained items are also destroyed. Its a is a p= art of relationship. Aggregation can be used to mean a point of control for= manipulating the contained.  It does not infer lifecycle control. 

[Bernd] That’s completely true. See= our answer to General::2.

  1. Section 5.5 - Its not clear how cleanly augment maps to inheritance= . Augment can apply to many things in YANG - container, list, leaf-list, uses, choice …. I can kind of see augment of a container = mapping to inheritance. Augments can also specify conditions as to when the= y apply - i.e. If if type =3D=3D ethernetCsmacd

[Bernd] True. In recent discussions we co= ncluded that augment is more appropriate for mapping to conditional composi= tion then inheritance. We see the „grouping” statement as the main mapping for inheritance. The “extension” statement= is no longer used here.

  1. Section 5.6 – I don’t see how UML interface maps to a c= ontainer. A UML interface represents a contract. A container either represe= nts containment for organization reasons or with presence the container itself= is configuration data. This may need more discussion – or at least m= ore explanation.

[Bernd] We use the UML Interface artifact= as a grouping of operations. A container can be used to group actions.
3D"cid:image001.png@01D0CA3E.1F2ED390"

=  

  1. Section 5.11 – what does package map to? Is it module/submodu= le? [Bernd] Regarding the mapping of packages= see our answer to Comments::1 above. Could a conditional package not also map to module/subm= odule with if-feature as a top-level entity?[Bernd] That’s possible but we see = the conditional Pacs closer to the object class. They provide the attribute= s for an object class on a conditional basis. This pattern is used e.g., to enhance a technology agnostic object class with technology s= pecific attributes.

 <= /p>

 

 

Ari Mark Sodhi

System Engineer and Architect II

T&= nbsp;707.766.3413

M&= nbsp;707.775.1379

E&= nbsp;asodhi@calix.com

 

Calix

1035 N. McDowell Boulevard

Petaluma, CA 94954

T&= nbsp;707.766.3000

F&= nbsp;707.283.3100

 

 

--_000_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_-- --_004_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=7816; creation-date="Thu, 30 Jul 2015 15:26:52 GMT"; modification-date="Thu, 30 Jul 2015 15:26:52 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAQMAAABzCAIAAAAT5vDpAAAAAXNSR0IArs4c6QAAHkJJREFUeF7t XQdcVMfWH2xJ1CTPlBelqUgJaBLfUxGlSQAjGDC2l8SCCqJIKIJ+goAIRlSMikKCWJBiiT7RQPSJ Cqg0KTE9qFRpi74Uk5fEXvY7M/fu7r3b2F3WKLtzf/OD2XPPnDnnP+WcuTuz10AoFCJ6UQT0HoEe eo8ABYAigBGgI4H2A4oAQQCiI+YaOXIkhYQioD8IQIcXd37IGIjXCQYGBg8fPtQfIKileo5Ajx49 uItkGh3peX+g5rMI8HzCgwcPKDAUAT1BoGfPnlyfwBsJ9+lI0JNeQM1EqBd/JNDoiHYKioDMU1Tu UprmVUOgOd2jJ8wuvTzSm1UroIzr7Aqtieq6MrouQWoC4EVH9+7fp/OD+gici+i10arxhO9guUWV 3+UWAU43VHg/cYL6KtAS6iPQu1cvhc+OYOMFTRogQL6WUZiU3+UWRGii5RDaBH8RAlJjR2qdAHuQ aFIXAQZSKHUusrfnnj0r+vTuBWnynmZCcduCTgeY9+oTcQ7ztKRPJnf79F5RLCoSGeFJKCwnKSgs jmDYRAUxc/OeySwxspgoKS1NXc31nJ83FngjQYPpUB+LtOyZ3HvynpaWPZ69oXtjBJihgDOnA2o9 79y9d6cgvGBxarHQef3dwjA0Ma3h3p0NzkLo3uZHpkMeM6CN6S1Mke8tUzFFxHl8wWCgO20gbEDc snFPCwiH6syPTGsgxHvrnYAiI+1cRJ/eEcVAx+r9RTNr9+0Ayn2C+tGW3pUojjSvXXE3FS0JRNvv bXCWsn9iWiAhOXuGoR8aW/l3Wxt/wP6h91N9ej/lvqWgDuZ+uCZOd5O3wiiOwGx93JIYGa1FRwrC V3DXIrLSnBPvNFhtnNwYiNWbnCFVu961lHoG0+hIzQih+ESSOwTzV2oL1CzIhp3hBXfv3mHSBieF sWhr+tvuiHA2pLmLK2JiMG6SJ60gpwiPgdO1VzTTUH9K0eioKw8GnDbcTkWBfTZa1q+oNe8TCcE+ iY2YIEGckU80GTYCQazTyl8lS8IYSfErdQXulqYgs6XwSAFhMHGb5s4vKyutOPIp87rld0CxJcLU uySCoknZkwzuUKDfrKnnQzG3qe+xO/9ZYOq8/g70ttaMt92TUMGSQIjM5V7Ok8IKllj0eRoGDXJe X5+GAsyffqoPTpii4HIK3I4CrIAnsG6EO8NjuuB4wQhR2ZUlQJGRBqMUliNAx+qpb5d+l+B9n3Dr 9h39RoNar0cIPPP0Uwr3Hd2kI0GPeoK+m9pX2Ui4dVvf4aH26w0CfZ95WqFPuEFHgt70A2poP2Uj 4eYtChBFQE8Q6Nf3GYU+4U86EvSkF1AzEerPHwn0KSrtFBQBjIDUviNd35OuNfuKo/o+039lsZS8 lkyv/n29MmE/UecXSFDEydxqyfR+Buat/t4ZKslTXmPJSq2J6ty07sEhNQHwRwLdiaoyAgi5udVs ymrlbn4o2RFYyOCryo4FJZzMV2k+eSdDkNvHKfNN5Assie7nzVdAUb0l0ZO2hpy8+XueIlEqKayK Ud2IR9lIoG5SLQRshqPcs5xtbqUnk0OXhqgl4q9jdrOUf5Dor9PgCa9Jb3xCa+bUfn2fIymmlJkC S2JgTi1l6VOzWtn5TMIZBXsaWLasKKasmA3a1SJguU1gGuGB1Jq16YeUgEkShyCnRiQUEadmNcnj ZGqUeBURD1GVpwNQJiWjwiDrvs9FlWAF5KkdE+VN1GY5GeVLolgc2IKM8lP44EhL00GnodQn6MyO rZbMaf28s1tasqf0XQX9RFiyyjpweP6N//15438XU2smwS3mVEFh8Ca0jRBRYBAhAufRdy4Sznxh UiZs8ydstZMIJbQocHup5ESC48TQraexfDg0cyYXTXOBOAZ3XkU1StTYJjyaLOGUrZE97iCSJquD 44d/4tgpBVRNcFSkdo1lClZbxHnUxwR0c0wg1gFx2yZiMqD0au7US4R440MHeSCUrHy+38pSAAej qivb+vhDQSd9QmmMTW3YnynCkGBh8o010E9am2pQ6ETIQAcznRcWWlhHergQuSUnzzPmEjFnYbBN v+f793veY1tRHTQ7YVvsiDOOHsGopomzNnBYnFqzGWJ1VLoj0GYZEcUkuTUC0S3Vn6hhPG95sIRT tkbZOVihDqLq5Kg9xQX2s8qIKo3C1vUHR8Goeja3MDRsHodTFgTHdb9dtEp6p8kfozpFtcXJk+5G 9GDFXJqf4mZlilrqyfKV6QqSUITzkcGCiW1gBDB5hEKP/XnjVyYl4AHAYZPkWaKpyxR09GxpVlIN 28XFzIpqFHdNDqfCGrnSuLaIVOUaqJLawtas6R6IGHgp2U1ssnSvlQWBuMajZFlUWM/OI096X1e+ fFc2EnRkM7tDwq/bhGH9N1nULKu36RcL0YvJUBu0TRTGZG7dFjoRxwAAVGHeGXLMseVMXiEhEs6t OCjixAC434k+ivNsxmRu+PAQj0D0zgQT7hkFuTUCsTBwF4mm2jI3pTASlNcoXR3/GIT4rupqN9cW weKZNZlRYMIUN77JstJKogbY1C79A/AMhmhyDYNed0/8oaCT0REOgQ7/kTvH1DH+jz/jcTTiGF/z yUXP/gOe7T9g+GfeNQn2rCtws64LIcQPrE8wRMyJgmwwEVJ0aeePBR0Xb3MLXcqNLkRyZGp0jD8R mkLUCENTg1gdFNXYmj3VIwUVhoTi6EueGo4TQwpDhjNKqqw2aIs+eB1MC62zdmPEms75LN9aZPIq /DhBRppjwvU/AB/AE1Dt3q5AyieLhwPvfML13/+Qchk6/bE09rktFjWfzWWWufTSMwReeO5Zxb93 JH/u0ZE5QHZalQrlO5/+9Qwf3QZED9YJqsev3AWA6qUop24gwB8KvOjo5//9rmcekpqrvwi89Pxz Cndl69hIWPvZd83tMLYNyCMSA/zPAH9gPAFzDTV+Nmbq6/rbHfTYcmUj4aff/qdLyCxMKU9eBL8p pOwK3lmcHuygS1ZTW1RE4OW/Pa8vb5d6+ODhU316Qvq6SQB/nVfnMElMgQx6KP7qTEUAKZtuIqDL 5xOgxXr17FF5uXVpVgVkLmx8HyjwF/JAATpkSKTU6dW6b/rzMIW8PB22sHX5Ko3RkqjS1aDSKtgG Jb6AMm2fFlTsso3dQYDSZ0c6N9p79TSATv/N5lmQgUTGBs4AhQwPZtXQ6WUyO+d4IHJNSoItbHKv srgB0/e3dSoHGMrivFICj/32Y44iUaoIEfO4ulx8O65MrSKUWT4COu4TevfssXXeuJHLDkAGEmDA ZIACdIaiZP4qXzV9v2iKxfgpZlV+l1sOIVcLU+3MmVCp99LkS1uz20TyVFdDBQ1a989YVa4CXzdl 0SefIBT27mngOdqcdHqD4Uv3gfHwF/JAATpkHipaJ5THvvLCgIK3cmZJe4Gy+BdmHNiL70J6by84 AqB4paKisDcGvBJL5ue2ve+Ru6+8EHsef8ZF4mNnEArLSQqi87EMm6ggKXxgJkuMLyeNJS2N34Km c0OsQ5YTadxLRjJRu5xVDCS372X0YUyQW5HJrMMTC3i66bI/0e33Jzzs2cMAkpetBfxt/MSHSWIK ZMh8xt9L1rr3XWj+UxOv/fJr7HjOLfE2POj09fjutbzgs6G7yoUOsb8cW4Jct3zz67V4B6GwLO6N PC/IYwa0Dc/X8CV90UXzJEwRcX46B2/YGxdP2ID48db9sNlb2LZ/+ut5Xt8RIlO7PGlihYlK4+KP vRoaRoqT3QDkroxkrEPYFvQRUTvVa8AyIdGHNUFRRWDar9fcT8OAiYP9SN1/053UvkruyNbtX41H 3nGfe8cd84o7Js5AnnyEv3DrcwOZrSTnd4ecg269ULRJT7KtG4dHBDvRXYeJS9DF5jb+xu22pkuo KHzkgIEvDhg4JeVcA/PDwa7eE5jDC8wl2sdQtgqzvei1nSG2nf38bFDIXMkxByRHmuy2bvvVedbh u8XLBcIgJZlRO2mOMdzCaov0EZugpCKHhVtc0PYpq87r2rYbnovT0b2ook63P9Jzf6THgUgPcQby 5CP8hVuenF7JtvO4+OtXf9kiDHth4IuxEJ5w+53sUQdxca4chIKO/AJCSIq3lzodIeGEsGcKIpzf bnaRf46ClJWWJquS0MF/c41XPBkL+G5nkvnaiquWraht/wzAIVyYBEquGadb266kQj2+T9CxLVcq hrVyrIYQ+frVn98qfHHmAfGWaAW9XroLG5tZo49TIPjmipXb9Vrqz7nA4hnel3Pu2FnSy4wneLnw y8qVJmcomMzasu3SFOJb4K6sZIXDUeSi5FTUdmBGONoCOByexfFSuuMY+N1DyifoVCgIls5JzFee SM9RZPX4VT//+30cz7cemAmdrGhZeHYbeohwYoqI8+NdPyha9o8XBq2GowLjV329FS19Y9BLL+CE KXKLCIX2Czej0DHAE15v7cLINH7/cJ61qOwaeHAjR5pYW65YodBkzsatLqxuciQr0IFjgozaoAxj vm4mqXmStwNP8NMvKk6j3YJtcUrZvggP5arCONlBd1t0i+bUtpJGL7+oL7sttA0dlafLCPB8QvuP P+uSrZtOXG5o6sTLmZu9uNzzVV2ymtqiIgLGf39J4a5sHRsJKiJC2fQTAWUjoU23fIJ+NjC1WkUE TPg+QbKVBsqPGw9fJ9GLIqAvCHB3TPHWCa3//UlfMKB26j0Cpq+8rHCd0HLtR73HhwKgLwgMHvh3 +hRVXxqb2qk6ArzoqPnqf1UvSTkpAt0agSGDXqE+oVu3IFX+kSDA8wlXOq49kkqoUIrAk4fAUMOB ClfMTXQkPHkNRjV6RAiY8UcCfQvtI8KZiu1mCPCio0bB1W6mPlWXIqApAsOMBtEVs6bg0XK6iwDP JzS0U5+gu01NLeMjYG7M8wlSI6GDwkUR0BMEzI0NFT47qm+jI0FPugE1E1mY8EYCfXZE+wRFACPA i47q2wQUFYqAniBgYWKkMDqqa6UjQU+6ATUTWZryRgKNjmifoAjIREe1Le0UFYqAniBgNdhYYXR0 mY4EPekF1EyEXuWPBN45Zls7+OlLelEE9AUBheeYLzWr9FoYfcGJ2qnTCFgPgV+6lLxlj/cU9dIV +DlcelEE9AIB66H41UZiU3kj4SIdCXrRB6iRGAEb/khQ7ylqaNZlm7mbwjPqKJYUAR1DQKU3DoZk X7Tx2QaupKDoeGlK2MmiHMjbzNkcnlX/+N42V/HRUFObdRVSCggOzrUZOjenXRW9QIIiTv6tirUw fzDJ/6D47X6qVKEOT/un/qpqro7YJ4RXM+sw8tJthJt4XUXVuq62hdRI7vydOuFZtYWFx89sChg+ d0tm9MLb91DG6uDhPklntoScLMhdmtX4uF4/gpCzfW3qEQH31RaVB1YWMxaqopUSTsmtyoThs2rX lLb80ASp/K18+0WH2lURrhpP5SYzH9YEo/d2NGVPM1JJc9WEP3ZRXbGu/cj8wcPPogVSrSk4GJfv eXql3ZiV0BZR/NZXz15lI0GuvwM/cHx96M27wv8kBrzYr+/tW/cHPtMrf33wjbsPjiV+UFCU+xi9 pKUVOlXG+TawsijDfxGDnZau9qNpOxccwB2UXMbTEhLRyqxqLUmnYhQjYDwts+WHla5SDB1lJ5CH gyHTFgFWsdmV2sKwc5/wbfYy78iUW7d73LzZI6/0y8/Lq3OKL/xx+/6N28IpkanfZy9TdX4SHFxs NngESZsqmeFL5oxKlr5YPNdKOBOgz7FshxKYshI2hIb4BFqQfkmktR9Jq433cZXoI6dGJBQRFx9q lsfJ1ChKgrJTJYsc7TgUI4eJTrWwU1Et5Tet9xlhhiVXr2cRGLG+kkh4NwMVxzoOFn0U+QdFWMkD QTX8YYrlm8Yzs0tN8xda116RjyY6GLMmmwyzr22GrXKqISDNptQnyLxGaHlW/Ws+m9cGLvj99v1T X36FhPd2/edCT2Rw+sKFu7cerA/we21e0rK9DXLeP9R+MMDM52h7+9H5gzdXwAuKKjY7Rljsb/6+ sfn7ksT6WXCLvLUIFa9OQ7GEiFZGESJwnphYQjj3o/RD7Sxb05uEsqh8ZdYXjJ44Bhrr5L+zBMuH gVB2GnnaGTJ0RTVK1IhFJzIlnLI1MkIQchoGG7V4L6NFxVda1VO+3mzd941RY4TCMZHErsaD83el Hm0fuwwyyDkejI0cK7JIKVZSIFQkvGaW8AUghqFW/hYoJsiQy9PVpnlU1klaWax225USKzhWwBpi ONiipFGg8buv+EOhE59wquj4Ov/56AH6+fqdhw/vZ+R/Xbxu2s5TlT0eGAh+u3P/gXCd34LTp3Nl BmXlZqdG38Z1wpgo4drmcJhTBS11SDS5Gr3r6198hbySD2L9uLXvDoI2EhMxZ/FqpyGvDRvy2uyd 5U3MS16d4+ba4Vrs3pyPamHLrPgNeqPnJtbtOAQTQ/XeCIvFWBRucUhyawSiU+J7ZI4f9K8l8yWc sjWKppCSRgi/+AY6DzFRT3l3eyNWQuU6bNew92AQMhRWW25eCVZSINhFfVcybPeClvcw1PPkB82C Q4txjfarS3b64syQzaxDFvu9rjbNo7JOBh8puITIZIgT2xk0cAvKfIKsOA/3t6N2Zzf/fPP6zVsG QrRg8j9doo74edg+7NHz9xt3m3+9EbU7w/0tb+mClWcyYSpFMIIlLc1UrLD5kaCtVnx3UXpj87dM iiQDQG6PYYgQrqATlZWH0mvZLi5mllsjl8jhVFAjjoV2lnC7jqDsNExLonWtyCLVlBccCpiNiGnl cU7K0OgMKx4gqOREJd5Nz04u0m1h9O52tkbWxjBusCfCVgtN82isk+n93LmDuAhNnzEoGwmy3nPD 7GHfZoTuPHLoxzs30dPw7bSB3+QxCPVAfV66dvtu+uHD32aGbpplLl1w7MpvPxSuGZY6tDjgitOQ LRC9GJpaIHEYczB9l7/TWDbAOA1LXhzblJ4uIUTCyQZFYscHTS+bZ4mGUxdZxs2OQJPs4YQ2iTHI X7k1ArEk4lMSTV09lJrF4VRQIwj3z5qdcIGtvWKLUwRa5zOarahYPeVbG847meFYCxsrskjWNIVY yYBQkfCGU4NfA4C8En14JZyBVFHiVsTl0VbTaN06bmuyChsPdbrcJo4D25vrGTw1S2pFR9Ct3liw zdtz8m9/Prh+59ZvD//+E/rbr8KXrt+9d/3GrXc8PUcuSJbvmIzeTW3IesfILqzhCpmE7MKKN9TP GfqG+dA3nE+4F0eNYmcjJ4umKEKMtNjHEDEninLAREgbYGUpL4TgEu3mrXby9/0XG4GIpje5NdqF 7fPPImqsQZ7zWB+ltEa7qG/2IT9GGfP30b4rqZKK1FQe9ESRk0DOqkYLJ8YB2jkuLIlzljJTEVaS II21EXRrANAAZIBa+cLR6J09LOYy7aWlptGydYKjvhjwLETw8T0ER+yFyGjsJHS6XMCa0NZ43nLw QC2tmHm7Lb6pb5JyGfAxOOuH0nOFLi7uxWdP2Tu59e7Z+57wQem5c64TnIuKz7q5eWKfoOFVmWSR NuRc5lT2GaWGUh5TsW6tfKeYPanWCQ4FxqBVGbAgFHy2IBqt1bzzjLQwU/jLX3Jn9+R5I2ztnM+e LfoyI7y05Mzvd2+VFxV9nRFUdPaMu5vXR7PMNVis0CIUAQ0RMHo32iPfI7Hyi0TH+FcDOvOEyvyk eusEJgLbsWjk13uCITPJdeqF8vNuk7wh/3VGyMb3h2gYokmCfuLnNYvzHnspJmp77Go8IgWeVOsM Z2Z8vWLs6BWN8LdL4POHAi86+qqusVOvSRkoArqBwD8th9HfRdWNpqRWaBMBnk/4srZBm7KpLIrA E4zAKCtzzX1C5KdNo/ySo/c3P8EGUtUoApogoNL5hIiDDaMWbpc6nzDKNyX605bHt/u9cquV+ajE SikFrh6eP8pqfq5K5xNAgiJO/q2qDTB/MCnosEqiNYGl/VCQqpprIv4xl9HEuvZcPxb2rVUS9XET J1ZeSOxqWyh9diRvLEV/eoU5nzDa72Px+YTRCz9hzies/PQx/giAw7i6tDzez/ZVHYop02RCUFKm OnG0z+VVRfUXLkM653ZyQnCOFn8psGrbqwtYE4z+lXI5Y0q3/GpFEXxds666HMUT2LMX7vVJ/JKp RPDvhJMex1eMHbUC2iKG3/pdavnOfUKn5xMe02SDzTa3RIUVsBlRdFWd3evrN5d5tNn5JXpMKIdT fEuQu3P33Kw93vhnleEy9I5PQDF7YTOsli4lOmiphscppmvWjZnJwj5mwlx0uY20cwdsy55kj18f C23hb/Xhfo6zUNNStX1C1a4gJecTvtgVpOpI7DgcYm05hqRk9qhLdbK1b141Sw85IvrNegln4gUs nbAdSWTKStgQGjw7wDxmL+GBqyNvV23MbBeJPnJqBC5xdS3yOJkaRVdHeVGZ33hbDsXQ3tWhVoA1 VUP55I98x1hjyRc+YhEY8xE+rZBsPWcvKlvrain66JvHYKAIK3kgqIZ/R54/3zSemV1qmkduXUdL g4OHLT6e01F9ErmOIwd14DI2G1fXoq2X30j5BOlvKmIOto7x/1jJ+YQxi1Kj/w1He2W+4hAAuL65 go7chZbbquBu9TbX6GGZddUX66oLExrmwS1m/3/Z2p0okhBRTAwhAmf+m4WEMxNl53SwbE0uhOJX AV2fqQ7vt7cd75tejuXDNuzyIqHHmEEMXVGNEjUihfl7JZyyNbIWIXsz8X54kZll8LtQainfMHRt 9cWIUUI0ajmx6+K+OXvScgW2wZBBDtFg7HJbkUVKsZICoQpmh8QLgBiGuvNvmRR8DdjVpnlU1rGd qiM3NnrYwpkD8cf25jIrI2hi5tagwcPKmmATkmZfLSr3CdJfgat4PkFmE1RlsluTz8U1aHUMiq8N sRWijpZG5GcPGWgNwxk+vmUt+DDwQwT9IH4G7r1iIuYsS3CztLWxtJ2fXoF/eIawzYI9sEJk6zwH 1bZ3MGXhEo6aldC46/BVJPzyQPQwfxDF0uXXCMLtE2YSNQZNXzSHSCCcsjWSW3CVN3XwvrPHysDv CKql/Jvj8BEMnKoTsV02c/YxVYu15eaVYCUFgu2K6kKzbP+WmRhq8CfydjB0HA7FNU5IKE9fgjPg kPlsXW6aR2UdQezLTRMSrLJxF5KGCyiGg+2ZzqBZ4o2FTk7qaHg+obp4H0ylqL2lnG1wZj8p0/jc PIcoaK9lGRDy236xtopJy2GrsdKyhuPeRPnV1TnZtdDFFQmXSFCghoIaQbh9enk1B+mOijPlVsaG vIqESDXlO3JC5yNi2ploe7GxymHpRHMMTnl+NY6pYHKR1yMMZ2xla2RtDCYocZN2muYRWHf1iN8S lM30AameQz5CB2PbQoOhoNQnyMiLm2FSlbZEyfmEqh1L1k43lYZ2zIqqOLTBZufggkUtblYpVXBC zGQYwmEM5hTkZO/xsydTPLTfmfPkBJoAehghEs5seD4j1VZcMMSo4IyR90KrhPnR6K1x4EDZHgoZ uTUCsTz6MFHjWs5OPDGLOBXUCML99s3f+BVbe1WKWzRaM/ufbEVqKt/WVEFiLWIsp22lTFOIFaf/ MppXbRwLvrcGQI5FcbXBDKSKkngekmLQVtM8AuumnPTIWwabi8RGGWMnID65LGhrZPDULPGHgpRP kBNxjQ3YruR8gl1Amvw4zXB6Us1uL0PboJrLQTgGtg0qWFu/wGrscKux7vkuBf/3DxzdgQkOZldi CTHaLIMhYs6HsW9iIqRNVSIzxQc3oBRTlsnAYmFWlL3v3OlMPC+my63RNijDdx9RYx2aNJuVoLRG 2/+rzBAuYZQZ7iPMuJwkqUhN5UFPFD0F5MQ1mtkzytuOX1CW4C5lpiKsRPaKbQTdagA0ABmgVh4t G3rtZOCVTVpqGi1b1563Ox2VE7hIgqAOYujRb8HTQtFRnfbGCkuTVzRcJuBpmHvxdltU/HBZ6jZ8 XHGwTvn5hA/BJ2h4VX88Yqfp6d3eoocBGop5PMW6tfKdQvakWteRszQeRe6YMRAJPl+8Gq3WvPOM G/GqerstNr5nyZxPKE8LEp9PqEhbxJxP6MIw6LQxKANFQAYBwxmRb52curn6q82u6y0XaXEO5fmE 899fUo79mpxrJ4uOTXSfHDdNK9N49Sev7TI9tctLK8L+6m7TrZXvFCzdtg6bP/41a65PUG8kdIof ZaAIdBcEpEZC57+Bp9m6nJaiCDzhCChbMZd9d7G7DGiqJ0Wgiwg4vG6j3oq5i/XR4hSB7oGAeANf /2ef7R4aUy0pAtpAADo8d/eqZMWsDeFUBkWguyKg3tuluquVVG+KQGcI/D+o6iKlPXlcbQAAAABJ RU5ErkJggg== --_004_8DBC3FDAC14BE441AED9C5939C7775858F25EE4DUS70TWXCHMBA12z_-- From nobody Thu Jul 30 08:54:51 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 B82041B2DD4 for ; Thu, 30 Jul 2015 08:54:50 -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 ANfQaympOLiS for ; Thu, 30 Jul 2015 08:54:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E051A8824 for ; Thu, 30 Jul 2015 08:54:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 05E051864 for ; Thu, 30 Jul 2015 17:54:43 +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 9BLu3xgU9h6N for ; Thu, 30 Jul 2015 17:54: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 for ; Thu, 30 Jul 2015 17:54:40 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAE612004A for ; Thu, 30 Jul 2015 17:54:43 +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 bjYb-lE7lqUD; Thu, 30 Jul 2015 17:54:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D019D20047; Thu, 30 Jul 2015 17:54:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 70AFB35F649D; Thu, 30 Jul 2015 17:54:36 +0200 (CEST) Date: Thu, 30 Jul 2015 17:54:36 +0200 From: Juergen Schoenwaelder To: "netmod@ietf.org" Message-ID: <20150730155434.GA17437@elstar.local> Mail-Followup-To: "netmod@ietf.org" References: <8DBC3FDAC14BE441AED9C5939C7775858F25EE4D@US70TWXCHMBA12.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable In-Reply-To: <8DBC3FDAC14BE441AED9C5939C7775858F25EE4D@US70TWXCHMBA12.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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: Thu, 30 Jul 2015 15:54:50 -0000 Hi all, is it possible to use/configure an email quoting style that works with text-only email readers? I know, it is old fashioned, but I do read all my email in a terminal window... Thanks, /js On Thu, Jul 30, 2015 at 03:26:53PM +0000, Lam, Hing-Kam (Kam) wrote: > Hi, >=20 > Additional responses inline below. >=20 > Regards, > Kam >=20 > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of B.Zeuner@telek= om.de > Sent: Thursday, July 30, 2015 10:44 AM > To: netmod@ietf.org > Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang >=20 > Hallo, >=20 > Thanks for sharing your questions and comments; some initial responses ar= e provided below in line. > Note that we have made some further progress that we plan to reflect in a= n update of this draft which of course will take into account the netmod di= scussions and input including this e-mail thread. >=20 > Regards > Bernd > Deutsche Telekom AG > Europe & Technology > Standardization Services > Bernd Zeuner > Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Germany > +49 6151 58-12086 (phone) > E-Mail: b.zeuner@telekom.de > www.telekom.com > Life is for sharing. > Deutsche Telekom AG > Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) > Board of Management: Timotheus H=F6ttges (Chairman), > Reinhard Clemens, Niek Jan van Damme, > Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat > Commercial register: Amtsgericht Bonn HRB 6794 > Registered office: Bonn, Germany > VAT identification no. DE 123475223 > Big changes start small - conserve resources by not printing every e-mail. > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ari Sodhi > Sent: Wednesday, July 29, 2015 6:44 PM > To: netmod@ietf.org > Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang >=20 > There are some interesting ideas proposed. Here are some initial question= s and somewhat random comments based on a quick read of draft-mansfield-net= mod-uml-to-yang-00. >=20 > General questions on draft-mansfield-netmod-uml-to-yang: >=20 > 1. Is the proposed mapping supposed to be bi-directional in nature? In= other words, is the intent to support a mapping between UML and YANG that = enables IM UML -> DM YANG -> IM UML in a round trip manner. [Bernd] The in= tent was UML -> YANG; but YANG -> UML is also possible. The rationale= of UML --> YANG being the intent is that we start with protocol-neutral mo= deling using UML first. The I-D draft-betts-netmod-framework-data-schema-um= l contains more details of this approach. Now given so many YANG drafts hav= e been created, in some cases it might be helpful to revert (YANG --> UML) = engineer the YANG drafts to UML so that comparison/analysis can be made. <= /Kam> The text in this section uses the term predictable. Should it not be = deterministic?[Bernd] Yes, agreed. > 2. Does there need to be a set of UML usages defined - similar to what= ONF did? The referenced ONF TR-514 UML guidelines, which is publicly= available, described the usages. Some of the UML concepts such as a= ggregation usually need definition as even the OMG UML 2.5 spec says aggreg= ation is open to some interpretation. This is touched on in section 5.5 of = draft-mansfield-netmod-uml-to-yang but it seems ambiguous as both compositi= on and aggregation map to container. The examples are not so clear - the fi= rst seems more like composition to me as there is a lifecycle implication b= etween instances of ClassA and ClassB. The second example - the list could = also be a set of leafref to the ClassD key. > [Bernd] You are right. Some statements (to be verified): >=20 > =B7 UML composition association is mapped to container/list withi= n a container/list; the reference is "passed by value" >=20 > =B7 UML aggregation association is mapped to a leafref within a c= ontainer/list; the reference is "passed by reference". >=20 > 1. Did the authors consider the use of UML stereotypes/annotations to = help support the mapping between UML and YANG? This may help remove potenti= al ambiguity in the mapping. [Bernd] We did not add YANG specific UML stere= otypes because the intent was that the UML be agnostic to any data schema (= DM). Hi Ari, I am not sure I understand your question correctly? Do y= ou mean applying the lifecycle stereotypes to qualify the status of the ma= pping rules? I.e., some of the mapping rules may be preliminary at the mome= nt, etc.?. >=20 > comments on draft-mansfield-netmod-uml-to-yang: >=20 > 1. Section 3 - What about UML packages and module/submodule relationsh= ip. Modules can be a root package with submodules being sub-packages.Need t= o enforce the semantics of include/import per RFC 6020. Any value in consid= ering relating YANG features to packages - ie. Represent yang Feature state= ments > [Bernd] The mapping of UML packages to YANG modules/submodules is an iden= tified open issue which is under discussion. You raise some good points to = consider. >=20 > 1. Section 5.2 - UML abstract is stated to map to a container. Contain= ers either represent containment for organization reasons or with presence = the container itself is configuration data. I do not get the mapping of abs= tract to this. Can you explain? > [Bernd] The current thinking is to map abstract superclasses to "grouping= " statements. This allows also to map multiple inheritance. Note: This is a= lso the mapping that we have used for the Link object class in draft-lam-te= as-usage-info-model-net-topology-01. >=20 > 1. Section 5.2 - both support and condition map to "if-feature" statem= ent in yang. This seems ambiguous. How does one distinguish in YANG which i= s which? > [Bernd] Support and condition belong together. If the "support" is condit= ional, then the "condition" explains the conditions under which the class h= as to be supported. >=20 > 1. Section 5.2 - "must" statement - could this not map to OCL? > [Bernd] Good idea; we are still discussing this point as a general place = for mapping UML constraints. YANG seems to have here constraints between at= tribute values in mind. >=20 > 1. Section 5.2 - wrt objectCreationNotfication/objectDeletionNotificat= ion - in UML how are these represented -seems to rely on ONF OpenModelCass = if I understand the source correctly? [Bernd] Yes, you are right. This is a= n additional class property defined in the OpenModel profile. It defines th= at a notification has to be sent when an instance of this class is instanti= ated or deleted. It seems like there are some assumptions wrt to the Object= Class. In YANG can these map to notification statements. [Bernd] Meanwhile= we have mapped this to the "notification" statement which goes beyond the = simple "a notification has to be sent". Is there some notification hierarch= y in YANG/UML where these notifications (objectCreationNotificaiton/objectD= eletionNotification) exist? [Bernd] Not now; but will be in the future. Mor= e current drafts of RFC 6020 (I.e. draft-ietf-netmod-rfc6020bis-06) propose= notifications to be top level of a module or associated with data nodes (c= ontainer or list data nodes). This notion could be leveraged as the sourc= e of the notification in YANG - xpath to its source in containment model. > 2. Section 5.4.4 - a complex data type does not always map to grouping= IMO except if the grouping has a singular top level container. A grouping = is a reusable construct that gets "flattened out" in the context they are u= sed within. Groupings can also be refined/augmented to tailor their usage c= ontextually. > [Bernd] We define complex data types in a separate UML package (TypeDefin= itions). They can always be reused as the type of class attributes or opera= tion parameters. >=20 > 1. Section 5.5 -The mapping is ambiguous as stated above. compositio= n is a stronger type of association then aggregation and infers ownership o= f lifecycle of the contained items. That is when the composing instance is = destroyed, the contained items are also destroyed. Its a is a part of relat= ionship. Aggregation can be used to mean a point of control for manipulatin= g the contained. It does not infer lifecycle control. > [Bernd] That's completely true. See our answer to General::2. >=20 > 1. Section 5.5 - Its not clear how cleanly augment maps to inheritance= . Augment can apply to many things in YANG - container, list, leaf-list, us= es, choice .... I can kind of see augment of a container mapping to inherit= ance. Augments can also specify conditions as to when they apply - i.e. If = if type =3D=3D ethernetCsmacd > [Bernd] True. In recent discussions we concluded that augment is more app= ropriate for mapping to conditional composition then inheritance. We see th= e "grouping" statement as the main mapping for inheritance. The "extension"= statement is no longer used here. >=20 > 1. Section 5.6 - I don't see how UML interface maps to a container. A = UML interface represents a contract. A container either represents containm= ent for organization reasons or with presence the container itself is confi= guration data. This may need more discussion - or at least more explanation. > [Bernd] We use the UML Interface artifact as a grouping of operations. A = container can be used to group actions. > [cid:image001.png@01D0CA3E.1F2ED390] >=20 >=20 > 1. Section 5.11 - what does package map to? Is it module/submodule? [B= ernd] Regarding the mapping of packages see our answer to Comments::1 above= . Could a conditional package not also map to module/submodule with if-feat= ure as a top-level entity?[Bernd] That's possible but we see the conditiona= l Pacs closer to the object class. They provide the attributes for an objec= t class on a conditional basis. This pattern is used e.g., to enhance a tec= hnology agnostic object class with technology specific attributes. >=20 >=20 >=20 > Ari Mark Sodhi > System Engineer and Architect II > T 707.766.3413 > M 707.775.1379 > E asodhi@calix.com >=20 > Calix > 1035 N. McDowell Boulevard > Petaluma, CA 94954 > T 707.766.3000 > F 707.283.3100 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 30 08:56:20 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 693D81B2E30 for ; Thu, 30 Jul 2015 08:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bf8QR8J5DRSL for ; Thu, 30 Jul 2015 08:56:14 -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 E72731B2D67 for ; Thu, 30 Jul 2015 08:56:13 -0700 (PDT) Received: by lahh5 with SMTP id h5so27806794lah.2 for ; Thu, 30 Jul 2015 08:56: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:content-type; bh=cDj/CNoCmfrWktw7dvQx4n5/CYxRdn7NzmVuhLPd/n0=; b=YDMdi9Qu0npvgz4a4SgReB6NrRSabvlCuFSch36MYMu7HuCGA874DjLSZgryYyUXCp QwaAsvXe2rBaT6AetDhu6fauqlhXwUUi0tPyQ1B0LC0h1PF6gGq3dGcxilnE/udfsrhJ h38/YxXq1FyaiDRlnhxMfL7onLaHauTB0QfnR8fXoo4p9LmF+/hC9DADw4UgUmwgFJJM bDGBixKaZi+eKZVhh7h7SIxlr1uCCyLrtoGGo2iDX1hHS2Umdevh7LC/A0Ohxm9Hrdfz uD2NT0htccUOpG21qAkGkI3DkoKorUpwCnsIKpkRvL4kKLUjtzWJ8en3UQI+jqqktHPc CwlA== X-Gm-Message-State: ALoCoQkInFirbXCN6qsfRM5F/PpjbIoj3bYkBFkUJpOrIo9DntdbM5tHCvljUP3V4OkG8zXaJhzw MIME-Version: 1.0 X-Received: by 10.152.42.205 with SMTP id q13mr44510601lal.119.1438271772340; Thu, 30 Jul 2015 08:56:12 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Jul 2015 08:56:12 -0700 (PDT) In-Reply-To: <20150730113821.GA16711@elstar.local> References: <20150729.194431.2002520234234267282.mbj@tail-f.com> <20150729.195151.71742690632261308.mbj@tail-f.com> <2D3B91C8-7711-4E0A-9DA2-7AD9DF82B147@nic.cz> <55BA0AF5.3040505@mg-soft.si> <20150730113821.GA16711@elstar.local> Date: Thu, 30 Jul 2015 08:56:12 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jernej Tuljak , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c353e814cee6051c19be05 Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 15:56:18 -0000 --001a11c353e814cee6051c19be05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The YANG RFC should be very clear that description-stmt is normative text. Consider the operation that says a lock is not granted if one is already held. This is clearly normative text that cannot be expressed in YANG constraints. Andy On Thu, Jul 30, 2015 at 4:38 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tuljak wrote: > > Ladislav Lhotka je 30.7.2015 ob 11:30 napisal: > > >>On 30 Jul 2015, at 01:12, Andy Bierman wrote: > > >> > > >> > > >> > > >>On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > wrote: > > >>Andy Bierman wrote: > > >>>Hi, > > >>> > > >>>I understand the intent is that an implementation of NACM > > >>>has to understand these NACM extensions. I agree with Lada > > >>>that the YANG text about MAY ignore extensions casts doubt whether > > >>>this sort of NACM rule is enforceable or specified correctly. > > >>So do you agree that it would be a good idea to clarify this > > >>according to Juergen's suggestion? > > >> > > >> > > >> > > >>Not really. > > >>Pretending the extension is just another description-stmt > > >>does not really fix anything. > > >In fact, generic tools like pyang ignore what=E2=80=99s written in des= criptions. > > > > Where does RFC6020 say that description-stmt may be used for defining > > additional semantics? The only instance where I can find "description" > > and "semantics" or "meaning" in the same sentence, is in the section > > that describes module updates. This is what a YANG description is: > > > > The "description" statement takes as an argument a string that > > contains a human-readable textual description of this definition. > > The text is provided in a language (or languages) chosen by the > > module developer; for the sake of interoperability, it is RECOMMENDE= D > > to choose a language that is widely understood among the community o= f > > network administrators who will use the module. > > > > A textual description for humans. A docstring. I don't see semantics > > being mentioned anywhere, so where is all this coming from? > > Seriously? Perhaps we have a different understanding of the word > 'semantics'. Anyway, description statements (or DESCRIPTION clauses > back in SMIv2) have always been used to provide semantics that are not > expressable in machine readable form. > > Example: The ietf-yang-types:counter32 definition defines a counter > type because of the text in the description statement. I would say > there is lots of semantics in the description statement. Without > the description statement, the ietf-yang-types:counter32 would not > at all be a counter. > > I am absolutely surprised lately how little we seem to have a common > understanding about basic YANG concepts. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c353e814cee6051c19be05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The YANG RFC should be very clear t= hat description-stmt
is normative text.=C2=A0 Consider the <lo= ck> operation that says
a lock is not granted if one is alread= y held.=C2=A0 This is clearly normative
text that cannot be expre= ssed in YANG constraints.


Andy


On Thu, Jul 30, 2015 at 4:38 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jul 30, 2015 at 01:31:01PM +0200, Jernej Tu= ljak wrote:
> Ladislav Lhotka je 30.7.2015 ob 11:30 napisal:
> >>On 30 Jul 2015, at 01:12, Andy Bierman <andy@yumaworks.com> wrote:
> >>
> >>
> >>
> >>On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>Andy Bierman <andy@yu= maworks.com> wrote:
> >>>Hi,
> >>>
> >>>I understand the intent is that an implementation of NACM<= br> > >>>has to understand these NACM extensions.=C2=A0 I agree wit= h Lada
> >>>that the YANG text about MAY ignore extensions casts doubt= whether
> >>>this sort of NACM rule is enforceable or specified correct= ly.
> >>So do you agree that it would be a good idea to clarify this > >>according to Juergen's suggestion?
> >>
> >>
> >>
> >>Not really.
> >>Pretending the extension is just another description-stmt
> >>does not really fix anything.
> >In fact, generic tools like pyang ignore what=E2=80=99s written in= descriptions.
>
> Where does RFC6020 say that description-stmt may be used for defining<= br> > additional semantics? The only instance where I can find "descrip= tion"
> and "semantics" or "meaning" in the same sentence,= is in the section
> that describes module updates. This is what a YANG description is:
>
>=C2=A0 =C2=A0 The "description" statement takes as an argumen= t a string that
>=C2=A0 =C2=A0 contains a human-readable textual description of this def= inition.
>=C2=A0 =C2=A0 The text is provided in a language (or languages) chosen = by the
>=C2=A0 =C2=A0 module developer; for the sake of interoperability, it is= RECOMMENDED
>=C2=A0 =C2=A0 to choose a language that is widely understood among the = community of
>=C2=A0 =C2=A0 network administrators who will use the module.
>
> A textual description for humans. A docstring. I don't see semanti= cs
> being mentioned anywhere, so where is all this coming from?

Seriously? Perhaps we have a different understanding of the word
'semantics'. Anyway, description statements (or DESCRIPTION clauses=
back in SMIv2) have always been used to provide semantics that are not
expressable in machine readable form.

Example: The ietf-yang-types:counter32 definition defines a counter
type because of the text in the description statement. I would say
there is lots of semantics in the description statement. Without
the description statement, the ietf-yang-types:counter32 would not
at all be a counter.

I am absolutely surprised lately how little we seem to have a common
understanding about basic YANG concepts.

/js

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

--001a11c353e814cee6051c19be05-- From nobody Thu Jul 30 10:06:22 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 B5FC91B2EB6 for ; Thu, 30 Jul 2015 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 2fqU38h6obeM for ; Thu, 30 Jul 2015 10:06:18 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 C97061B2E8C for ; Thu, 30 Jul 2015 10:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1438275934; bh=YBy2sp6qN87IUSa+BmaOfczB0eOavEW/kcCp/pyuPUs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Wg1msP0NKnJ+5TnuLUEdQF+KqG1+9sgARYVx0+UJwTWOK2jQTfAl50JMdHXy4NuUI z39RRw+SdLOwri14SYJdkedRllFOxGmeecrlydPreHAW1yQjHrDCic0e4g8SUg1G6f yuTKg48zVW8NFUzoo1e4BvQN/itZm1aGfmZ3o6po= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=75.104.69.165; Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Nadeau Thomas In-Reply-To: <20150730155434.GA17437@elstar.local> Date: Thu, 30 Jul 2015 13:06:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DBC3FDAC14BE441AED9C5939C7775858F25EE4D@US70TWXCHMBA12.zam.alcatel-lucent.com> <20150730155434.GA17437@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2102) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=75.104.69.165 X-IP-stats: Notspam Incoming Last 0, First 0, in=3, out=0, spam=0 Known=true ip=75.104.69.165 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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, 30 Jul 2015 17:06:20 -0000 Isn=92t this 2015? *) =97Tom > On Jul 30, 2015:11:54 AM, at 11:54 AM, Juergen Schoenwaelder = wrote: >=20 > Hi all, >=20 > is it possible to use/configure an email quoting style that works with > text-only email readers? I know, it is old fashioned, but I do read > all my email in a terminal window... >=20 > Thanks, >=20 > /js >=20 > On Thu, Jul 30, 2015 at 03:26:53PM +0000, Lam, Hing-Kam (Kam) wrote: >> Hi, >>=20 >> Additional responses inline below. >>=20 >> Regards, >> Kam >>=20 >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of = B.Zeuner@telekom.de >> Sent: Thursday, July 30, 2015 10:44 AM >> To: netmod@ietf.org >> Subject: Re: [netmod] Mail regarding = draft-mansfield-netmod-uml-to-yang >>=20 >> Hallo, >>=20 >> Thanks for sharing your questions and comments; some initial = responses are provided below in line. >> Note that we have made some further progress that we plan to reflect = in an update of this draft which of course will take into account the = netmod discussions and input including this e-mail thread. >>=20 >> Regards >> Bernd >> Deutsche Telekom AG >> Europe & Technology >> Standardization Services >> Bernd Zeuner >> Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Germany >> +49 6151 58-12086 (phone) >> E-Mail: b.zeuner@telekom.de >> www.telekom.com >> Life is for sharing. >> Deutsche Telekom AG >> Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) >> Board of Management: Timotheus H=F6ttges (Chairman), >> Reinhard Clemens, Niek Jan van Damme, >> Thomas Dannenfeldt, Dr. Thomas Kremer, Claudia Nemat >> Commercial register: Amtsgericht Bonn HRB 6794 >> Registered office: Bonn, Germany >> VAT identification no. DE 123475223 >> Big changes start small - conserve resources by not printing every = e-mail. >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ari Sodhi >> Sent: Wednesday, July 29, 2015 6:44 PM >> To: netmod@ietf.org >> Subject: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang >>=20 >> There are some interesting ideas proposed. Here are some initial = questions and somewhat random comments based on a quick read of = draft-mansfield-netmod-uml-to-yang-00. >>=20 >> General questions on draft-mansfield-netmod-uml-to-yang: >>=20 >> 1. Is the proposed mapping supposed to be bi-directional in nature? = In other words, is the intent to support a mapping between UML and YANG = that enables IM UML -> DM YANG -> IM UML in a round trip manner. = [Bernd] The intent was UML -> YANG; but YANG -> UML is also possible. = The rationale of UML --> YANG being the intent is that we start = with protocol-neutral modeling using UML first. The I-D = draft-betts-netmod-framework-data-schema-uml contains more details of = this approach. Now given so many YANG drafts have been created, in some = cases it might be helpful to revert (YANG --> UML) engineer the YANG = drafts to UML so that comparison/analysis can be made. The text = in this section uses the term predictable. Should it not be = deterministic?[Bernd] Yes, agreed. >> 2. Does there need to be a set of UML usages defined - similar to = what ONF did? The referenced ONF TR-514 UML guidelines, which is = publicly available, described the usages. Some of the UML = concepts such as aggregation usually need definition as even the OMG UML = 2.5 spec says aggregation is open to some interpretation. This is = touched on in section 5.5 of draft-mansfield-netmod-uml-to-yang but it = seems ambiguous as both composition and aggregation map to container. = The examples are not so clear - the first seems more like composition to = me as there is a lifecycle implication between instances of ClassA and = ClassB. The second example - the list could also be a set of leafref to = the ClassD key. >> [Bernd] You are right. Some statements (to be verified): >>=20 >> =B7 UML composition association is mapped to container/list = within a container/list; the reference is "passed by value" >>=20 >> =B7 UML aggregation association is mapped to a leafref within = a container/list; the reference is "passed by reference". >>=20 >> 1. Did the authors consider the use of UML stereotypes/annotations = to help support the mapping between UML and YANG? This may help remove = potential ambiguity in the mapping. [Bernd] We did not add YANG specific = UML stereotypes because the intent was that the UML be agnostic to any = data schema (DM). Hi Ari, I am not sure I understand your question = correctly? Do you mean applying the lifecycle stereotypes to qualify = the status of the mapping rules? I.e., some of the mapping rules may be = preliminary at the moment, etc.?. >>=20 >> comments on draft-mansfield-netmod-uml-to-yang: >>=20 >> 1. Section 3 - What about UML packages and module/submodule = relationship. Modules can be a root package with submodules being = sub-packages.Need to enforce the semantics of include/import per RFC = 6020. Any value in considering relating YANG features to packages - ie. = Represent yang Feature statements >> [Bernd] The mapping of UML packages to YANG modules/submodules is an = identified open issue which is under discussion. You raise some good = points to consider. >>=20 >> 1. Section 5.2 - UML abstract is stated to map to a container. = Containers either represent containment for organization reasons or with = presence the container itself is configuration data. I do not get the = mapping of abstract to this. Can you explain? >> [Bernd] The current thinking is to map abstract superclasses to = "grouping" statements. This allows also to map multiple inheritance. = Note: This is also the mapping that we have used for the Link object = class in draft-lam-teas-usage-info-model-net-topology-01. >>=20 >> 1. Section 5.2 - both support and condition map to "if-feature" = statement in yang. This seems ambiguous. How does one distinguish in = YANG which is which? >> [Bernd] Support and condition belong together. If the "support" is = conditional, then the "condition" explains the conditions under which = the class has to be supported. >>=20 >> 1. Section 5.2 - "must" statement - could this not map to OCL? >> [Bernd] Good idea; we are still discussing this point as a general = place for mapping UML constraints. YANG seems to have here constraints = between attribute values in mind. >>=20 >> 1. Section 5.2 - wrt = objectCreationNotfication/objectDeletionNotification - in UML how are = these represented -seems to rely on ONF OpenModelCass if I understand = the source correctly? [Bernd] Yes, you are right. This is an additional = class property defined in the OpenModel profile. It defines that a = notification has to be sent when an instance of this class is = instantiated or deleted. It seems like there are some assumptions wrt to = the Object Class. In YANG can these map to notification statements. = [Bernd] Meanwhile we have mapped this to the "notification" statement = which goes beyond the simple "a notification has to be sent". Is there = some notification hierarchy in YANG/UML where these notifications = (objectCreationNotificaiton/objectDeletionNotification) exist? [Bernd] = Not now; but will be in the future. More current drafts of RFC 6020 = (I.e. draft-ietf-netmod-rfc6020bis-06) propose notifications to be top = level of a module or associated with data nodes (container or list data = nodes). This notion could be leveraged as the source of the = notification in YANG - xpath to its source in containment model. >> 2. Section 5.4.4 - a complex data type does not always map to = grouping IMO except if the grouping has a singular top level container. = A grouping is a reusable construct that gets "flattened out" in the = context they are used within. Groupings can also be refined/augmented to = tailor their usage contextually. >> [Bernd] We define complex data types in a separate UML package = (TypeDefinitions). They can always be reused as the type of class = attributes or operation parameters. >>=20 >> 1. Section 5.5 -The mapping is ambiguous as stated above. = composition is a stronger type of association then aggregation and = infers ownership of lifecycle of the contained items. That is when the = composing instance is destroyed, the contained items are also destroyed. = Its a is a part of relationship. Aggregation can be used to mean a point = of control for manipulating the contained. It does not infer lifecycle = control. >> [Bernd] That's completely true. See our answer to General::2. >>=20 >> 1. Section 5.5 - Its not clear how cleanly augment maps to = inheritance. Augment can apply to many things in YANG - container, list, = leaf-list, uses, choice .... I can kind of see augment of a container = mapping to inheritance. Augments can also specify conditions as to when = they apply - i.e. If if type =3D=3D ethernetCsmacd >> [Bernd] True. In recent discussions we concluded that augment is more = appropriate for mapping to conditional composition then inheritance. We = see the "grouping" statement as the main mapping for inheritance. The = "extension" statement is no longer used here. >>=20 >> 1. Section 5.6 - I don't see how UML interface maps to a container. = A UML interface represents a contract. A container either represents = containment for organization reasons or with presence the container = itself is configuration data. This may need more discussion - or at = least more explanation. >> [Bernd] We use the UML Interface artifact as a grouping of = operations. A container can be used to group actions. >> [cid:image001.png@01D0CA3E.1F2ED390] >>=20 >>=20 >> 1. Section 5.11 - what does package map to? Is it module/submodule? = [Bernd] Regarding the mapping of packages see our answer to Comments::1 = above. Could a conditional package not also map to module/submodule with = if-feature as a top-level entity?[Bernd] That's possible but we see the = conditional Pacs closer to the object class. They provide the attributes = for an object class on a conditional basis. This pattern is used e.g., = to enhance a technology agnostic object class with technology specific = attributes. >>=20 >>=20 >>=20 >> Ari Mark Sodhi >> System Engineer and Architect II >> T 707.766.3413 >> M 707.775.1379 >> E asodhi@calix.com >>=20 >> Calix >> 1035 N. McDowell Boulevard >> Petaluma, CA 94954 >> T 707.766.3000 >> F 707.283.3100 >>=20 >>=20 >>=20 >=20 >=20 >=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jul 30 10:21:41 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 9A4571ACD03 for ; Thu, 30 Jul 2015 10:21:40 -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 8FYT4viaY8GW for ; Thu, 30 Jul 2015 10:21:37 -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 603841ACCFE for ; Thu, 30 Jul 2015 10:21:37 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 016E6E73D69B0; Thu, 30 Jul 2015 17:21:30 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t6UHLRL7009203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 17:21:33 GMT Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.242]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 13:21:27 -0400 From: "Lam, Hing-Kam (Kam)" To: "B.Zeuner@telekom.de" , "netmod@ietf.org" Thread-Topic: Mail regarding draft-mansfield-netmod-uml-to-yang Thread-Index: AQHQyh22Uqyd0J/A30GczhkujIMBLp3ytUsAgAFotuCAAB+HsA== Date: Thu, 30 Jul 2015 17:21:25 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C7775858F25F19A@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <8DBC3FDAC14BE441AED9C5939C7775858F25EE4D@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: <8DBC3FDAC14BE441AED9C5939C7775858F25EE4D@US70TWXCHMBA12.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Mail regarding draft-mansfield-netmod-uml-to-yang 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, 30 Jul 2015 17:21:40 -0000 T2theS4gUmVmb3JtYXR0ZWQgaW50byBwbGFpbiB0ZXh0IG9ubHksIGluY2x1ZGluZyB0aGUgb3Jp Z2luYWwgZW1haWxzIGZyb20gQXJpIGFuZCBCZXJuZC4gU2VlIGJlbG93LiBCZXR0ZXI/IDotKQ0K DQpSZWdhcmRzLA0KS2FtDQoNCkZyb206IExhbSwgSGluZy1LYW0gKEthbSkgDQpTZW50OiBUaHVy c2RheSwgSnVseSAzMCwgMjAxNSAxMToyNyBBTQ0KVG86IEIuWmV1bmVyQHRlbGVrb20uZGU7IG5l dG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LW1hbnNmaWVs ZC1uZXRtb2QtdW1sLXRvLXlhbmcNCg0KSGksDQoNCkFkZGl0aW9uYWwgcmVzcG9uc2VzIGlubGlu ZSBiZWxvdy4NCg0KUmVnYXJkcywNCkthbQ0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEIuWmV1bmVyQHRlbGVrb20uZGUNClNlbnQ6 IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDEwOjQ0IEFNDQpUbzogbmV0bW9kQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW25ldG1vZF0gTWFpbCByZWdhcmRpbmcgZHJhZnQtbWFuc2ZpZWxkLW5ldG1v ZC11bWwtdG8teWFuZw0KDQpIYWxsbywNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgcXVlc3Rp b25zIGFuZCBjb21tZW50czsgc29tZSBpbml0aWFsIHJlc3BvbnNlcyBhcmUgcHJvdmlkZWQgYmVs b3cgaW4gbGluZS4NCk5vdGUgdGhhdCB3ZSBoYXZlIG1hZGUgc29tZSBmdXJ0aGVyIHByb2dyZXNz IHRoYXQgd2UgcGxhbiB0byByZWZsZWN0IGluIGFuIHVwZGF0ZSBvZiB0aGlzIGRyYWZ0IHdoaWNo IG9mIGNvdXJzZSB3aWxsIHRha2UgaW50byBhY2NvdW50IHRoZSBuZXRtb2QgZGlzY3Vzc2lvbnMg YW5kIGlucHV0IGluY2x1ZGluZyDCoHRoaXMgZS1tYWlsIHRocmVhZC4NCg0KUmVnYXJkcw0KQmVy bmQNCkRldXRzY2hlIFRlbGVrb20gQUcNCkV1cm9wZSAmIFRlY2hub2xvZ3kNClN0YW5kYXJkaXph dGlvbiBTZXJ2aWNlcw0KQmVybmQgWmV1bmVyDQpIZWlucmljaC1IZXJ0ei1TdHIuIDMtNywgNjQy OTUgRGFybXN0YWR0LCBHZXJtYW55DQorNDkgNjE1MSA1OC0xMjA4NiAocGhvbmUpDQpFLU1haWw6 IGIuemV1bmVyQHRlbGVrb20uZGUNCnd3dy50ZWxla29tLmNvbQ0KTGlmZSBpcyBmb3Igc2hhcmlu Zy4NCkRldXRzY2hlIFRlbGVrb20gQUcNClN1cGVydmlzb3J5IEJvYXJkOiBQcm9mLiBEci4gVWxy aWNoIExlaG5lciAoQ2hhaXJtYW4pIA0KQm9hcmQgb2YgTWFuYWdlbWVudDogVGltb3RoZXVzIEjD tnR0Z2VzIChDaGFpcm1hbiksDQpSZWluaGFyZCBDbGVtZW5zLCBOaWVrIEphbiB2YW4gRGFtbWUs DQpUaG9tYXMgRGFubmVuZmVsZHQsIERyLiBUaG9tYXMgS3JlbWVyLCBDbGF1ZGlhIE5lbWF0DQpD b21tZXJjaWFsIHJlZ2lzdGVyOiBBbXRzZ2VyaWNodCBCb25uIEhSQiA2Nzk0DQpSZWdpc3RlcmVk IG9mZmljZTogQm9ubiwgR2VybWFueQ0KVkFUIGlkZW50aWZpY2F0aW9uIG5vLiBERSAxMjM0NzUy MjMNCkJpZyBjaGFuZ2VzIHN0YXJ0IHNtYWxsIOKAkyBjb25zZXJ2ZSByZXNvdXJjZXMgYnkgbm90 IHByaW50aW5nIGV2ZXJ5IGUtbWFpbC4NCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXJpIFNvZGhpDQpTZW50OiBXZWRuZXNkYXksIEp1 bHkgMjksIDIwMTUgNjo0NCBQTQ0KVG86IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogW25ldG1v ZF0gTWFpbCByZWdhcmRpbmcgZHJhZnQtbWFuc2ZpZWxkLW5ldG1vZC11bWwtdG8teWFuZw0KDQpU aGVyZSBhcmUgc29tZSBpbnRlcmVzdGluZyBpZGVhcyBwcm9wb3NlZC4gSGVyZSBhcmUgc29tZSBp bml0aWFsIHF1ZXN0aW9ucyBhbmQgc29tZXdoYXQgcmFuZG9tIGNvbW1lbnRzIGJhc2VkIG9uIGEg cXVpY2sgcmVhZCBvZsKgZHJhZnQtbWFuc2ZpZWxkLW5ldG1vZC11bWwtdG8teWFuZy0wMC7CoA0K wqANCkdlbmVyYWwgcXVlc3Rpb25zIG9uwqBkcmFmdC1tYW5zZmllbGQtbmV0bW9kLXVtbC10by15 YW5nOg0KDQoxLiBJcyB0aGUgcHJvcG9zZWQgbWFwcGluZyBzdXBwb3NlZCB0byBiZSBiaS1kaXJl Y3Rpb25hbCBpbiBuYXR1cmU/IEluIG90aGVyIHdvcmRzLCBpcyB0aGUgaW50ZW50IHRvIHN1cHBv cnQgYSBtYXBwaW5nIGJldHdlZW4gVU1MIGFuZCBZQU5HIHRoYXQgZW5hYmxlcyBJTSBVTUwgLT4g RE0gWUFORyAtPiBJTSBVTUwgaW4gYSByb3VuZCB0cmlwIG1hbm5lci4gDQrCoA0KW0Jlcm5kXSBU aGUgaW50ZW50IHdhcyBVTUwgLT4gWUFORzsgYnV0IFlBTkcgLT4gVU1MIGlzIGFsc28gcG9zc2li bGUuIA0KDQo8S2FtPiBUaGUgcmF0aW9uYWxlIG9mIFVNTCDihpIgWUFORyBiZWluZyB0aGUgaW50 ZW50IGlzIHRoYXQgd2Ugc3RhcnQgd2l0aCBwcm90b2NvbC1uZXV0cmFsIG1vZGVsaW5nIHVzaW5n IFVNTCBmaXJzdC4gVGhlIEktRCBkcmFmdC1iZXR0cy1uZXRtb2QtZnJhbWV3b3JrLWRhdGEtc2No ZW1hLXVtbCBjb250YWlucyBtb3JlIGRldGFpbHMgb2YgdGhpcyBhcHByb2FjaC4gTm93IGdpdmVu IHNvIG1hbnkgWUFORyBkcmFmdHMgaGF2ZSBiZWVuIGNyZWF0ZWQsIGluIHNvbWUgY2FzZXMgaXQg bWlnaHQgYmUgaGVscGZ1bCB0byByZXZlcnQgKFlBTkcg4oaSIFVNTCkgZW5naW5lZXIgdGhlIFlB TkcgZHJhZnRzIHRvIFVNTCBzbyB0aGF0IGNvbXBhcmlzb24vYW5hbHlzaXMgY2FuIGJlIG1hZGUu IMKgPC9LYW0+IA0KDQpUaGUgdGV4dCBpbiB0aGlzIHNlY3Rpb24gdXNlcyB0aGUgdGVybSBwcmVk aWN0YWJsZS4gU2hvdWxkIGl0IG5vdCBiZSBkZXRlcm1pbmlzdGljPw0KDQpbQmVybmRdIFllcywg YWdyZWVkLg0KDQoyLiBEb2VzIHRoZXJlIG5lZWQgdG8gYmUgYSBzZXQgb2YgVU1MIHVzYWdlcyBk ZWZpbmVkIOKAkyBzaW1pbGFyIHRvIHdoYXQgT05GIGRpZD8gDQoNCjxLYW0+IFRoZSByZWZlcmVu Y2VkIE9ORiBUUi01MTQgVU1MIGd1aWRlbGluZXMsIHdoaWNoIGlzIHB1YmxpY2x5IGF2YWlsYWJs ZSwgZGVzY3JpYmVkIHRoZSB1c2FnZXMuIDwvS2FtPiANCg0KU29tZSBvZiB0aGUgVU1MIGNvbmNl cHRzIHN1Y2ggYXMgYWdncmVnYXRpb24gdXN1YWxseSBuZWVkIGRlZmluaXRpb24gYXMgZXZlbiB0 aGUgT01HIFVNTCAyLjUgc3BlYyBzYXlzIGFnZ3JlZ2F0aW9uIGlzIG9wZW4gdG8gc29tZSBpbnRl cnByZXRhdGlvbi4gVGhpcyBpcyB0b3VjaGVkIG9uIGluIHNlY3Rpb24gNS41IG9mwqBkcmFmdC1t YW5zZmllbGQtbmV0bW9kLXVtbC10by15YW5nIGJ1dCBpdCBzZWVtcyBhbWJpZ3VvdXMgYXMgYm90 aCBjb21wb3NpdGlvbiBhbmQgYWdncmVnYXRpb24gbWFwIHRvIGNvbnRhaW5lci4gVGhlIGV4YW1w bGVzIGFyZSBub3Qgc28gY2xlYXIg4oCTIHRoZSBmaXJzdCBzZWVtcyBtb3JlIGxpa2UgY29tcG9z aXRpb24gdG8gbWUgYXMgdGhlcmUgaXMgYSBsaWZlY3ljbGUgaW1wbGljYXRpb24gYmV0d2VlbiBp bnN0YW5jZXMgb2YgQ2xhc3NBIGFuZCBDbGFzc0IuIFRoZSBzZWNvbmQgZXhhbXBsZSDigJMgdGhl IGxpc3QgY291bGQgYWxzbyBiZSBhIHNldCBvZiBsZWFmcmVmIHRvIHRoZSBDbGFzc0Qga2V5Lg0K DQpbQmVybmRdIFlvdSBhcmUgcmlnaHQuIFNvbWUgc3RhdGVtZW50cyAodG8gYmUgdmVyaWZpZWQp Og0K4oCiIFVNTCBjb21wb3NpdGlvbiBhc3NvY2lhdGlvbiBpcyBtYXBwZWQgdG8gY29udGFpbmVy L2xpc3Qgd2l0aGluIGEgY29udGFpbmVyL2xpc3Q7IHRoZSByZWZlcmVuY2UgaXMg4oCccGFzc2Vk IGJ5IHZhbHVl4oCdDQrigKIgVU1MIGFnZ3JlZ2F0aW9uIGFzc29jaWF0aW9uIGlzIG1hcHBlZCB0 byBhIGxlYWZyZWYgd2l0aGluIGEgY29udGFpbmVyL2xpc3Q7IHRoZSByZWZlcmVuY2UgaXMg4oCc cGFzc2VkIGJ5IHJlZmVyZW5jZeKAnS4NCg0KMy4gRGlkIHRoZSBhdXRob3JzIGNvbnNpZGVyIHRo ZSB1c2Ugb2YgVU1MIHN0ZXJlb3R5cGVzL2Fubm90YXRpb25zIHRvIGhlbHAgc3VwcG9ydCB0aGUg bWFwcGluZyBiZXR3ZWVuIFVNTCBhbmQgWUFORz8gVGhpcyBtYXkgaGVscCByZW1vdmXCoHBvdGVu dGlhbMKgYW1iaWd1aXR5IGluIHRoZSBtYXBwaW5nLsKgDQoNCltCZXJuZF0gV2UgZGlkIG5vdCBh ZGQgWUFORyBzcGVjaWZpYyBVTUwgc3RlcmVvdHlwZXMgYmVjYXVzZSB0aGUgaW50ZW50IHdhcyB0 aGF0IHRoZSBVTUwgYmUgYWdub3N0aWMgdG8gYW55IGRhdGEgc2NoZW1hIChETSkuIA0KDQo8S2Ft PiBIaSBBcmksIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gY29ycmVj dGx5PyBEbyB5b3UgbWVhbiBhcHBseWluZyB0aGUgbGlmZWN5Y2xlIHN0ZXJlb3R5cGVzwqAgdG8g cXVhbGlmeSB0aGUgc3RhdHVzIG9mIHRoZSBtYXBwaW5nIHJ1bGVzPyBJLmUuLCBzb21lIG9mIHRo ZSBtYXBwaW5nIHJ1bGVzIG1heSBiZSBwcmVsaW1pbmFyeSBhdCB0aGUgbW9tZW50LCBldGMuPy4g PC9LYW0+DQoNCmNvbW1lbnRzIG9uIGRyYWZ0LW1hbnNmaWVsZC1uZXRtb2QtdW1sLXRvLXlhbmc6 DQoNCjEuIFNlY3Rpb24gMyAtIFdoYXQgYWJvdXQgVU1MIHBhY2thZ2VzIGFuZCBtb2R1bGUvc3Vi bW9kdWxlIHJlbGF0aW9uc2hpcC4gTW9kdWxlcyBjYW4gYmUgYSByb290IHBhY2thZ2Ugd2l0aCBz dWJtb2R1bGVzIGJlaW5nIHN1Yi1wYWNrYWdlcy5OZWVkIHRvIGVuZm9yY2UgdGhlIHNlbWFudGlj cyBvZiBpbmNsdWRlL2ltcG9ydCBwZXIgUkZDIDYwMjAuIEFueSB2YWx1ZSBpbiBjb25zaWRlcmlu ZyByZWxhdGluZyBZQU5HIGZlYXR1cmVzIHRvIHBhY2thZ2VzwqDigJPCoGllLsKgUmVwcmVzZW50 IHlhbmcgRmVhdHVyZSBzdGF0ZW1lbnRzDQoNCltCZXJuZF0gVGhlIG1hcHBpbmcgb2YgVU1MIHBh Y2thZ2VzIHRvIFlBTkcgbW9kdWxlcy9zdWJtb2R1bGVzIGlzIGFuIGlkZW50aWZpZWQgb3BlbiBp c3N1ZSB3aGljaCBpcyB1bmRlciBkaXNjdXNzaW9uLiBZb3UgcmFpc2Ugc29tZSBnb29kIHBvaW50 cyB0byBjb25zaWRlci4NCg0KMi4gU2VjdGlvbiA1LjIgLSBVTUwgYWJzdHJhY3QgaXMgc3RhdGVk IHRvIG1hcCB0byBhIGNvbnRhaW5lci4gQ29udGFpbmVycyBlaXRoZXIgcmVwcmVzZW50IGNvbnRh aW5tZW50IGZvciBvcmdhbml6YXRpb24gcmVhc29ucyBvciB3aXRoIHByZXNlbmNlIHRoZSBjb250 YWluZXIgaXRzZWxmIGlzIGNvbmZpZ3VyYXRpb24gZGF0YS4gSSBkbyBub3QgZ2V0IHRoZSBtYXBw aW5nIG9mIGFic3RyYWN0IHRvIHRoaXMuIENhbiB5b3UgZXhwbGFpbj8NCg0KW0Jlcm5kXSBUaGUg Y3VycmVudCB0aGlua2luZyBpcyB0byBtYXAgYWJzdHJhY3Qgc3VwZXJjbGFzc2VzIHRvIOKAnGdy b3VwaW5n4oCdIHN0YXRlbWVudHMuIFRoaXMgYWxsb3dzIGFsc28gdG8gbWFwIG11bHRpcGxlIGlu aGVyaXRhbmNlLiBOb3RlOiBUaGlzIGlzIGFsc28gdGhlIG1hcHBpbmcgdGhhdCB3ZSBoYXZlIHVz ZWQgZm9yIHRoZSBMaW5rIG9iamVjdCBjbGFzcyBpbiBkcmFmdC1sYW0tdGVhcy11c2FnZS1pbmZv LW1vZGVsLW5ldC10b3BvbG9neS0wMS4NCg0KMy4gU2VjdGlvbiA1LjIg4oCTIGJvdGggc3VwcG9y dCBhbmQgY29uZGl0aW9uIG1hcCB0byDigJxpZi1mZWF0dXJl4oCdIHN0YXRlbWVudCBpbiB5YW5n LiBUaGlzIHNlZW1zIGFtYmlndW91cy4gSG93IGRvZXMgb25lIGRpc3Rpbmd1aXNoIGluIFlBTkcg d2hpY2ggaXMgd2hpY2g/DQoNCltCZXJuZF0gU3VwcG9ydCBhbmQgY29uZGl0aW9uIGJlbG9uZyB0 b2dldGhlci4gSWYgdGhlIOKAnHN1cHBvcnTigJ0gaXMgY29uZGl0aW9uYWwsIHRoZW4gdGhlIOKA nGNvbmRpdGlvbuKAnSBleHBsYWlucyB0aGUgY29uZGl0aW9ucyB1bmRlciB3aGljaCB0aGUgY2xh c3MgaGFzIHRvIGJlIHN1cHBvcnRlZC4gDQoNCjQuIFNlY3Rpb24gNS4yIC0g4oCcbXVzdOKAnSBz dGF0ZW1lbnQg4oCTIGNvdWxkIHRoaXMgbm90IG1hcCB0byBPQ0w/DQoNCltCZXJuZF0gR29vZCBp ZGVhOyB3ZSBhcmUgc3RpbGwgZGlzY3Vzc2luZyB0aGlzIHBvaW50IGFzIGEgZ2VuZXJhbCBwbGFj ZSBmb3IgbWFwcGluZyBVTUwgY29uc3RyYWludHMuIFlBTkcgc2VlbXMgdG8gaGF2ZSBoZXJlIGNv bnN0cmFpbnRzIGJldHdlZW4gYXR0cmlidXRlIHZhbHVlcyBpbiBtaW5kLg0KDQo1LiBTZWN0aW9u IDUuMiDigJMgd3J0IG9iamVjdENyZWF0aW9uTm90ZmljYXRpb24vb2JqZWN0RGVsZXRpb25Ob3Rp ZmljYXRpb24g4oCTIGluIFVNTCBob3cgYXJlIHRoZXNlIHJlcHJlc2VudGVkIC1zZWVtcyB0byBy ZWx5IG9uIE9ORiBPcGVuTW9kZWxDYXNzIGlmwqBJIHVuZGVyc3RhbmQgdGhlIHNvdXJjZSBjb3Jy ZWN0bHk/IA0KDQpbQmVybmRdIFllcywgeW91IGFyZSByaWdodC4gVGhpcyBpcyBhbiBhZGRpdGlv bmFsIGNsYXNzIHByb3BlcnR5IGRlZmluZWQgaW4gdGhlIE9wZW5Nb2RlbCBwcm9maWxlLiBJdCBk ZWZpbmVzIHRoYXQgYSBub3RpZmljYXRpb24gaGFzIHRvIGJlIHNlbnQgd2hlbiBhbiBpbnN0YW5j ZSBvZiB0aGlzIGNsYXNzIGlzIGluc3RhbnRpYXRlZCBvciBkZWxldGVkLiANCg0KSXQgc2VlbXMg bGlrZSB0aGVyZSBhcmUgc29tZSBhc3N1bXB0aW9ucyB3cnQgdG8gdGhlIE9iamVjdCBDbGFzcy4g SW4gWUFORyBjYW4gdGhlc2UgbWFwIHRvIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnRzLiANCg0KW0Jl cm5kXSBNZWFud2hpbGUgd2UgaGF2ZSBtYXBwZWQgdGhpcyB0byB0aGUg4oCcbm90aWZpY2F0aW9u 4oCdIHN0YXRlbWVudCB3aGljaCBnb2VzIGJleW9uZCB0aGUgc2ltcGxlIOKAnGEgbm90aWZpY2F0 aW9uIGhhcyB0byBiZSBzZW504oCdLiANCg0KSXMgdGhlcmUgc29tZSBub3RpZmljYXRpb24gaGll cmFyY2h5IGluIFlBTkcvVU1MIHdoZXJlIHRoZXNlIG5vdGlmaWNhdGlvbnMgKG9iamVjdENyZWF0 aW9uTm90aWZpY2FpdG9uL29iamVjdERlbGV0aW9uTm90aWZpY2F0aW9uKSBleGlzdD8gDQoNCltC ZXJuZF0gTm90IG5vdzsgYnV0IHdpbGwgYmUgaW4gdGhlIGZ1dHVyZS4gDQoNCk1vcmUgY3VycmVu dCBkcmFmdHMgb2YgUkZDIDYwMjAgKEkuZS4gZHJhZnQtaWV0Zi1uZXRtb2TigJNyZmM2MDIwYmlz 4oCTMDYpIHByb3Bvc2Ugbm90aWZpY2F0aW9ucyB0byBiZSB0b3AgbGV2ZWwgb2YgYSBtb2R1bGUg b3IgYXNzb2NpYXRlZCB3aXRoIGRhdGEgbm9kZXMgKGNvbnRhaW5lciBvciBsaXN0IGRhdGEgbm9k ZXMpLiDCoCBUaGlzIG5vdGlvbiBjb3VsZCBiZSBsZXZlcmFnZWQgYXMgdGhlIHNvdXJjZSBvZiB0 aGUgbm90aWZpY2F0aW9uIGluIFlBTkcg4oCTIHhwYXRoIHRvIGl0cyBzb3VyY2UgaW4gY29udGFp bm1lbnQgbW9kZWwuwqANCg0KNi4gU2VjdGlvbiA1LjQuNCDigJMgYSBjb21wbGV4IGRhdGEgdHlw ZSBkb2VzIG5vdCBhbHdheXMgbWFwIHRvIGdyb3VwaW5nIElNTyBleGNlcHQgaWYgdGhlIGdyb3Vw aW5nIGhhcyBhIHNpbmd1bGFyIHRvcCBsZXZlbCBjb250YWluZXIuIEEgZ3JvdXBpbmcgaXMgYSBy ZXVzYWJsZSBjb25zdHJ1Y3QgdGhhdCBnZXRzICJmbGF0dGVuZWQgb3V0IiBpbiB0aGUgY29udGV4 dCB0aGV5IGFyZSB1c2VkIHdpdGhpbi4gR3JvdXBpbmdzIGNhbiBhbHNvIGJlIHJlZmluZWQvYXVn bWVudGVkIHRvIHRhaWxvciB0aGVpciB1c2FnZSBjb250ZXh0dWFsbHkuwqANCg0KW0Jlcm5kXSBX ZSBkZWZpbmUgY29tcGxleCBkYXRhIHR5cGVzIGluIGEgc2VwYXJhdGUgVU1MIHBhY2thZ2UgKFR5 cGVEZWZpbml0aW9ucykuIFRoZXkgY2FuIGFsd2F5cyBiZSByZXVzZWQgYXMgdGhlIHR5cGUgb2Yg Y2xhc3MgYXR0cmlidXRlcyBvciBvcGVyYXRpb24gcGFyYW1ldGVycy4NCg0KNy4gwqBTZWN0aW9u IDUuNSDigJNUaGUgbWFwcGluZyBpcyBhbWJpZ3VvdXMgYXMgc3RhdGVkIGFib3ZlLiDCoGNvbXBv c2l0aW9uIGlzIGEgc3Ryb25nZXIgdHlwZSBvZiBhc3NvY2lhdGlvbiB0aGVuIGFnZ3JlZ2F0aW9u IGFuZCBpbmZlcnMgb3duZXJzaGlwIG9mIGxpZmVjeWNsZSBvZiB0aGUgY29udGFpbmVkIGl0ZW1z LiBUaGF0IGlzIHdoZW4gdGhlIGNvbXBvc2luZyBpbnN0YW5jZSBpcyBkZXN0cm95ZWQsIHRoZSBj b250YWluZWQgaXRlbXMgYXJlIGFsc28gZGVzdHJveWVkLiBJdHMgYSBpcyBhIHBhcnQgb2YgcmVs YXRpb25zaGlwLiBBZ2dyZWdhdGlvbiBjYW4gYmUgdXNlZCB0byBtZWFuIGEgcG9pbnQgb2YgY29u dHJvbCBmb3IgbWFuaXB1bGF0aW5nIHRoZSBjb250YWluZWQuIMKgSXQgZG9lcyBub3QgaW5mZXIg bGlmZWN5Y2xlIGNvbnRyb2wuwqANCg0KW0Jlcm5kXSBUaGF04oCZcyBjb21wbGV0ZWx5IHRydWUu IFNlZSBvdXIgYW5zd2VyIHRvIEdlbmVyYWw6OjIuDQoNCjguIFNlY3Rpb24gNS41IC0gSXRzIG5v dCBjbGVhciBob3cgY2xlYW5seSBhdWdtZW50IG1hcHMgdG8gaW5oZXJpdGFuY2UuIEF1Z21lbnQg Y2FuIGFwcGx5IHRvIG1hbnkgdGhpbmdzIGluIFlBTkcgLSBjb250YWluZXIsIGxpc3QsIGxlYWYt bGlzdCwgdXNlcywgY2hvaWNlIOKApi4gSSBjYW4ga2luZCBvZiBzZWUgYXVnbWVudCBvZiBhIGNv bnRhaW5lciBtYXBwaW5nIHRvIGluaGVyaXRhbmNlLiBBdWdtZW50cyBjYW4gYWxzbyBzcGVjaWZ5 IGNvbmRpdGlvbnMgYXMgdG8gd2hlbiB0aGV5IGFwcGx5IC0gaS5lLiBJZiBpZiB0eXBlID09IGV0 aGVybmV0Q3NtYWNkDQoNCltCZXJuZF0gVHJ1ZS4gSW4gcmVjZW50IGRpc2N1c3Npb25zIHdlIGNv bmNsdWRlZCB0aGF0IGF1Z21lbnQgaXMgbW9yZSBhcHByb3ByaWF0ZSBmb3IgbWFwcGluZyB0byBj b25kaXRpb25hbCBjb21wb3NpdGlvbiB0aGVuIGluaGVyaXRhbmNlLiBXZSBzZWUgdGhlIOKAnmdy b3VwaW5n4oCdIHN0YXRlbWVudCBhcyB0aGUgbWFpbiBtYXBwaW5nIGZvciBpbmhlcml0YW5jZS4g VGhlIOKAnGV4dGVuc2lvbuKAnSBzdGF0ZW1lbnQgaXMgbm8gbG9uZ2VyIHVzZWQgaGVyZS4NCg0K OS4gU2VjdGlvbiA1LjYg4oCTIEkgZG9u4oCZdCBzZWUgaG93IFVNTCBpbnRlcmZhY2UgbWFwcyB0 byBhIGNvbnRhaW5lci4gQSBVTUwgaW50ZXJmYWNlIHJlcHJlc2VudHMgYSBjb250cmFjdC4gQSBj b250YWluZXIgZWl0aGVyIHJlcHJlc2VudHMgY29udGFpbm1lbnQgZm9yIG9yZ2FuaXphdGlvbiBy ZWFzb25zIG9yIHdpdGggcHJlc2VuY2UgdGhlIGNvbnRhaW5lciBpdHNlbGYgaXMgY29uZmlndXJh dGlvbiBkYXRhLiBUaGlzIG1heSBuZWVkIG1vcmUgZGlzY3Vzc2lvbiDigJMgb3IgYXQgbGVhc3Qg bW9yZSBleHBsYW5hdGlvbi4NCg0KW0Jlcm5kXSBXZSB1c2UgdGhlIFVNTCBJbnRlcmZhY2UgYXJ0 aWZhY3QgYXMgYSBncm91cGluZyBvZiBvcGVyYXRpb25zLiBBIGNvbnRhaW5lciBjYW4gYmUgdXNl ZCB0byBncm91cCBhY3Rpb25zLg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQp8ICAgICAgICAgICAgIDw8SW50ZXJmYWNlPj4gICAgICAgICAgICAgIHwNCnwgICAg ICAgICA8PG9wZW5Nb2RlbEludGVyZmFjZT4+ICAgICAgICAgfA0KfCAgICAgICAgICAgIDxJbnRl cmZhY2UgTmFtZT4gICAgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8ICogPDxvcGVuTW9k ZWxPcGVyYXRpb24+ICsgb3BlcmF0aW9uMSgpIHwNCnwgKiA8PG9wZW5Nb2RlbE9wZXJhdGlvbj4g KyBvcGVyYXRpb24yKCkgfA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQoNCsKgDQoxMC4gU2VjdGlvbiA1LjExIOKAkyB3aGF0IGRvZXMgcGFja2FnZSBtYXAgdG8/ IElzIGl0IG1vZHVsZS9zdWJtb2R1bGU/IA0KDQpbQmVybmRdIFJlZ2FyZGluZyB0aGUgbWFwcGlu ZyBvZiBwYWNrYWdlcyBzZWUgb3VyIGFuc3dlciB0byBDb21tZW50czo6MSBhYm92ZS4gDQoNCkNv dWxkIGEgY29uZGl0aW9uYWwgcGFja2FnZSBub3QgYWxzbyBtYXAgdG8gbW9kdWxlL3N1Ym1vZHVs ZSB3aXRoIGlmLWZlYXR1cmUgYXMgYSB0b3AtbGV2ZWwgZW50aXR5Pw0KDQpbQmVybmRdIFRoYXTi gJlzIHBvc3NpYmxlIGJ1dCB3ZSBzZWUgdGhlIGNvbmRpdGlvbmFsIFBhY3MgY2xvc2VyIHRvIHRo ZSBvYmplY3QgY2xhc3MuIFRoZXkgcHJvdmlkZSB0aGUgYXR0cmlidXRlcyBmb3IgYW4gb2JqZWN0 IGNsYXNzIG9uIGEgY29uZGl0aW9uYWwgYmFzaXMuIFRoaXMgcGF0dGVybiBpcyB1c2VkIGUuZy4s IHRvIGVuaGFuY2UgYSB0ZWNobm9sb2d5IGFnbm9zdGljIG9iamVjdCBjbGFzcyB3aXRoIHRlY2hu b2xvZ3kgc3BlY2lmaWMgYXR0cmlidXRlcy4NCg0KwqANCg0KQXJpIE1hcmsgU29kaGkNClN5c3Rl bSBFbmdpbmVlciBhbmQgQXJjaGl0ZWN0IElJDQpUwqA3MDcuNzY2LjM0MTMNCk3CoDcwNy43NzUu MTM3OQ0KRcKgYXNvZGhpQGNhbGl4LmNvbQ0KwqANCkNhbGl4DQoxMDM1IE4uIE1jRG93ZWxsIEJv dWxldmFyZA0KUGV0YWx1bWEsIENBIDk0OTU0DQpUwqA3MDcuNzY2LjMwMDANCkbCoDcwNy4yODMu MzEwMA0KwqANCg0K From nobody Thu Jul 30 10:41:53 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 46AE51ACE7B for ; Thu, 30 Jul 2015 10:41:52 -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 7UBytyj2lm5H for ; Thu, 30 Jul 2015 10:41:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F28031B2D35 for ; Thu, 30 Jul 2015 10:41:32 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id CC09D1AE046E; Thu, 30 Jul 2015 19:41:30 +0200 (CEST) Date: Thu, 30 Jul 2015 19:41:30 +0200 (CEST) Message-Id: <20150730.194130.1378875555824248389.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150729.195151.71742690632261308.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 17:41:52 -0000 Andy Bierman wrote: > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Hi, > > > > > > I understand the intent is that an implementation of NACM > > > has to understand these NACM extensions. I agree with Lada > > > that the YANG text about MAY ignore extensions casts doubt whether > > > this sort of NACM rule is enforceable or specified correctly. > > > > So do you agree that it would be a good idea to clarify this > > according to Juergen's suggestion? > > > > > > > Not really. > Pretending the extension is just another description-stmt > does not really fix anything. > > A real YANG statement like config-stmt or a new statement > called ephemeral-stmt can be modified with refine-stmt > or deviate-stmt. This can never happen for > an external statement. There are two separate issues here: 1) It seems we are in agreement that if a model uses an extension statement, it is normative (like ietf-system's usage of nacm:*). Should we somehow clarify this in 6020bis? 2) Extensions cannot be refined or deviated. Actually, the *syntax* rules allows things like: deviation /x:foo { deviate replace { i2rs:ephemeral true; } } I agree that it not clear what this means, but we could also clarify this in 6020bis. > IMO ephemeral data support needs to be a real statement > that can be used with refine-stmt and deviate-stmt. > It is a real property of a data node. Note: it is still not clear that such a statement (base or extension) is needed at all. /martin From nobody Thu Jul 30 10:58:40 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 3F76B1ACD54 for ; Thu, 30 Jul 2015 10:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 zllRG4tZQ2fM for ; Thu, 30 Jul 2015 10:58:37 -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 07E051ACD50 for ; Thu, 30 Jul 2015 10:58:37 -0700 (PDT) Received: by laah7 with SMTP id h7so29749084laa.0 for ; Thu, 30 Jul 2015 10:58:35 -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=KXA39UNTut7u5KTk1rXvo5RT03VxYzOhmkN7T5l/Ms8=; b=eWgyBnbgGfPxKzFihjvg+t76kyFyM6GfxcR/ZYnR4lcbBkjxwm3OgNYqlme8dNuw54 fvuWNqMbld8Uc+HWhHewMxOTSB6USPPgRYCgwMHQZhz7hXrAXfGrWZbYlvqTGJ6HSOxr 388t1WYWtJP5grtZQUnqO/dTZmRSFaODBXfUT1QXboLWjn2jCDKwmG8F8zbSOGLHtz4K jN92/vV8blhWgVcx2gxnKfWOlEcAXroIb/R7NInk7WZOFxlq3mmeP+65ovgU2F+deLM2 PNWYaKqI348fcm2kLAbrQo6nYVTeb4hu7eEoZcrOD0zuXu6Oap3I7jei7lNpKHUYGk// wRPQ== X-Gm-Message-State: ALoCoQnLCVEH2FtEh/cynCfgZDKUsaynT8k/JVVdOo/bH2fso9d9vqE13AuMgevHM33p8uQfVV/g MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr45231840laj.88.1438279115477; Thu, 30 Jul 2015 10:58:35 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Jul 2015 10:58:35 -0700 (PDT) In-Reply-To: <20150730.194130.1378875555824248389.mbj@tail-f.com> References: <20150729.195151.71742690632261308.mbj@tail-f.com> <20150730.194130.1378875555824248389.mbj@tail-f.com> Date: Thu, 30 Jul 2015 10:58:35 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158b5e4c42bfd051c1b7320 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 17:58:39 -0000 --089e0158b5e4c42bfd051c1b7320 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > I understand the intent is that an implementation of NACM > > > > has to understand these NACM extensions. I agree with Lada > > > > that the YANG text about MAY ignore extensions casts doubt whether > > > > this sort of NACM rule is enforceable or specified correctly. > > > > > > So do you agree that it would be a good idea to clarify this > > > according to Juergen's suggestion? > > > > > > > > > > > Not really. > > Pretending the extension is just another description-stmt > > does not really fix anything. > > > > A real YANG statement like config-stmt or a new statement > > called ephemeral-stmt can be modified with refine-stmt > > or deviate-stmt. This can never happen for > > an external statement. > > There are two separate issues here: > > 1) It seems we are in agreement that if a model uses an extension > statement, it is normative (like ietf-system's usage of nacm:*). > > Should we somehow clarify this in 6020bis? > > No -- I agree that was the intent, but it is not achievable because tools MAY ignore extensions. > 2) Extensions cannot be refined or deviated. > > Actually, the *syntax* rules allows things like: > > deviation /x:foo { > deviate replace { > i2rs:ephemeral true; > } > } > > I agree that it not clear what this means, but we could also > clarify this in 6020bis. > > > > IMO ephemeral data support needs to be a real statement > > that can be used with refine-stmt and deviate-stmt. > > It is a real property of a data node. > > Note: it is still not clear that such a statement (base or extension) > is needed at all. > > I do not understand why you are so opposed to using real YANG statements to support ephemeral state. Do you have a better solution that the proposal from draft-haas-i2rs-ephermal-state-reqs-00? I don't see it. I am opposed to using extensions to ephemeral state because they are poorly defined in YANG. This is OK since they are for defining statements outside the YANG standard. Normal mechanisms like uses/refine and deviate must be supported. I do see any advantages whatsoever for using external statements instead of YANG statements. > /martin > Andy --089e0158b5e4c42bfd051c1b7320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > Hi,
> > >
> > > I understand the intent is that an implementation of NACM > > > has to understand these NACM extensions.=C2=A0 I agree with = Lada
> > > that the YANG text about MAY ignore extensions casts doubt w= hether
> > > this sort of NACM rule is enforceable or specified correctly= .
> >
> > So do you agree that it would be a good idea to clarify this
> > according to Juergen's suggestion?
> >
> >
> >
> Not really.
> Pretending the extension is just another description-stmt
> does not really fix anything.
>
> A real YANG statement like config-stmt or a new statement
> called ephemeral-stmt can be modified with refine-stmt
> or deviate-stmt.=C2=A0 =C2=A0This can never happen for
> an external statement.

There are two separate issues here:

1) It seems we are in agreement that if a model uses an extension
=C2=A0 =C2=A0statement, it is normative (like ietf-system's usage of na= cm:*).

=C2=A0 =C2=A0Should we somehow clarify this in 6020bis?


No -- I agree that was the intent, but= it is not achievable
because tools MAY ignore extensions.
<= div>

=C2=A0



I do not understand why you are so op= posed to using real YANG statements
to support ephemeral state.= =C2=A0 Do you have a better solution that the
proposal from draft= -haas-i2rs-ephermal-state-reqs-00?=C2=A0 I don't see it.
I am= opposed to using extensions to ephemeral state because
they are = poorly defined in YANG.=C2=A0 This is OK since they are for
defin= ing statements outside the YANG standard.=C2=A0 Normal mechanisms
like uses/refine and deviate must be supported.

<= br>
I do see any advantages whatsoever for using external stateme= nts
instead of YANG statements.



/martin


<= /div>
Andy

--089e0158b5e4c42bfd051c1b7320-- From nobody Thu Jul 30 11:11:20 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 E71B31B2D4E for ; Thu, 30 Jul 2015 11:11:19 -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 9agqF3Azi4pv for ; Thu, 30 Jul 2015 11:11:17 -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 3AB781B2CF9 for ; Thu, 30 Jul 2015 11:11:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 39C531833; Thu, 30 Jul 2015 20:11:12 +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 iX_Ki0ZXihg0; Thu, 30 Jul 2015 20:11:11 +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, 30 Jul 2015 20:11:10 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BFF220046; Thu, 30 Jul 2015 20:11:14 +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 pWPLRq16U3sD; Thu, 30 Jul 2015 20:11:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C55A20045; Thu, 30 Jul 2015 20:11:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C401835F6682; Thu, 30 Jul 2015 20:11:11 +0200 (CEST) Date: Thu, 30 Jul 2015 20:11:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150730181111.GA17770@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Ladislav Lhotka , "netmod@ietf.org" References: <20150729.195151.71742690632261308.mbj@tail-f.com> <20150730.194130.1378875555824248389.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Thu, 30 Jul 2015 18:11:20 -0000 On Thu, Jul 30, 2015 at 10:58:35AM -0700, Andy Bierman wrote: > On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > I understand the intent is that an implementation of NACM > > > > > has to understand these NACM extensions. I agree with Lada > > > > > that the YANG text about MAY ignore extensions casts doubt whether > > > > > this sort of NACM rule is enforceable or specified correctly. > > > > > > > > So do you agree that it would be a good idea to clarify this > > > > according to Juergen's suggestion? > > > > > > > > > > > > > > > Not really. > > > Pretending the extension is just another description-stmt > > > does not really fix anything. > > > > > > A real YANG statement like config-stmt or a new statement > > > called ephemeral-stmt can be modified with refine-stmt > > > or deviate-stmt. This can never happen for > > > an external statement. > > > > There are two separate issues here: > > > > 1) It seems we are in agreement that if a model uses an extension > > statement, it is normative (like ietf-system's usage of nacm:*). > > > > Should we somehow clarify this in 6020bis? > > > > > No -- I agree that was the intent, but it is not achievable > because tools MAY ignore extensions. > Why do we keep on confusing what a statement in a module means and what a tool is required to do? If I decorate a definition with nacm:default-deny-write, then I assume that an implementation will implement the semantics associated with nacm:default-deny-write. If this would not be the case, then why did we define this at all? It does not matter whether a tool knows how to implement nacm:default-deny-write or whether this must be coded by a human. Sorry for 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 From nobody Thu Jul 30 11:19:19 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 CCA131B2E1E for ; Thu, 30 Jul 2015 11:19:18 -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 I4zB5iGBT0yI for ; Thu, 30 Jul 2015 11:19:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3079E1B2D35 for ; Thu, 30 Jul 2015 11:19:14 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B6B91AE046E; Thu, 30 Jul 2015 20:19:13 +0200 (CEST) Date: Thu, 30 Jul 2015 20:19:12 +0200 (CEST) Message-Id: <20150730.201912.763525508503943000.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150730.194130.1378875555824248389.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 18:19:19 -0000 Andy Bierman wrote: > On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > I understand the intent is that an implementation of NACM > > > > > has to understand these NACM extensions. I agree with Lada > > > > > that the YANG text about MAY ignore extensions casts doubt whether > > > > > this sort of NACM rule is enforceable or specified correctly. > > > > > > > > So do you agree that it would be a good idea to clarify this > > > > according to Juergen's suggestion? > > > > > > > > > > > > > > > Not really. > > > Pretending the extension is just another description-stmt > > > does not really fix anything. > > > > > > A real YANG statement like config-stmt or a new statement > > > called ephemeral-stmt can be modified with refine-stmt > > > or deviate-stmt. This can never happen for > > > an external statement. > > > > There are two separate issues here: > > > > 1) It seems we are in agreement that if a model uses an extension > > statement, it is normative (like ietf-system's usage of nacm:*). > > > > Should we somehow clarify this in 6020bis? > > > > > No -- I agree that was the intent, but it is not achievable > because tools MAY ignore extensions. But as have been said several times, this was clearly not the intention. So we should clarify this in 6020bis. > > 2) Extensions cannot be refined or deviated. > > > > Actually, the *syntax* rules allows things like: > > > > deviation /x:foo { > > deviate replace { > > i2rs:ephemeral true; > > } > > } > > > > I agree that it not clear what this means, but we could also > > clarify this in 6020bis. > > > > > > > IMO ephemeral data support needs to be a real statement > > > that can be used with refine-stmt and deviate-stmt. > > > It is a real property of a data node. > > > > Note: it is still not clear that such a statement (base or extension) > > is needed at all. > > > > > > I do not understand why you are so opposed to using real YANG statements > to support ephemeral state. If this solution was already well defined and agreed upon by everyone, then it could be done as a YANG statement. But I am worried that adding this will take quite some time, and will thus delay YANG 1.1; and since IMO extensions can be used just as well, there is no real reason for adding this delay. > Do you have a better solution that the > proposal from draft-haas-i2rs-ephermal-state-reqs-00? Use a separate ephemeral datastore. > I don't see it. > I am opposed to using extensions to ephemeral state because > they are poorly defined in YANG. Then we should fix this. /martin > This is OK since they are for > defining statements outside the YANG standard. Normal mechanisms > like uses/refine and deviate must be supported. > > I do see any advantages whatsoever for using external statements > instead of YANG statements. From nobody Thu Jul 30 11:30:32 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 C797F1B2C5B for ; Thu, 30 Jul 2015 11:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ND9l4mVvvcRm for ; Thu, 30 Jul 2015 11:30:28 -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 DCE691ACD2F for ; Thu, 30 Jul 2015 11:30:27 -0700 (PDT) Received: by lbqc9 with SMTP id c9so7224449lbq.1 for ; Thu, 30 Jul 2015 11:30:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WArNMCSYJLL5Z+sgIaX/UyhPJ0A6G8b4awDu17yG4qM=; b=PR4izuHheEWtzxS2pgrWxBX75p0pl4r+McP8Sa/LvaJtTCf5oMePY5prmbmZGGrrIk tTMl0ZJVO0vfMtv24bMNDaF7rmi5uBFgULo7MFFKUYre8iPaBe1NWZ6oDb9SbVwQ2k3u wvadg3KB+L4KwxNI36cKSX2x7n3/zFVgW1PYcGutR24Uk77IJR7xqgGHEQgvnTdp+eHM +kBt0HgS8915WjplTp+MzEuL5Bd8ATs4fE1aJxIucKbOPenupZM0RaqrpSdwH3Jqedry WVUtGWYorUSPO/maanfu2vV+M+NLah65GGYBzqWHKfj6XRpJw69Z+DZzNRjjtCbSrneR ipeQ== X-Gm-Message-State: ALoCoQmfM8jMgDgit4LEd+ya4WE6V1bzcpUS1IFQptC4y60/LV2atYK7EdfudQe6WlpJR6lZzMsV MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr45345811laj.88.1438281026397; Thu, 30 Jul 2015 11:30:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Jul 2015 11:30:26 -0700 (PDT) In-Reply-To: <20150730.201912.763525508503943000.mbj@tail-f.com> References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.201912.763525508503943000.mbj@tail-f.com> Date: Thu, 30 Jul 2015 11:30:26 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158b5e4aa7ddb051c1be54e Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 18:30:31 -0000 --089e0158b5e4aa7ddb051c1be54e Content-Type: text/plain; charset=UTF-8 Hi, I don't think I2RS is slowing down YANG 1.1. The ephemeral state issue has been known to the NETMOD WG for over a year. I don't care if YANG 1.1 is delayed a month because the solution details need to be worked out. An ephemeral datastore would be useful for describing the collection of YANG data nodes that share the ephemeral property. A YANG statement is needed so ephemeral only data can have its own validation rules. I strongly object to using extensions because they are not part of YANG. They cannot be used properly in refine-stmt or deviate-stmt. They can be ignored by YANG tools. Extensions are fine for proprietary usage, but not standards. On Thu, Jul 30, 2015 at 11:19 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > > > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I understand the intent is that an implementation of NACM > > > > > > has to understand these NACM extensions. I agree with Lada > > > > > > that the YANG text about MAY ignore extensions casts doubt > whether > > > > > > this sort of NACM rule is enforceable or specified correctly. > > > > > > > > > > So do you agree that it would be a good idea to clarify this > > > > > according to Juergen's suggestion? > > > > > > > > > > > > > > > > > > > Not really. > > > > Pretending the extension is just another description-stmt > > > > does not really fix anything. > > > > > > > > A real YANG statement like config-stmt or a new statement > > > > called ephemeral-stmt can be modified with refine-stmt > > > > or deviate-stmt. This can never happen for > > > > an external statement. > > > > > > There are two separate issues here: > > > > > > 1) It seems we are in agreement that if a model uses an extension > > > statement, it is normative (like ietf-system's usage of nacm:*). > > > > > > Should we somehow clarify this in 6020bis? > > > > > > > > No -- I agree that was the intent, but it is not achievable > > because tools MAY ignore extensions. > > But as have been said several times, this was clearly not the > intention. So we should clarify this in 6020bis. > > > > 2) Extensions cannot be refined or deviated. > > > > > > Actually, the *syntax* rules allows things like: > > > > > > deviation /x:foo { > > > deviate replace { > > > i2rs:ephemeral true; > > > } > > > } > > > > > > I agree that it not clear what this means, but we could also > > > clarify this in 6020bis. > > > > > > > > > > IMO ephemeral data support needs to be a real statement > > > > that can be used with refine-stmt and deviate-stmt. > > > > It is a real property of a data node. > > > > > > Note: it is still not clear that such a statement (base or extension) > > > is needed at all. > > > > > > > > > > I do not understand why you are so opposed to using real YANG statements > > to support ephemeral state. > > If this solution was already well defined and agreed upon by everyone, > then it could be done as a YANG statement. But I am worried that > adding this will take quite some time, and will thus delay YANG 1.1; > and since IMO extensions can be used just as well, there is no real > reason for adding this delay. > > > Do you have a better solution that the > > proposal from draft-haas-i2rs-ephermal-state-reqs-00? > > Use a separate ephemeral datastore. > > > I don't see it. > > I am opposed to using extensions to ephemeral state because > > they are poorly defined in YANG. > > Then we should fix this. > > > /martin > > > This is OK since they are for > > defining statements outside the YANG standard. Normal mechanisms > > like uses/refine and deviate must be supported. > > > > I do see any advantages whatsoever for using external statements > > instead of YANG statements. > > --089e0158b5e4aa7ddb051c1be54e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't think I2RS is slowing d= own YANG 1.1.
The ephemeral state issue has been known to the NET= MOD WG
for over a year.=C2=A0 I don't care if YANG 1.1 is del= ayed a month because
the solution details need to be worked out.<= /div>

An ephemeral datastore would be useful for describ= ing the collection of
YANG data nodes that share the ephemeral pr= operty.
A YANG statement is needed so ephemeral only data can
have its own validation rules.=C2=A0 I strongly object to using
extensions because they are not part of YANG.=C2=A0 They
ca= nnot be used properly in refine-stmt or deviate-stmt.
They can be= ignored by YANG tools.
Extensions are fine for proprietary usage= , but not standards.





= On Thu, Jul 30, 2015 at 11:19 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I understand the intent is that an implementation = of NACM
> > > > > has to understand these NACM extensions.=C2=A0 I a= gree with Lada
> > > > > that the YANG text about MAY ignore extensions cas= ts doubt whether
> > > > > this sort of NACM rule is enforceable or specified= correctly.
> > > >
> > > > So do you agree that it would be a good idea to clarify= this
> > > > according to Juergen's suggestion?
> > > >
> > > >
> > > >
> > > Not really.
> > > Pretending the extension is just another description-stmt > > > does not really fix anything.
> > >
> > > A real YANG statement like config-stmt or a new statement > > > called ephemeral-stmt can be modified with refine-stmt
> > > or deviate-stmt.=C2=A0 =C2=A0This can never happen for
> > > an external statement.
> >
> > There are two separate issues here:
> >
> > 1) It seems we are in agreement that if a model uses an extension=
> >=C2=A0 =C2=A0 statement, it is normative (like ietf-system's u= sage of nacm:*).
> >
> >=C2=A0 =C2=A0 Should we somehow clarify this in 6020bis?
> >
> >
> No -- I agree that was the intent, but it is not achievable
> because tools MAY ignore extensions.

But as have been said several times, this was clearly not the
intention.=C2=A0 So we should clarify this in 6020bis.

> > 2) Extensions cannot be refined or deviated.
> >
> >=C2=A0 =C2=A0 Actually, the *syntax* rules allows things like:
> >
> >=C2=A0 =C2=A0 =C2=A0 deviation /x:foo {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviate replace {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2rs:ephemeral true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 }
> >
> >=C2=A0 =C2=A0 I agree that it not clear what this means, but we co= uld also
> >=C2=A0 =C2=A0 clarify this in 6020bis.
> >
> >
> > > IMO ephemeral data support needs to be a real statement
> > > that can be used with refine-stmt and=C2=A0 deviate-stmt. > > > It is a real property of a data node.
> >
> > Note: it is still not clear that such a statement (base or extens= ion)
> > is needed at all.
> >
> >
>
> I do not understand why you are so opposed to using real YANG statemen= ts
> to support ephemeral state.

If this solution was already well defined and agreed upon by everyone,
then it could be done as a YANG statement.=C2=A0 But I am worried that
adding this will take quite some time, and will thus delay YANG 1.1;
and since IMO extensions can be used just as well, there is no real
reason for adding this delay.

> Do you have a better solution that the
> proposal from draft-haas-i2rs-ephermal-state-reqs-00?

Use a separate ephemeral datastore.

> I don't see it.
> I am opposed to using extensions to ephemeral state because
> they are poorly defined in YANG.

Then we should fix this.


/martin

> This is OK since they are for
> defining statements outside the YANG standard.=C2=A0 Normal mechanisms=
> like uses/refine and deviate must be supported.
>
> I do see any advantages whatsoever for using external statements
> instead of YANG statements.


--089e0158b5e4aa7ddb051c1be54e-- From nobody Thu Jul 30 11:43:56 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 CB8DC1B2F2C for ; Thu, 30 Jul 2015 11:43:55 -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 NeyeLIfQ2iAL for ; Thu, 30 Jul 2015 11:43:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 025771B2F2E for ; Thu, 30 Jul 2015 11:43:54 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id CD8B41AE046E; Thu, 30 Jul 2015 20:43:52 +0200 (CEST) Date: Thu, 30 Jul 2015 20:43:52 +0200 (CEST) Message-Id: <20150730.204352.1467860508243983687.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150730.201912.763525508503943000.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 18:43:55 -0000 Andy Bierman wrote: > I strongly object to using > extensions because they are not part of YANG. They > cannot be used properly in refine-stmt or deviate-stmt. > They can be ignored by YANG tools. Putting the ephemeral question aside for a moment, and focusing on extensions. The original intention with the extension statement was that they could be used for normative semantics, which is also evident from NACM and ietf-system etc. So if the text is unclear in this regard, we should clarify this. Juergen already provided text. > Extensions are fine for proprietary usage, but not standards. 6020 says: YANG is an extensible language, allowing extension statements to be defined by standards bodies, vendors, and individuals. It is pretty clear that the intention was not that this is for vendors only. /martin From nobody Thu Jul 30 12:06: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 627131B2F95 for ; Thu, 30 Jul 2015 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 MlIn0MbFlRLj for ; Thu, 30 Jul 2015 12:05:58 -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 F338E1B2F9A for ; Thu, 30 Jul 2015 12:05:57 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so33125269lbb.0 for ; Thu, 30 Jul 2015 12:05:56 -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=aQK667FJTl3fxcVxFukbITFVWb8rxUcF7CTzrb5Gkms=; b=Yr4R8kl87w8EQ0yFPquZ0DNOgx59u+omq+0fveJDm14geV6re3xqCFOCxBJ5x9dBK6 lstpcmbd1CL/YalKt69cQbG1jIwoSHP1IwkI/PchXO8kirScite0EUjEUILcEPVJgvP0 dXMu7M2qer0NTsMlMKq+gQ/POVW0oCWM9jbPvpvs0OuVvaVNU/8D1HWYNpHXCSLVBsby xZkQcvgA4fYNnsbXGG8q6RL6vVVeoKqQSDkAa4wlaOeD4osjD5dbR2R2Jp3LcGHjlLCD Dow0m7oKk/wieNAiIy989zywTYnUsH/Gp8aL25d4Bk3/5i+qnfpkP+/AENqlwp/wsUhQ bX0Q== X-Gm-Message-State: ALoCoQlIKnSRilV0RtaacIPUHIBCtjIeKUg9yLtEIaJCjlVXLj2psld1ew6o6QfTH82gJ7WfYj2j MIME-Version: 1.0 X-Received: by 10.112.155.164 with SMTP id vx4mr45686637lbb.38.1438283156475; Thu, 30 Jul 2015 12:05:56 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Jul 2015 12:05:56 -0700 (PDT) In-Reply-To: <20150730.194130.1378875555824248389.mbj@tail-f.com> References: <20150729.195151.71742690632261308.mbj@tail-f.com> <20150730.194130.1378875555824248389.mbj@tail-f.com> Date: Thu, 30 Jul 2015 12:05:56 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e01228a92a0e9f7051c1c6468 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 19:06:00 -0000 --089e01228a92a0e9f7051c1c6468 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > I understand the intent is that an implementation of NACM > > > > has to understand these NACM extensions. I agree with Lada > > > > that the YANG text about MAY ignore extensions casts doubt whether > > > > this sort of NACM rule is enforceable or specified correctly. > > > > > > So do you agree that it would be a good idea to clarify this > > > according to Juergen's suggestion? > > > > > > > > > > > Not really. > > Pretending the extension is just another description-stmt > > does not really fix anything. > > > > A real YANG statement like config-stmt or a new statement > > called ephemeral-stmt can be modified with refine-stmt > > or deviate-stmt. This can never happen for > > an external statement. > > There are two separate issues here: > > 1) It seems we are in agreement that if a model uses an extension > statement, it is normative (like ietf-system's usage of nacm:*). > > Should we somehow clarify this in 6020bis? > > 2) Extensions cannot be refined or deviated. > > Actually, the *syntax* rules allows things like: > > deviation /x:foo { > deviate replace { > i2rs:ephemeral true; > } > } > > I agree that it not clear what this means, but we could also > clarify this in 6020bis. > > But this will take even longer than just defining the statements that are needed for ephemeral state, so no point in doing that. The text in 7.18.3.2 clearly does not support the example above at all. Only one of the keywords listed in the table are supported. The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node. The deviates's Substatements +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | config | 7.19.1 | 0..1 | | default | 7.6.4 | 0..1 | | mandatory | 7.6.5 | 0..1 | | max-elements | 7.7.4 | 0..1 | | min-elements | 7.7.3 | 0..1 | | must | 7.5.3 | 0..n | | type | 7.4 | 0..1 | | unique | 7.8.3 | 0..n | | units | 7.3.3 | 0..1 | +--------------+---------+-------------+ > > IMO ephemeral data support needs to be a real statement > > that can be used with refine-stmt and deviate-stmt. > > It is a real property of a data node. > > Note: it is still not clear that such a statement (base or extension) > is needed at all. > > Maybe not to you, but according to the I2RS ephemeral requirements, it is needed, so unless you have a better plan, this is the default. Explain how ephemeral state can be identified within a data node. It must be possible to use groupings to define such data nodes. If must be possible to refine these groupings. It must be possible for a vendor to write deviation statements. All YANG tools must recognize the ephemeral data property. It should not be isolated to a particular YANG module, which would create a dependency in all future YANG modules. Andy > > /martin > --089e01228a92a0e9f7051c1c6468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > Hi,
> > >
> > > I understand the intent is that an implementation of NACM > > > has to understand these NACM extensions.=C2=A0 I agree with = Lada
> > > that the YANG text about MAY ignore extensions casts doubt w= hether
> > > this sort of NACM rule is enforceable or specified correctly= .
> >
> > So do you agree that it would be a good idea to clarify this
> > according to Juergen's suggestion?
> >
> >
> >
> Not really.
> Pretending the extension is just another description-stmt
> does not really fix anything.
>
> A real YANG statement like config-stmt or a new statement
> called ephemeral-stmt can be modified with refine-stmt
> or deviate-stmt.=C2=A0 =C2=A0This can never happen for
> an external statement.

There are two separate issues here:

1) It seems we are in agreement that if a model uses an extension
=C2=A0 =C2=A0statement, it is normative (like ietf-system's usage of na= cm:*).

=C2=A0 =C2=A0Should we somehow clarify this in 6020bis?

2) Extensions cannot be refined or deviated.

=C2=A0 =C2=A0Actually, the *syntax* rules allows things like:

=C2=A0 =C2=A0 =C2=A0deviation /x:foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0deviate replace {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs:ephemeral true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0I agree that it not clear what this means, but we could also =C2=A0 =C2=A0clarify this in 6020bis.



But this will take even= longer than just defining the statements that
are needed for eph= emeral state, so no point in doing that.

The text = in =C2=A07.18.3.2 clearly does not support the example above at all.
<= div>Only one of the keywords listed in the table are supported.
<= br>

   The substatement's keyword MUST match a =
corresponding
   keyword in the target node, and the argument's string MUST be equal
   to the corresponding keyword's argument string in the target node.

                       The deviates's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | default      | 7.6.4   | 0..1        |
                 | mandatory    | 7.6.5   | 0..1        |
                 | max-elements | 7.7.4   | 0..1        |
                 | min-elements | 7.7.3   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | type         | 7.4     | 0..1        |
                 | unique       | 7.8.3   | 0..n        |
                 | units        | 7.3.3   | 0..1        |
                 +--------------+---------+-------------+



> IMO ephemeral data support needs to be a real statement
> that can be used with refine-stmt and=C2=A0 deviate-stmt.
> It is a real property of a data node.

Note: it is still not clear that such a statement (base or extension)
is needed at all.



Maybe not to you, but according to th= e I2RS ephemeral requirements,
it is needed, so unless you have a= better plan, this is the default.

Explain how eph= emeral state can be identified within a data node.
It must be pos= sible to use groupings to define such data nodes.
If must be poss= ible to refine these groupings.
It must be possible for a vendor = to write deviation statements.
All YANG tools must recognize the = ephemeral data property.
It should not be isolated to a particula= r YANG module, which would
create a dependency in all future YANG= modules.


Andy

=


=C2=A0

/martin

--089e01228a92a0e9f7051c1c6468-- From nobody Thu Jul 30 12:16: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 733A21ACD6C for ; Thu, 30 Jul 2015 12:16: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 206k2O503oPo for ; Thu, 30 Jul 2015 12:16: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 1B3AD1ACCFB for ; Thu, 30 Jul 2015 12:16:32 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id E55941AE046E; Thu, 30 Jul 2015 21:16:29 +0200 (CEST) Date: Thu, 30 Jul 2015 21:16:29 +0200 (CEST) Message-Id: <20150730.211629.1600508626921450694.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150730.194130.1378875555824248389.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: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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, 30 Jul 2015 19:16:44 -0000 Andy Bierman wrote: > On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > I understand the intent is that an implementation of NACM > > > > > has to understand these NACM extensions. I agree with Lada > > > > > that the YANG text about MAY ignore extensions casts doubt whether > > > > > this sort of NACM rule is enforceable or specified correctly. > > > > > > > > So do you agree that it would be a good idea to clarify this > > > > according to Juergen's suggestion? > > > > > > > > > > > > > > > Not really. > > > Pretending the extension is just another description-stmt > > > does not really fix anything. > > > > > > A real YANG statement like config-stmt or a new statement > > > called ephemeral-stmt can be modified with refine-stmt > > > or deviate-stmt. This can never happen for > > > an external statement. > > > > There are two separate issues here: > > > > 1) It seems we are in agreement that if a model uses an extension > > statement, it is normative (like ietf-system's usage of nacm:*). > > > > Should we somehow clarify this in 6020bis? > > > > 2) Extensions cannot be refined or deviated. > > > > Actually, the *syntax* rules allows things like: > > > > deviation /x:foo { > > deviate replace { > > i2rs:ephemeral true; > > } > > } > > > > I agree that it not clear what this means, but we could also > > clarify this in 6020bis. > > > > > > But this will take even longer than just defining the statements that > are needed for ephemeral state, so no point in doing that. > > The text in 7.18.3.2 clearly does not support the example above at all. The grammar allows extensions everywhere, so the example is (as I wrote) syntactically valid. > Only one of the keywords listed in the table are supported. The text doesn't say so, and anyway my point was that - regardless of the outcome of the ephemeral dicussion - it might be a good a idea to clarify that extensions can be deviated as well. /martin > > > The substatement's keyword MUST match a corresponding > keyword in the target node, and the argument's string MUST be equal > to the corresponding keyword's argument string in the target node. > > The deviates's Substatements > > +--------------+---------+-------------+ > | substatement | section | cardinality | > +--------------+---------+-------------+ > | config | 7.19.1 | 0..1 | > | default | 7.6.4 | 0..1 | > | mandatory | 7.6.5 | 0..1 | > | max-elements | 7.7.4 | 0..1 | > | min-elements | 7.7.3 | 0..1 | > | must | 7.5.3 | 0..n | > | type | 7.4 | 0..1 | > | unique | 7.8.3 | 0..n | > | units | 7.3.3 | 0..1 | > +--------------+---------+-------------+ > > > > > > > IMO ephemeral data support needs to be a real statement > > > that can be used with refine-stmt and deviate-stmt. > > > It is a real property of a data node. > > > > Note: it is still not clear that such a statement (base or extension) > > is needed at all. > > > > > > Maybe not to you, but according to the I2RS ephemeral requirements, > it is needed, so unless you have a better plan, this is the default. > > Explain how ephemeral state can be identified within a data node. > It must be possible to use groupings to define such data nodes. > If must be possible to refine these groupings. > It must be possible for a vendor to write deviation statements. > All YANG tools must recognize the ephemeral data property. > It should not be isolated to a particular YANG module, which would > create a dependency in all future YANG modules. > > > Andy > > > > > > > > > /martin > > From nobody Thu Jul 30 23:22:58 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 C45E11B3285 for ; Thu, 30 Jul 2015 23:22:56 -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 ZDMMdfX5t304 for ; Thu, 30 Jul 2015 23:22:55 -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 930FA1A00CF for ; Thu, 30 Jul 2015 23:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=653; q=dns/txt; s=iport; t=1438323775; x=1439533375; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QDU6V3IMAsmtmPTy26VhyUDls2GK5uqxWhL3B0KkiGo=; b=Zz9mhIWCFxlmGMMCAA1EhDY/YSzvGQNhPO+ETUJkN9LRIjkZ+3lMX98b VOeV5hXHOfz2Tr6aPePfW6iO+VcffL1zLu8oWqGEkVeEa7ytNnA9zVpqd GeNoANf2mkCXmE/shik6CeqtD0mSqCUlzsW8E2PKnX/9JIX0dSVgClXlf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnAwBvE7tV/4YNJK1bgxpUb7wnCYF/hzM4FAEBAQEBAQF/C4QqgQsBgQAnBIhBoGKlagEBCAIBH5AKhH4FlHgBhHqHToINkAqHJSaDfYI3gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,582,1432598400"; d="scan'208";a="174228900" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2015 06:22:54 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6V6Ms1K017886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Jul 2015 06:22:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 01:22:54 -0500 From: "Pravin Gohite (prgohite)" To: "netmod@ietf.org" Thread-Topic: Minor review comments for Yang 1.1 draft Thread-Index: AQHQy1lVQRgVQp7VSUedqIzzPm3cYQ== Date: Fri, 31 Jul 2015 06:22:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.24.88.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] Minor review comments for Yang 1.1 draft 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: Fri, 31 Jul 2015 06:22:56 -0000 Section 7.15, Para 4, Typo Error: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D "Since an action cannot be defined >> an the << top-level of a module =8A" Section 7.15.3, Invalid XML: =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 XML reply example is malformed as reset-finished-at tag has wrong closing tag.=20 2014-07-29T13:42:12Z Thanks, Pravin From nobody Fri Jul 31 01:09:41 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 34F8C1B33AD for ; Fri, 31 Jul 2015 01:09:39 -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 ngNqgqjISn4G for ; Fri, 31 Jul 2015 01:09:37 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6241B3415 for ; Fri, 31 Jul 2015 01:06:18 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 474881CC0249; Fri, 31 Jul 2015 10:06:17 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150730.194130.1378875555824248389.mbj@tail-f.com> References: <20150729.195151.71742690632261308.mbj@tail-f.com> <20150730.194130.1378875555824248389.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 31 Jul 2015 10:06:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 08:09:39 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> > > Hi, >> > > >> > > I understand the intent is that an implementation of NACM >> > > has to understand these NACM extensions. I agree with Lada >> > > that the YANG text about MAY ignore extensions casts doubt whether >> > > this sort of NACM rule is enforceable or specified correctly. >> > >> > So do you agree that it would be a good idea to clarify this >> > according to Juergen's suggestion? >> > >> > >> > >> Not really. >> Pretending the extension is just another description-stmt >> does not really fix anything. >> >> A real YANG statement like config-stmt or a new statement >> called ephemeral-stmt can be modified with refine-stmt >> or deviate-stmt. This can never happen for >> an external statement. > > There are two separate issues here: > > 1) It seems we are in agreement that if a model uses an extension > statement, it is normative (like ietf-system's usage of nacm:*). > > Should we somehow clarify this in 6020bis? Yes, and I made a proposal. The text should clarify what's important for interoperability. Behaviour of tools, compilers and parsers is IMO irrelevant because tools have different purposes. Lada > > 2) Extensions cannot be refined or deviated. > > Actually, the *syntax* rules allows things like: > > deviation /x:foo { > deviate replace { > i2rs:ephemeral true; > } > } > > I agree that it not clear what this means, but we could also > clarify this in 6020bis. > > >> IMO ephemeral data support needs to be a real statement >> that can be used with refine-stmt and deviate-stmt. >> It is a real property of a data node. > > Note: it is still not clear that such a statement (base or extension) > is needed at all. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jul 31 01:13:19 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 D7F181B330B for ; Fri, 31 Jul 2015 01:13: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] 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 MWoK0VyP0iCs for ; Fri, 31 Jul 2015 01:13:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D01C1B337C for ; Fri, 31 Jul 2015 01:12:18 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9CC931CC06AE; Fri, 31 Jul 2015 10:12:17 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150730.211629.1600508626921450694.mbj@tail-f.com> References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 31 Jul 2015 10:12:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 08:13:18 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund >> > wrote: >> > > >> > > > Andy Bierman wrote: >> > > > > Hi, >> > > > > >> > > > > I understand the intent is that an implementation of NACM >> > > > > has to understand these NACM extensions. I agree with Lada >> > > > > that the YANG text about MAY ignore extensions casts doubt whether >> > > > > this sort of NACM rule is enforceable or specified correctly. >> > > > >> > > > So do you agree that it would be a good idea to clarify this >> > > > according to Juergen's suggestion? >> > > > >> > > > >> > > > >> > > Not really. >> > > Pretending the extension is just another description-stmt >> > > does not really fix anything. >> > > >> > > A real YANG statement like config-stmt or a new statement >> > > called ephemeral-stmt can be modified with refine-stmt >> > > or deviate-stmt. This can never happen for >> > > an external statement. >> > >> > There are two separate issues here: >> > >> > 1) It seems we are in agreement that if a model uses an extension >> > statement, it is normative (like ietf-system's usage of nacm:*). >> > >> > Should we somehow clarify this in 6020bis? >> > >> > 2) Extensions cannot be refined or deviated. >> > >> > Actually, the *syntax* rules allows things like: >> > >> > deviation /x:foo { >> > deviate replace { >> > i2rs:ephemeral true; >> > } >> > } >> > >> > I agree that it not clear what this means, but we could also >> > clarify this in 6020bis. >> > >> > >> >> But this will take even longer than just defining the statements that >> are needed for ephemeral state, so no point in doing that. >> >> The text in 7.18.3.2 clearly does not support the example above at all. > > The grammar allows extensions everywhere, so the example is (as I > wrote) syntactically valid. > >> Only one of the keywords listed in the table are supported. > > The text doesn't say so, and anyway my point was that - regardless of > the outcome of the ephemeral dicussion - it might be a good a idea to > clarify that extensions can be deviated as well. +1 Lada > > /martin > >> >> >> The substatement's keyword MUST match a corresponding >> keyword in the target node, and the argument's string MUST be equal >> to the corresponding keyword's argument string in the target node. >> >> The deviates's Substatements >> >> +--------------+---------+-------------+ >> | substatement | section | cardinality | >> +--------------+---------+-------------+ >> | config | 7.19.1 | 0..1 | >> | default | 7.6.4 | 0..1 | >> | mandatory | 7.6.5 | 0..1 | >> | max-elements | 7.7.4 | 0..1 | >> | min-elements | 7.7.3 | 0..1 | >> | must | 7.5.3 | 0..n | >> | type | 7.4 | 0..1 | >> | unique | 7.8.3 | 0..n | >> | units | 7.3.3 | 0..1 | >> +--------------+---------+-------------+ >> >> >> >> >> > > IMO ephemeral data support needs to be a real statement >> > > that can be used with refine-stmt and deviate-stmt. >> > > It is a real property of a data node. >> > >> > Note: it is still not clear that such a statement (base or extension) >> > is needed at all. >> > >> > >> >> Maybe not to you, but according to the I2RS ephemeral requirements, >> it is needed, so unless you have a better plan, this is the default. >> >> Explain how ephemeral state can be identified within a data node. >> It must be possible to use groupings to define such data nodes. >> If must be possible to refine these groupings. >> It must be possible for a vendor to write deviation statements. >> All YANG tools must recognize the ephemeral data property. >> It should not be isolated to a particular YANG module, which would >> create a dependency in all future YANG modules. >> >> >> Andy >> >> >> >> >> >> > >> > /martin >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jul 31 01:40:03 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 DF1351B33E9 for ; Fri, 31 Jul 2015 01:40:02 -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 jiAaSHvG8_c9 for ; Fri, 31 Jul 2015 01:40:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 28F5A1B2CFE for ; Fri, 31 Jul 2015 01:40:01 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id CE46F1CC06AE; Fri, 31 Jul 2015 10:39:59 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150730.194130.1378875555824248389.mbj@tail-f.com> References: <20150729.195151.71742690632261308.mbj@tail-f.com> <20150730.194130.1378875555824248389.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 31 Jul 2015 10:40:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 08:40:03 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> > > Hi, >> > > >> > > I understand the intent is that an implementation of NACM >> > > has to understand these NACM extensions. I agree with Lada >> > > that the YANG text about MAY ignore extensions casts doubt whether >> > > this sort of NACM rule is enforceable or specified correctly. >> > >> > So do you agree that it would be a good idea to clarify this >> > according to Juergen's suggestion? >> > >> > >> > >> Not really. >> Pretending the extension is just another description-stmt >> does not really fix anything. >> >> A real YANG statement like config-stmt or a new statement >> called ephemeral-stmt can be modified with refine-stmt >> or deviate-stmt. This can never happen for >> an external statement. > > There are two separate issues here: > > 1) It seems we are in agreement that if a model uses an extension > statement, it is normative (like ietf-system's usage of nacm:*). > What about the problem with "old clients"? Let's say a new version of a device advertises a module that contains an extension (such as "annotation") that changes server behaviour, datastore semantics, things like that. So far the theory has been that a client may ignore such a module, which however means ignoring the changes in semantics that may be crucial for interoperability and/or security. I think a robust and safe old client support is in fact very difficult to achieve and may be a security hole. This is my favorite example: augment "/if:interfaces" { leaf launch-missiles { type boolean; default true; } } IMO old clients may try to perform the same operations they used to do with an old version without knowing the current datastore schema and semantics, but no guarantees can be given - it may work or fail miserably. Lada > Should we somehow clarify this in 6020bis? > > 2) Extensions cannot be refined or deviated. > > Actually, the *syntax* rules allows things like: > > deviation /x:foo { > deviate replace { > i2rs:ephemeral true; > } > } > > I agree that it not clear what this means, but we could also > clarify this in 6020bis. > > >> IMO ephemeral data support needs to be a real statement >> that can be used with refine-stmt and deviate-stmt. >> It is a real property of a data node. > > Note: it is still not clear that such a statement (base or extension) > is needed at all. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jul 31 05:40:11 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 35A391A1A86 for ; Fri, 31 Jul 2015 05:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yrqa_vTC0Ifw for ; Fri, 31 Jul 2015 05:40:07 -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 23AE21A012D for ; Fri, 31 Jul 2015 05:40:07 -0700 (PDT) Received: by lafd3 with SMTP id d3so43351575laf.1 for ; Fri, 31 Jul 2015 05:40: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:cc:content-type; bh=gZJD+uEeGPxGZVaNrS8Z+mIyz2Cpi/37DQqGZCEKDFQ=; b=J3ZyMPRzZDDHH5qm+DTeHSqBbiKyE/DZh6hQkjhljbo1yHx3mFfVgGqpwK5a7Gn64T 9Od7PukbQc+yJ6GzOkhb/CtuGevWgqGBWPvAmXO/Z/Ew0E7BYyGxfgTLeVhBhRvXySBH K5xgU3hxftVOkCujiVkfTuMjSBCLrXg5bAxlmDBg8kfX18XgqLBoYIpajSXcgqy47dWJ EeNqQwRUlWBQhGwjOkS6fevlpqhDUBOHy4dRnaXdkIeGzhEuqAg595HD4dBbGhMjKjg3 Al6WFAbEOh/dCg5e3DK4Fbltwm53OLcPvSrFXGRcSfRrvF9NDxg4a0Vs2xEbkmCclKoX VU4g== X-Gm-Message-State: ALoCoQmC6AdtxqRwNHX8+syoio4ti2uL6v3A/YXDF4lw3ZQdJTtigLgLp26fgV3U77eW6Szle/3X MIME-Version: 1.0 X-Received: by 10.112.24.71 with SMTP id s7mr2500049lbf.37.1438346405636; Fri, 31 Jul 2015 05:40:05 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 31 Jul 2015 05:40:05 -0700 (PDT) In-Reply-To: References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> Date: Fri, 31 Jul 2015 05:40:05 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113438329285fe051c2b1e67 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 12:40:10 -0000 --001a113438329285fe051c2b1e67 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Andy Bierman wrote: > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund > wrote: > >> > >> > Andy Bierman wrote: > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund > >> > wrote: > >> > > > >> > > > Andy Bierman wrote: > >> > > > > Hi, > >> > > > > > >> > > > > I understand the intent is that an implementation of NACM > >> > > > > has to understand these NACM extensions. I agree with Lada > >> > > > > that the YANG text about MAY ignore extensions casts doubt > whether > >> > > > > this sort of NACM rule is enforceable or specified correctly. > >> > > > > >> > > > So do you agree that it would be a good idea to clarify this > >> > > > according to Juergen's suggestion? > >> > > > > >> > > > > >> > > > > >> > > Not really. > >> > > Pretending the extension is just another description-stmt > >> > > does not really fix anything. > >> > > > >> > > A real YANG statement like config-stmt or a new statement > >> > > called ephemeral-stmt can be modified with refine-stmt > >> > > or deviate-stmt. This can never happen for > >> > > an external statement. > >> > > >> > There are two separate issues here: > >> > > >> > 1) It seems we are in agreement that if a model uses an extension > >> > statement, it is normative (like ietf-system's usage of nacm:*). > >> > > >> > Should we somehow clarify this in 6020bis? > >> > > >> > 2) Extensions cannot be refined or deviated. > >> > > >> > Actually, the *syntax* rules allows things like: > >> > > >> > deviation /x:foo { > >> > deviate replace { > >> > i2rs:ephemeral true; > >> > } > >> > } > >> > > >> > I agree that it not clear what this means, but we could also > >> > clarify this in 6020bis. > >> > > >> > > >> > >> But this will take even longer than just defining the statements that > >> are needed for ephemeral state, so no point in doing that. > >> > >> The text in 7.18.3.2 clearly does not support the example above at all. > > > > The grammar allows extensions everywhere, so the example is (as I > > wrote) syntactically valid. > > > >> Only one of the keywords listed in the table are supported. > > > > The text doesn't say so, and anyway my point was that - regardless of > > the outcome of the ephemeral dicussion - it might be a good a idea to > > clarify that extensions can be deviated as well. > > +1 > So you are saying that a tool MAY ignore any extension, except inside a deviation-stmt? Then it becomes mandatory to support? Or do you mean: Yes you can put extension-stmts anywhere, but also, yes the tool MAY ignore every single extension (everywhere, including inside a deviation-stmt) > Lada > Andy > > > > > /martin > > > >> > >> > >> The substatement's keyword MUST match a corresponding > >> keyword in the target node, and the argument's string MUST be equal > >> to the corresponding keyword's argument string in the target node. > >> > >> The deviates's Substatements > >> > >> +--------------+---------+-------------+ > >> | substatement | section | cardinality | > >> +--------------+---------+-------------+ > >> | config | 7.19.1 | 0..1 | > >> | default | 7.6.4 | 0..1 | > >> | mandatory | 7.6.5 | 0..1 | > >> | max-elements | 7.7.4 | 0..1 | > >> | min-elements | 7.7.3 | 0..1 | > >> | must | 7.5.3 | 0..n | > >> | type | 7.4 | 0..1 | > >> | unique | 7.8.3 | 0..n | > >> | units | 7.3.3 | 0..1 | > >> +--------------+---------+-------------+ > >> > >> > >> > >> > >> > > IMO ephemeral data support needs to be a real statement > >> > > that can be used with refine-stmt and deviate-stmt. > >> > > It is a real property of a data node. > >> > > >> > Note: it is still not clear that such a statement (base or extension) > >> > is needed at all. > >> > > >> > > >> > >> Maybe not to you, but according to the I2RS ephemeral requirements, > >> it is needed, so unless you have a better plan, this is the default. > >> > >> Explain how ephemeral state can be identified within a data node. > >> It must be possible to use groupings to define such data nodes. > >> If must be possible to refine these groupings. > >> It must be possible for a vendor to write deviation statements. > >> All YANG tools must recognize the ephemeral data property. > >> It should not be isolated to a particular YANG module, which would > >> create a dependency in all future YANG modules. > >> > >> > >> Andy > >> > >> > >> > >> > >> > >> > > >> > /martin > >> > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a113438329285fe051c2b1e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Martin Bjorklund <mbj@tail-f.com> writes:

> Andy Bierman <andy@yumaworks.= com> wrote:
>> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>> > Andy Bierman <andy@y= umaworks.com> wrote:
>> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>
>> > wrote:
>> > >
>> > > > Andy Bierman <andy@yumaworks.com> wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I understand the intent is that an implementat= ion of NACM
>> > > > > has to understand these NACM extensions.=C2=A0= I agree with Lada
>> > > > > that the YANG text about MAY ignore extensions= casts doubt whether
>> > > > > this sort of NACM rule is enforceable or speci= fied correctly.
>> > > >
>> > > > So do you agree that it would be a good idea to cla= rify this
>> > > > according to Juergen's suggestion?
>> > > >
>> > > >
>> > > >
>> > > Not really.
>> > > Pretending the extension is just another description-stm= t
>> > > does not really fix anything.
>> > >
>> > > A real YANG statement like config-stmt or a new statemen= t
>> > > called ephemeral-stmt can be modified with refine-stmt >> > > or deviate-stmt.=C2=A0 =C2=A0This can never happen for >> > > an external statement.
>> >
>> > There are two separate issues here:
>> >
>> > 1) It seems we are in agreement that if a model uses an exten= sion
>> >=C2=A0 =C2=A0 statement, it is normative (like ietf-system'= ;s usage of nacm:*).
>> >
>> >=C2=A0 =C2=A0 Should we somehow clarify this in 6020bis?
>> >
>> > 2) Extensions cannot be refined or deviated.
>> >
>> >=C2=A0 =C2=A0 Actually, the *syntax* rules allows things like:=
>> >
>> >=C2=A0 =C2=A0 =C2=A0 deviation /x:foo {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviate replace {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2rs:ephemeral true;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> >=C2=A0 =C2=A0 =C2=A0 }
>> >
>> >=C2=A0 =C2=A0 I agree that it not clear what this means, but w= e could also
>> >=C2=A0 =C2=A0 clarify this in 6020bis.
>> >
>> >
>>
>> But this will take even longer than just defining the statements t= hat
>> are needed for ephemeral state, so no point in doing that.
>>
>> The text in=C2=A0 7.18.3.2 clearly does not support the example ab= ove at all.
>
> The grammar allows extensions everywhere, so the example is (as I
> wrote) syntactically valid.
>
>> Only one of the keywords listed in the table are supported.
>
> The text doesn't say so, and anyway my point was that - regardless= of
> the outcome of the ephemeral dicussion - it might be a good a idea to<= br> > clarify that extensions can be deviated as well.

+1


So you are saying tha= t a tool MAY ignore any extension, except
inside a deviation-stmt= ?=C2=A0 Then it becomes mandatory to support?

Or d= o you mean:

Yes you can put extension-stmts anywhe= re, but also, yes the tool
MAY ignore every single extension (eve= rywhere, including inside a
deviation-stmt)=C2=A0

<= /div>

Lada

Andy
=C2=A0

>
> /martin
>
>>
>>
>>=C2=A0 =C2=A0 The substatement's keyword MUST match a correspon= ding
>>=C2=A0 =C2=A0 keyword in the target node, and the argument's st= ring MUST be equal
>>=C2=A0 =C2=A0 to the corresponding keyword's argument string in= the target node.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 The deviates's Substatements
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---= -----------+---------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | su= bstatement | section | cardinality |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---= -----------+---------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | co= nfig=C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.19.1=C2=A0 | 0..1=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | de= fault=C2=A0 =C2=A0 =C2=A0 | 7.6.4=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ma= ndatory=C2=A0 =C2=A0 | 7.6.5=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ma= x-elements | 7.7.4=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | mi= n-elements | 7.7.3=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | mu= st=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.5.3=C2=A0 =C2=A0| 0..n=C2=A0 =C2=A0= =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ty= pe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.4=C2=A0 =C2=A0 =C2=A0| 0..1=C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | un= ique=C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.8.3=C2=A0 =C2=A0| 0..n=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | un= its=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 7.3.3=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---= -----------+---------+-------------+
>>
>>
>>
>>
>> > > IMO ephemeral data support needs to be a real statement<= br> >> > > that can be used with refine-stmt and=C2=A0 deviate-stmt= .
>> > > It is a real property of a data node.
>> >
>> > Note: it is still not clear that such a statement (base or ex= tension)
>> > is needed at all.
>> >
>> >
>>
>> Maybe not to you, but according to the I2RS ephemeral requirements= ,
>> it is needed, so unless you have a better plan, this is the defaul= t.
>>
>> Explain how ephemeral state can be identified within a data node.<= br> >> It must be possible to use groupings to define such data nodes. >> If must be possible to refine these groupings.
>> It must be possible for a vendor to write deviation statements. >> All YANG tools must recognize the ephemeral data property.
>> It should not be isolated to a particular YANG module, which would=
>> create a dependency in all future YANG modules.
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> >
>> > /martin
>> >

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a113438329285fe051c2b1e67-- From nobody Fri Jul 31 05:48:03 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 4D3671A6FE9 for ; Fri, 31 Jul 2015 05:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 BAuesPFj_tmz for ; Fri, 31 Jul 2015 05:48:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440031A6FF7 for ; Fri, 31 Jul 2015 05:45:17 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E936818187B; Fri, 31 Jul 2015 14:45:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438346716; bh=6i2O74XosHxsa4ZwTOObl7ErZUT30e2zgrWtMehjZpI=; h=From:Date:To; b=VXMgv590Z+IbnpMd9QUXExANQteDFIFMDUtYFHluYpwcaMAjxp9CgOj0cLqaAYXiB ZI+1rC7KSMIABm/g5Fd43FhafT2qWAwmLy3ojb7QdiCBRFQI+fG51QB8I8GmaJEmNA qTbMMSNaydCo1OCgn/5jmm3lVS1K7QA18naZopdg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 31 Jul 2015 14:45:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 12:48:02 -0000 > On 31 Jul 2015, at 14:40, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka = wrote: > Martin Bjorklund writes: >=20 > > Andy Bierman wrote: > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund = wrote: > >> > >> > Andy Bierman wrote: > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = > >> > wrote: > >> > > > >> > > > Andy Bierman wrote: > >> > > > > Hi, > >> > > > > > >> > > > > I understand the intent is that an implementation of NACM > >> > > > > has to understand these NACM extensions. I agree with Lada > >> > > > > that the YANG text about MAY ignore extensions casts doubt = whether > >> > > > > this sort of NACM rule is enforceable or specified = correctly. > >> > > > > >> > > > So do you agree that it would be a good idea to clarify this > >> > > > according to Juergen's suggestion? > >> > > > > >> > > > > >> > > > > >> > > Not really. > >> > > Pretending the extension is just another description-stmt > >> > > does not really fix anything. > >> > > > >> > > A real YANG statement like config-stmt or a new statement > >> > > called ephemeral-stmt can be modified with refine-stmt > >> > > or deviate-stmt. This can never happen for > >> > > an external statement. > >> > > >> > There are two separate issues here: > >> > > >> > 1) It seems we are in agreement that if a model uses an extension > >> > statement, it is normative (like ietf-system's usage of = nacm:*). > >> > > >> > Should we somehow clarify this in 6020bis? > >> > > >> > 2) Extensions cannot be refined or deviated. > >> > > >> > Actually, the *syntax* rules allows things like: > >> > > >> > deviation /x:foo { > >> > deviate replace { > >> > i2rs:ephemeral true; > >> > } > >> > } > >> > > >> > I agree that it not clear what this means, but we could also > >> > clarify this in 6020bis. > >> > > >> > > >> > >> But this will take even longer than just defining the statements = that > >> are needed for ephemeral state, so no point in doing that. > >> > >> The text in 7.18.3.2 clearly does not support the example above at = all. > > > > The grammar allows extensions everywhere, so the example is (as I > > wrote) syntactically valid. > > > >> Only one of the keywords listed in the table are supported. > > > > The text doesn't say so, and anyway my point was that - regardless = of > > the outcome of the ephemeral dicussion - it might be a good a idea = to > > clarify that extensions can be deviated as well. >=20 > +1 >=20 >=20 > So you are saying that a tool MAY ignore any extension, except > inside a deviation-stmt? Then it becomes mandatory to support? >=20 > Or do you mean: >=20 > Yes you can put extension-stmts anywhere, but also, yes the tool > MAY ignore every single extension (everywhere, including inside a > deviation-stmt) I understood Martin=E2=80=99s proposal so that a device that doesn=E2=80=99= t support an extension used in modules it advertises will have to put it = in a =E2=80=9Cnot-supported=E2=80=9D deviation. Lada > =20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > > > /martin > > > >> > >> > >> The substatement's keyword MUST match a corresponding > >> keyword in the target node, and the argument's string MUST be = equal > >> to the corresponding keyword's argument string in the target = node. > >> > >> The deviates's Substatements > >> > >> +--------------+---------+-------------+ > >> | substatement | section | cardinality | > >> +--------------+---------+-------------+ > >> | config | 7.19.1 | 0..1 | > >> | default | 7.6.4 | 0..1 | > >> | mandatory | 7.6.5 | 0..1 | > >> | max-elements | 7.7.4 | 0..1 | > >> | min-elements | 7.7.3 | 0..1 | > >> | must | 7.5.3 | 0..n | > >> | type | 7.4 | 0..1 | > >> | unique | 7.8.3 | 0..n | > >> | units | 7.3.3 | 0..1 | > >> +--------------+---------+-------------+ > >> > >> > >> > >> > >> > > IMO ephemeral data support needs to be a real statement > >> > > that can be used with refine-stmt and deviate-stmt. > >> > > It is a real property of a data node. > >> > > >> > Note: it is still not clear that such a statement (base or = extension) > >> > is needed at all. > >> > > >> > > >> > >> Maybe not to you, but according to the I2RS ephemeral requirements, > >> it is needed, so unless you have a better plan, this is the = default. > >> > >> Explain how ephemeral state can be identified within a data node. > >> It must be possible to use groupings to define such data nodes. > >> If must be possible to refine these groupings. > >> It must be possible for a vendor to write deviation statements. > >> All YANG tools must recognize the ephemeral data property. > >> It should not be isolated to a particular YANG module, which would > >> create a dependency in all future YANG modules. > >> > >> > >> Andy > >> > >> > >> > >> > >> > >> > > >> > /martin > >> > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jul 31 07:54:19 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 268B11A896F for ; Fri, 31 Jul 2015 07:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 EngBdfCYaVoZ for ; Fri, 31 Jul 2015 07:54:15 -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 035F91A8908 for ; Fri, 31 Jul 2015 07:54:04 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so47810865lbb.0 for ; Fri, 31 Jul 2015 07:54: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=b0wO0ISrl4EQgjNjC80bHw1ZD56//7MtM8zKko5xTyc=; b=B3cQXXcaCXlFrcJAjdtBZ+XWrPrXWHlB1uWsyZTf1pN2doMiV9fGeyT2ifMmCFemyJ O7pL7RK+ocfuq/JqEbWfu3XtwZoZu3qGIFM4fXodY48Swul1dJi+1+g4fRzXWrDupbxy 1FShmPaJEWoWE1SfEYCbjumeNZzJIkdOwj+XRnzAXixSr3CImxsRwakZCp0DJsLbb8vR t8HT4f/IZsTSpZqj61e5EaC3ugVMlrbFqTHExCmfRUXfx0/SQChNx/ZLbodeswmKLVZF +WRAifocfiQYF+KQKq+3vMDi1NkaxOUFWBMg8ZayknIu43JiWXkRB1cjPyur6QvfXbOS /Vzg== X-Gm-Message-State: ALoCoQn6wRQB3BstYurfNcy6XJCPzSc5vUcSaZr2ItGNK92bZ+TgmLJ4DzUAfUSFVwdx2UxhKNwD MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr3381736lbp.88.1438354442354; Fri, 31 Jul 2015 07:54:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 31 Jul 2015 07:54:02 -0700 (PDT) In-Reply-To: <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> Date: Fri, 31 Jul 2015 07:54:02 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113403d89919ab051c2cfd92 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 14:54:18 -0000 --001a113403d89919ab051c2cfd92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka wrote: > > > On 31 Jul 2015, at 14:40, Andy Bierman wrote: > > > > > > > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Andy Bierman wrote: > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund > wrote: > > >> > > >> > Andy Bierman wrote: > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund < > mbj@tail-f.com> > > >> > wrote: > > >> > > > > >> > > > Andy Bierman wrote: > > >> > > > > Hi, > > >> > > > > > > >> > > > > I understand the intent is that an implementation of NACM > > >> > > > > has to understand these NACM extensions. I agree with Lada > > >> > > > > that the YANG text about MAY ignore extensions casts doubt > whether > > >> > > > > this sort of NACM rule is enforceable or specified correctly= . > > >> > > > > > >> > > > So do you agree that it would be a good idea to clarify this > > >> > > > according to Juergen's suggestion? > > >> > > > > > >> > > > > > >> > > > > > >> > > Not really. > > >> > > Pretending the extension is just another description-stmt > > >> > > does not really fix anything. > > >> > > > > >> > > A real YANG statement like config-stmt or a new statement > > >> > > called ephemeral-stmt can be modified with refine-stmt > > >> > > or deviate-stmt. This can never happen for > > >> > > an external statement. > > >> > > > >> > There are two separate issues here: > > >> > > > >> > 1) It seems we are in agreement that if a model uses an extension > > >> > statement, it is normative (like ietf-system's usage of nacm:*)= . > > >> > > > >> > Should we somehow clarify this in 6020bis? > > >> > > > >> > 2) Extensions cannot be refined or deviated. > > >> > > > >> > Actually, the *syntax* rules allows things like: > > >> > > > >> > deviation /x:foo { > > >> > deviate replace { > > >> > i2rs:ephemeral true; > > >> > } > > >> > } > > >> > > > >> > I agree that it not clear what this means, but we could also > > >> > clarify this in 6020bis. > > >> > > > >> > > > >> > > >> But this will take even longer than just defining the statements tha= t > > >> are needed for ephemeral state, so no point in doing that. > > >> > > >> The text in 7.18.3.2 clearly does not support the example above at > all. > > > > > > The grammar allows extensions everywhere, so the example is (as I > > > wrote) syntactically valid. > > > > > >> Only one of the keywords listed in the table are supported. > > > > > > The text doesn't say so, and anyway my point was that - regardless of > > > the outcome of the ephemeral dicussion - it might be a good a idea to > > > clarify that extensions can be deviated as well. > > > > +1 > > > > > > So you are saying that a tool MAY ignore any extension, except > > inside a deviation-stmt? Then it becomes mandatory to support? > > > > Or do you mean: > > > > Yes you can put extension-stmts anywhere, but also, yes the tool > > MAY ignore every single extension (everywhere, including inside a > > deviation-stmt) > > I understood Martin=E2=80=99s proposal so that a device that doesn=E2=80= =99t support an > extension used in modules it advertises will have to put it in a > =E2=80=9Cnot-supported=E2=80=9D deviation. > > So features are all "not-supported" by default. but extensions, which a tool MAY ignore, are all supported by default? A server would be required to identify and remember all extensions used? And what about nested extensions: acme:foo test1 { acme:foo2 test2; } The server would be required to completely parse all extensions, and not skip over them? Just to list them as deviations? I think extensions should be like features and the server should advertise them if they are supported. I don't agree that "external-stmt" should be under YANG conformance at all. That is why MAY skip over is in the text. A tool that understands the extension is purely optional. Lada > > Andy > > > > > > > > Lada > > > > Andy > > > > > > > > > > /martin > > > > > >> > > >> > > >> The substatement's keyword MUST match a corresponding > > >> keyword in the target node, and the argument's string MUST be equ= al > > >> to the corresponding keyword's argument string in the target node= . > > >> > > >> The deviates's Substatements > > >> > > >> +--------------+---------+-------------+ > > >> | substatement | section | cardinality | > > >> +--------------+---------+-------------+ > > >> | config | 7.19.1 | 0..1 | > > >> | default | 7.6.4 | 0..1 | > > >> | mandatory | 7.6.5 | 0..1 | > > >> | max-elements | 7.7.4 | 0..1 | > > >> | min-elements | 7.7.3 | 0..1 | > > >> | must | 7.5.3 | 0..n | > > >> | type | 7.4 | 0..1 | > > >> | unique | 7.8.3 | 0..n | > > >> | units | 7.3.3 | 0..1 | > > >> +--------------+---------+-------------+ > > >> > > >> > > >> > > >> > > >> > > IMO ephemeral data support needs to be a real statement > > >> > > that can be used with refine-stmt and deviate-stmt. > > >> > > It is a real property of a data node. > > >> > > > >> > Note: it is still not clear that such a statement (base or > extension) > > >> > is needed at all. > > >> > > > >> > > > >> > > >> Maybe not to you, but according to the I2RS ephemeral requirements, > > >> it is needed, so unless you have a better plan, this is the default. > > >> > > >> Explain how ephemeral state can be identified within a data node. > > >> It must be possible to use groupings to define such data nodes. > > >> If must be possible to refine these groupings. > > >> It must be possible for a vendor to write deviation statements. > > >> All YANG tools must recognize the ephemeral data property. > > >> It should not be isolated to a particular YANG module, which would > > >> create a dependency in all future YANG modules. > > >> > > >> > > >> Andy > > >> > > >> > > >> > > >> > > >> > > >> > > > >> > /martin > > >> > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a113403d89919ab051c2cfd92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 31 Jul 2015, at 14:40, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com<= /a>> writes:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>
> >> > Andy Bierman <a= ndy@yumaworks.com> wrote:
> >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = <mbj@tail-f.com>
> >> > wrote:
> >> > >
> >> > > > Andy Bierman <andy@yumaworks.com> wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I understand the intent is that an implem= entation of NACM
> >> > > > > has to understand these NACM extensions.= =C2=A0 I agree with Lada
> >> > > > > that the YANG text about MAY ignore exten= sions casts doubt whether
> >> > > > > this sort of NACM rule is enforceable or = specified correctly.
> >> > > >
> >> > > > So do you agree that it would be a good idea t= o clarify this
> >> > > > according to Juergen's suggestion?
> >> > > >
> >> > > >
> >> > > >
> >> > > Not really.
> >> > > Pretending the extension is just another descriptio= n-stmt
> >> > > does not really fix anything.
> >> > >
> >> > > A real YANG statement like config-stmt or a new sta= tement
> >> > > called ephemeral-stmt can be modified with refine-s= tmt
> >> > > or deviate-stmt.=C2=A0 =C2=A0This can never happen = for
> >> > > an external statement.
> >> >
> >> > There are two separate issues here:
> >> >
> >> > 1) It seems we are in agreement that if a model uses an = extension
> >> >=C2=A0 =C2=A0 statement, it is normative (like ietf-syste= m's usage of nacm:*).
> >> >
> >> >=C2=A0 =C2=A0 Should we somehow clarify this in 6020bis?<= br> > >> >
> >> > 2) Extensions cannot be refined or deviated.
> >> >
> >> >=C2=A0 =C2=A0 Actually, the *syntax* rules allows things = like:
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 deviation /x:foo {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviate replace {
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2rs:ephemeral true; > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >> >=C2=A0 =C2=A0 =C2=A0 }
> >> >
> >> >=C2=A0 =C2=A0 I agree that it not clear what this means, = but we could also
> >> >=C2=A0 =C2=A0 clarify this in 6020bis.
> >> >
> >> >
> >>
> >> But this will take even longer than just defining the stateme= nts that
> >> are needed for ephemeral state, so no point in doing that. > >>
> >> The text in=C2=A0 7.18.3.2 clearly does not support the examp= le above at all.
> >
> > The grammar allows extensions everywhere, so the example is (as I=
> > wrote) syntactically valid.
> >
> >> Only one of the keywords listed in the table are supported. > >
> > The text doesn't say so, and anyway my point was that - regar= dless of
> > the outcome of the ephemeral dicussion - it might be a good a ide= a to
> > clarify that extensions can be deviated as well.
>
> +1
>
>
> So you are saying that a tool MAY ignore any extension, except
> inside a deviation-stmt?=C2=A0 Then it becomes mandatory to support? >
> Or do you mean:
>
> Yes you can put extension-stmts anywhere, but also, yes the tool
> MAY ignore every single extension (everywhere, including inside a
> deviation-stmt)

I understood Martin=E2=80=99s proposal so that a device that doesn=E2=80=99= t support an extension used in modules it advertises will have to put it in= a =E2=80=9Cnot-supported=E2=80=9D deviation.


So features are all "not-supporte= d" by default. but extensions,
which a tool MAY ignore, are = all supported by default?
A server would be required to identify = and remember all
extensions used?=C2=A0 And what about nested ext= ensions:

=C2=A0 =C2=A0 acme:foo test1 {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0acme:foo2 test2;
=C2=A0 =C2=A0 }
=

The server would be required to completely parse all ex= tensions,
and not skip over them? Just to list them as deviations= ?

I think extensions should be like features and t= he server should
advertise them if they are supported.
=
I don't agree that "external-stmt" should be u= nder YANG conformance
at all.=C2=A0 That is why MAY skip over is = in the text.=C2=A0 A tool that
understands the extension is purel= y optional.


Lada


Andy
=C2=A0
>
>
>
> Lada
>
> Andy
>
>
> >
> > /martin
> >
> >>
> >>
> >>=C2=A0 =C2=A0 The substatement's keyword MUST match a corr= esponding
> >>=C2=A0 =C2=A0 keyword in the target node, and the argument'= ;s string MUST be equal
> >>=C2=A0 =C2=A0 to the corresponding keyword's argument stri= ng in the target node.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 The deviates's Substatements
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--------------+---------+-------------+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | substatement | section | cardinality |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--------------+---------+-------------+
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | config=C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.19.1=C2=A0 | 0..1=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | default=C2=A0 =C2=A0 =C2=A0 | 7.6.4=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | mandatory=C2=A0 =C2=A0 | 7.6.5=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | max-elements | 7.7.4=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | min-elements | 7.7.3=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | must=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.5.3=C2=A0 =C2=A0| 0..n=C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.4=C2=A0 =C2=A0 =C2=A0| 0..1=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | unique=C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.8.3=C2=A0 =C2=A0| 0..n=C2=A0 =C2=A0= =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | units=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 7.3.3=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0= =C2=A0 =C2=A0 |
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--------------+---------+-------------+
> >>
> >>
> >>
> >>
> >> > > IMO ephemeral data support needs to be a real state= ment
> >> > > that can be used with refine-stmt and=C2=A0 deviate= -stmt.
> >> > > It is a real property of a data node.
> >> >
> >> > Note: it is still not clear that such a statement (base = or extension)
> >> > is needed at all.
> >> >
> >> >
> >>
> >> Maybe not to you, but according to the I2RS ephemeral require= ments,
> >> it is needed, so unless you have a better plan, this is the d= efault.
> >>
> >> Explain how ephemeral state can be identified within a data n= ode.
> >> It must be possible to use groupings to define such data node= s.
> >> If must be possible to refine these groupings.
> >> It must be possible for a vendor to write deviation statement= s.
> >> All YANG tools must recognize the ephemeral data property. > >> It should not be isolated to a particular YANG module, which = would
> >> create a dependency in all future YANG modules.
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > /martin
> >> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a113403d89919ab051c2cfd92-- From nobody Fri Jul 31 08:38:57 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 5E0B71B2D8B for ; Fri, 31 Jul 2015 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 9NDH2X7xyrXk for ; Fri, 31 Jul 2015 08:38:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19011B2D0E for ; Fri, 31 Jul 2015 08:37:44 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:201f:dab5:2f95:4a7c] (unknown [IPv6:2a01:5e0:29:ffff:201f:dab5:2f95:4a7c]) by mail.nic.cz (Postfix) with ESMTPSA id 28756181425; Fri, 31 Jul 2015 17:37:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438357063; bh=avjSE+Bo3MSZH07qps7jftDvGvwemKtmlE8WgzG5MA4=; h=From:Date:To; b=XZ+s6kBgbeRgQoKy3nh9IxExaTLxNl7UGR/OjuHnHAfTClLnxB9+OW7wKfdf1qJYt 5C4hYgX+cOK26iAgPMqfg8xw04C1JkiO/4TxK2RZZDQ5h2CXAqNugxwbyeC1a5UOZW W8ZUcqfMgCbZPGUhix5VqCQmDxxt33dfJLYCOq+Q= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 31 Jul 2015 17:37:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 15:38:56 -0000 > On 31 Jul 2015, at 16:54, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka = wrote: >=20 > > On 31 Jul 2015, at 14:40, Andy Bierman wrote: > > > > > > > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka = wrote: > > Martin Bjorklund writes: > > > > > Andy Bierman wrote: > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund = wrote: > > >> > > >> > Andy Bierman wrote: > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund = > > >> > wrote: > > >> > > > > >> > > > Andy Bierman wrote: > > >> > > > > Hi, > > >> > > > > > > >> > > > > I understand the intent is that an implementation of NACM > > >> > > > > has to understand these NACM extensions. I agree with = Lada > > >> > > > > that the YANG text about MAY ignore extensions casts = doubt whether > > >> > > > > this sort of NACM rule is enforceable or specified = correctly. > > >> > > > > > >> > > > So do you agree that it would be a good idea to clarify = this > > >> > > > according to Juergen's suggestion? > > >> > > > > > >> > > > > > >> > > > > > >> > > Not really. > > >> > > Pretending the extension is just another description-stmt > > >> > > does not really fix anything. > > >> > > > > >> > > A real YANG statement like config-stmt or a new statement > > >> > > called ephemeral-stmt can be modified with refine-stmt > > >> > > or deviate-stmt. This can never happen for > > >> > > an external statement. > > >> > > > >> > There are two separate issues here: > > >> > > > >> > 1) It seems we are in agreement that if a model uses an = extension > > >> > statement, it is normative (like ietf-system's usage of = nacm:*). > > >> > > > >> > Should we somehow clarify this in 6020bis? > > >> > > > >> > 2) Extensions cannot be refined or deviated. > > >> > > > >> > Actually, the *syntax* rules allows things like: > > >> > > > >> > deviation /x:foo { > > >> > deviate replace { > > >> > i2rs:ephemeral true; > > >> > } > > >> > } > > >> > > > >> > I agree that it not clear what this means, but we could also > > >> > clarify this in 6020bis. > > >> > > > >> > > > >> > > >> But this will take even longer than just defining the statements = that > > >> are needed for ephemeral state, so no point in doing that. > > >> > > >> The text in 7.18.3.2 clearly does not support the example above = at all. > > > > > > The grammar allows extensions everywhere, so the example is (as I > > > wrote) syntactically valid. > > > > > >> Only one of the keywords listed in the table are supported. > > > > > > The text doesn't say so, and anyway my point was that - regardless = of > > > the outcome of the ephemeral dicussion - it might be a good a idea = to > > > clarify that extensions can be deviated as well. > > > > +1 > > > > > > So you are saying that a tool MAY ignore any extension, except > > inside a deviation-stmt? Then it becomes mandatory to support? > > > > Or do you mean: > > > > Yes you can put extension-stmts anywhere, but also, yes the tool > > MAY ignore every single extension (everywhere, including inside a > > deviation-stmt) >=20 > I understood Martin=E2=80=99s proposal so that a device that doesn=E2=80= =99t support an extension used in modules it advertises will have to put = it in a =E2=80=9Cnot-supported=E2=80=9D deviation. >=20 >=20 > So features are all "not-supported" by default. but extensions, > which a tool MAY ignore, are all supported by default? I proposed to remove this =E2=80=9CMAY ignore=E2=80=9D text. > A server would be required to identify and remember all > extensions used? And what about nested extensions: >=20 > acme:foo test1 { > acme:foo2 test2; > } >=20 Yes. > The server would be required to completely parse all extensions, > and not skip over them? Just to list them as deviations? >=20 > I think extensions should be like features and the server should > advertise them if they are supported. My idea was that all extensions has to be supported, and those that = aren=E2=80=99t will be declared as not-supported in deviations. >=20 > I don't agree that "external-stmt" should be under YANG conformance > at all. That is why MAY skip over is in the text. A tool that > understands the extension is purely optional. >=20 But then we run into problems if extensions change semantics on the = server side, as with nacm. Lada >=20 > Lada >=20 >=20 > Andy > =20 > > > > > > > > Lada > > > > Andy > > > > > > > > > > /martin > > > > > >> > > >> > > >> The substatement's keyword MUST match a corresponding > > >> keyword in the target node, and the argument's string MUST be = equal > > >> to the corresponding keyword's argument string in the target = node. > > >> > > >> The deviates's Substatements > > >> > > >> +--------------+---------+-------------+ > > >> | substatement | section | cardinality | > > >> +--------------+---------+-------------+ > > >> | config | 7.19.1 | 0..1 | > > >> | default | 7.6.4 | 0..1 | > > >> | mandatory | 7.6.5 | 0..1 | > > >> | max-elements | 7.7.4 | 0..1 | > > >> | min-elements | 7.7.3 | 0..1 | > > >> | must | 7.5.3 | 0..n | > > >> | type | 7.4 | 0..1 | > > >> | unique | 7.8.3 | 0..n | > > >> | units | 7.3.3 | 0..1 | > > >> +--------------+---------+-------------+ > > >> > > >> > > >> > > >> > > >> > > IMO ephemeral data support needs to be a real statement > > >> > > that can be used with refine-stmt and deviate-stmt. > > >> > > It is a real property of a data node. > > >> > > > >> > Note: it is still not clear that such a statement (base or = extension) > > >> > is needed at all. > > >> > > > >> > > > >> > > >> Maybe not to you, but according to the I2RS ephemeral = requirements, > > >> it is needed, so unless you have a better plan, this is the = default. > > >> > > >> Explain how ephemeral state can be identified within a data node. > > >> It must be possible to use groupings to define such data nodes. > > >> If must be possible to refine these groupings. > > >> It must be possible for a vendor to write deviation statements. > > >> All YANG tools must recognize the ephemeral data property. > > >> It should not be isolated to a particular YANG module, which = would > > >> create a dependency in all future YANG modules. > > >> > > >> > > >> Andy > > >> > > >> > > >> > > >> > > >> > > >> > > > >> > /martin > > >> > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jul 31 09:15:30 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 173EC1AC42B for ; Fri, 31 Jul 2015 09:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3Lc4zlxvJrjW for ; Fri, 31 Jul 2015 09:15:25 -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 471391AC40F for ; Fri, 31 Jul 2015 09:15:25 -0700 (PDT) Received: by lacct8 with SMTP id ct8so14087582lac.2 for ; Fri, 31 Jul 2015 09:15: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=LH3HQkTYUAOX93WtNXmKDh1a1rW0p32NXgYwBLyDkWU=; b=D+ssmbHvpoBUWVN60gyNjlQEWojAg+nmgVFrQwSR+wTY5+NF7i8GdPHWP1K0rNYZtd Qs7FdJwjbzlLekKSYPQSlizOy7P9R/HcLjEz5Bc2oUXUxv7nhl69Z4/DajLblnvtc0BO wVc1iVNCu78BIZLg6gcv4MFmX97SDaavU/NRzCEwhQUpIxMGfRRplEv7iNREsNP8mN7M Mjs8Hmiu2V99leo/uR5VS0hcNDv4fwatt3smvIsmii0AGaJ8Wda6W4hZj4YBxlccZ+Jq +lwMcpVtoOrJlWtpZVoowREeoOkJjssM5N3RD+3h49h8FNkzKsNpk3Q5ZiQVh9ohxDPf 1wbA== X-Gm-Message-State: ALoCoQn7bBUX+VMhZGdlFlmpE7NyEl9MzHxmpmZHnbH2DX2eHK9abLG8tl4DsYxJU04LGuBRCzZh MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr3863480lbz.33.1438359323514; Fri, 31 Jul 2015 09:15:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 31 Jul 2015 09:15:23 -0700 (PDT) In-Reply-To: References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> Date: Fri, 31 Jul 2015 09:15:23 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134946c89b0b7051c2e2030 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support 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: Fri, 31 Jul 2015 16:15:29 -0000 --001a1134946c89b0b7051c2e2030 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka wrote: > > > On 31 Jul 2015, at 16:54, Andy Bierman wrote: > > > > > > > > On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka wrote: > > > > > On 31 Jul 2015, at 14:40, Andy Bierman wrote: > > > > > > > > > > > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka > wrote: > > > Martin Bjorklund writes: > > > > > > > Andy Bierman wrote: > > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund > wrote: > > > >> > > > >> > Andy Bierman wrote: > > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund < > mbj@tail-f.com> > > > >> > wrote: > > > >> > > > > > >> > > > Andy Bierman wrote: > > > >> > > > > Hi, > > > >> > > > > > > > >> > > > > I understand the intent is that an implementation of NACM > > > >> > > > > has to understand these NACM extensions. I agree with Lad= a > > > >> > > > > that the YANG text about MAY ignore extensions casts doubt > whether > > > >> > > > > this sort of NACM rule is enforceable or specified > correctly. > > > >> > > > > > > >> > > > So do you agree that it would be a good idea to clarify this > > > >> > > > according to Juergen's suggestion? > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > Not really. > > > >> > > Pretending the extension is just another description-stmt > > > >> > > does not really fix anything. > > > >> > > > > > >> > > A real YANG statement like config-stmt or a new statement > > > >> > > called ephemeral-stmt can be modified with refine-stmt > > > >> > > or deviate-stmt. This can never happen for > > > >> > > an external statement. > > > >> > > > > >> > There are two separate issues here: > > > >> > > > > >> > 1) It seems we are in agreement that if a model uses an extensio= n > > > >> > statement, it is normative (like ietf-system's usage of > nacm:*). > > > >> > > > > >> > Should we somehow clarify this in 6020bis? > > > >> > > > > >> > 2) Extensions cannot be refined or deviated. > > > >> > > > > >> > Actually, the *syntax* rules allows things like: > > > >> > > > > >> > deviation /x:foo { > > > >> > deviate replace { > > > >> > i2rs:ephemeral true; > > > >> > } > > > >> > } > > > >> > > > > >> > I agree that it not clear what this means, but we could also > > > >> > clarify this in 6020bis. > > > >> > > > > >> > > > > >> > > > >> But this will take even longer than just defining the statements > that > > > >> are needed for ephemeral state, so no point in doing that. > > > >> > > > >> The text in 7.18.3.2 clearly does not support the example above a= t > all. > > > > > > > > The grammar allows extensions everywhere, so the example is (as I > > > > wrote) syntactically valid. > > > > > > > >> Only one of the keywords listed in the table are supported. > > > > > > > > The text doesn't say so, and anyway my point was that - regardless = of > > > > the outcome of the ephemeral dicussion - it might be a good a idea = to > > > > clarify that extensions can be deviated as well. > > > > > > +1 > > > > > > > > > So you are saying that a tool MAY ignore any extension, except > > > inside a deviation-stmt? Then it becomes mandatory to support? > > > > > > Or do you mean: > > > > > > Yes you can put extension-stmts anywhere, but also, yes the tool > > > MAY ignore every single extension (everywhere, including inside a > > > deviation-stmt) > > > > I understood Martin=E2=80=99s proposal so that a device that doesn=E2= =80=99t support an > extension used in modules it advertises will have to put it in a > =E2=80=9Cnot-supported=E2=80=9D deviation. > > > > > > So features are all "not-supported" by default. but extensions, > > which a tool MAY ignore, are all supported by default? > > I proposed to remove this =E2=80=9CMAY ignore=E2=80=9D text. > I do not support this change > > > A server would be required to identify and remember all > > extensions used? And what about nested extensions: > > > > acme:foo test1 { > > acme:foo2 test2; > > } > > > > Yes. > > > The server would be required to completely parse all extensions, > > and not skip over them? Just to list them as deviations? > > > > I think extensions should be like features and the server should > > advertise them if they are supported. > > My idea was that all extensions has to be supported, and those that aren= =E2=80=99t > will be declared as not-supported in deviations. > > I do not support this change. Extensions are used to define external statements which are, in fact, not part of the YANG language. (hence the name "external") IMO it is a mistake to try to make them part of YANG and YANG conformance. > > > > I don't agree that "external-stmt" should be under YANG conformance > > at all. That is why MAY skip over is in the text. A tool that > > understands the extension is purely optional. > > > > But then we run into problems if extensions change semantics on the serve= r > side, as with nacm. > > Some people have asked if they can just support the NACM extensions and not the NACM module. A: no. Only the NACM module is required to understand these extensions. They do not affect the syntax or semantics of the tagged objects at all. They only affect access control for those objects. IMO the NACM extensions should be real YANG statements, and then the concepts of 'default-deny-write' and 'default-deny-all' could be implemented without NACM. Lada > Andy > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > > /martin > > > > > > > >> > > > >> > > > >> The substatement's keyword MUST match a corresponding > > > >> keyword in the target node, and the argument's string MUST be > equal > > > >> to the corresponding keyword's argument string in the target > node. > > > >> > > > >> The deviates's Substatements > > > >> > > > >> +--------------+---------+-------------+ > > > >> | substatement | section | cardinality | > > > >> +--------------+---------+-------------+ > > > >> | config | 7.19.1 | 0..1 | > > > >> | default | 7.6.4 | 0..1 | > > > >> | mandatory | 7.6.5 | 0..1 | > > > >> | max-elements | 7.7.4 | 0..1 | > > > >> | min-elements | 7.7.3 | 0..1 | > > > >> | must | 7.5.3 | 0..n | > > > >> | type | 7.4 | 0..1 | > > > >> | unique | 7.8.3 | 0..n | > > > >> | units | 7.3.3 | 0..1 | > > > >> +--------------+---------+-------------+ > > > >> > > > >> > > > >> > > > >> > > > >> > > IMO ephemeral data support needs to be a real statement > > > >> > > that can be used with refine-stmt and deviate-stmt. > > > >> > > It is a real property of a data node. > > > >> > > > > >> > Note: it is still not clear that such a statement (base or > extension) > > > >> > is needed at all. > > > >> > > > > >> > > > > >> > > > >> Maybe not to you, but according to the I2RS ephemeral requirements= , > > > >> it is needed, so unless you have a better plan, this is the defaul= t. > > > >> > > > >> Explain how ephemeral state can be identified within a data node. > > > >> It must be possible to use groupings to define such data nodes. > > > >> If must be possible to refine these groupings. > > > >> It must be possible for a vendor to write deviation statements. > > > >> All YANG tools must recognize the ephemeral data property. > > > >> It should not be isolated to a particular YANG module, which would > > > >> create a dependency in all future YANG modules. > > > >> > > > >> > > > >> Andy > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > /martin > > > >> > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1134946c89b0b7051c2e2030 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 31 Jul 2015, at 16:54, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 31 Jul 2015, at 14:40, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Martin Bjorklund <mbj@tail-f= .com> writes:
> >
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com> wrote:
> > >>
> > >> > Andy Bierman <andy@yumaworks.com> wrote:
> > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjork= lund <mbj@tail-f.com>
> > >> > wrote:
> > >> > >
> > >> > > > Andy Bierman <andy@yumaworks.com> wrote:
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > I understand the intent is that an i= mplementation of NACM
> > >> > > > > has to understand these NACM extensi= ons.=C2=A0 I agree with Lada
> > >> > > > > that the YANG text about MAY ignore = extensions casts doubt whether
> > >> > > > > this sort of NACM rule is enforceabl= e or specified correctly.
> > >> > > >
> > >> > > > So do you agree that it would be a good i= dea to clarify this
> > >> > > > according to Juergen's suggestion? > > >> > > >
> > >> > > >
> > >> > > >
> > >> > > Not really.
> > >> > > Pretending the extension is just another descr= iption-stmt
> > >> > > does not really fix anything.
> > >> > >
> > >> > > A real YANG statement like config-stmt or a ne= w statement
> > >> > > called ephemeral-stmt can be modified with ref= ine-stmt
> > >> > > or deviate-stmt.=C2=A0 =C2=A0This can never ha= ppen for
> > >> > > an external statement.
> > >> >
> > >> > There are two separate issues here:
> > >> >
> > >> > 1) It seems we are in agreement that if a model use= s an extension
> > >> >=C2=A0 =C2=A0 statement, it is normative (like ietf-= system's usage of nacm:*).
> > >> >
> > >> >=C2=A0 =C2=A0 Should we somehow clarify this in 6020= bis?
> > >> >
> > >> > 2) Extensions cannot be refined or deviated.
> > >> >
> > >> >=C2=A0 =C2=A0 Actually, the *syntax* rules allows th= ings like:
> > >> >
> > >> >=C2=A0 =C2=A0 =C2=A0 deviation /x:foo {
> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviate replace {
> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2rs:ephemeral tr= ue;
> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >> >=C2=A0 =C2=A0 =C2=A0 }
> > >> >
> > >> >=C2=A0 =C2=A0 I agree that it not clear what this me= ans, but we could also
> > >> >=C2=A0 =C2=A0 clarify this in 6020bis.
> > >> >
> > >> >
> > >>
> > >> But this will take even longer than just defining the st= atements that
> > >> are needed for ephemeral state, so no point in doing tha= t.
> > >>
> > >> The text in=C2=A0 7.18.3.2 clearly does not support the = example above at all.
> > >
> > > The grammar allows extensions everywhere, so the example is = (as I
> > > wrote) syntactically valid.
> > >
> > >> Only one of the keywords listed in the table are support= ed.
> > >
> > > The text doesn't say so, and anyway my point was that - = regardless of
> > > the outcome of the ephemeral dicussion - it might be a good = a idea to
> > > clarify that extensions can be deviated as well.
> >
> > +1
> >
> >
> > So you are saying that a tool MAY ignore any extension, except > > inside a deviation-stmt?=C2=A0 Then it becomes mandatory to suppo= rt?
> >
> > Or do you mean:
> >
> > Yes you can put extension-stmts anywhere, but also, yes the tool<= br> > > MAY ignore every single extension (everywhere, including inside a=
> > deviation-stmt)
>
> I understood Martin=E2=80=99s proposal so that a device that doesn=E2= =80=99t support an extension used in modules it advertises will have to put= it in a =E2=80=9Cnot-supported=E2=80=9D deviation.
>
>
> So features are all "not-supported" by default. but extensio= ns,
> which a tool MAY ignore, are all supported by default?

I proposed to remove this =E2=80=9CMAY ignore=E2=80=9D text.


I do not support this change

=C2=A0

> A server would be required to identify and remember all
> extensions used?=C2=A0 And what about nested extensions:
>
>=C2=A0 =C2=A0 =C2=A0acme:foo test1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 acme:foo2 test2;
>=C2=A0 =C2=A0 =C2=A0}
>

Yes.

> The server would be required to completely parse all extensions,
> and not skip over them? Just to list them as deviations?
>
> I think extensions should be like features and the server should
> advertise them if they are supported.

My idea was that all extensions has to be supported, and those that aren=E2= =80=99t will be declared as not-supported in deviations.


I do not support this change.
Extensions are used to define external statements
which are, in= fact, not part of the YANG language.
(hence the name "exter= nal")

IMO it is a mistake to try to make them= part of YANG and
YANG conformance.

=C2= =A0
>
> I don't agree that "external-stmt" should be under YANG = conformance
> at all.=C2=A0 That is why MAY skip over is in the text.=C2=A0 A tool t= hat
> understands the extension is purely optional.
>

But then we run into problems if extensions change semantics on the server = side, as with nacm.



Some people have asked = if they can just support the NACM extensions
and not the NACM mod= ule. A: no. Only the NACM module is required
to understand these = extensions.=C2=A0 They do not affect the
syntax or semantics of t= he tagged objects at all.
They only affect access control for tho= se objects.
IMO the NACM extensions should be real YANG statement= s,
and then the concepts of 'default-deny-write' and '= ;default-deny-all'
could be implemented without NACM.



Lada

Andy
=C2=A0

>
> Lada
>
>
> Andy
>
> >
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > > /martin
> > >
> > >>
> > >>
> > >>=C2=A0 =C2=A0 The substatement's keyword MUST match a= corresponding
> > >>=C2=A0 =C2=A0 keyword in the target node, and the argumen= t's string MUST be equal
> > >>=C2=A0 =C2=A0 to the corresponding keyword's argument= string in the target node.
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 The deviates's Substatements
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------------+---------+-------------+
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | substatement | section | cardinality |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------------+---------+-------------+
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | config=C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.19.1=C2=A0 | 0..1=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | default=C2=A0 =C2=A0 =C2=A0 | 7.6.4=C2=A0 =C2=A0| 0..1=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | mandatory=C2=A0 =C2=A0 | 7.6.5=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | max-elements | 7.7.4=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0= |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | min-elements | 7.7.3=C2=A0 =C2=A0| 0..1=C2=A0 =C2=A0 =C2=A0 =C2=A0= |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | must=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.5.3=C2=A0 =C2=A0| 0..n= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.4=C2=A0 =C2=A0 =C2=A0| 0= ..1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | unique=C2=A0 =C2=A0 =C2=A0 =C2=A0| 7.8.3=C2=A0 =C2=A0| 0..n=C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | units=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 7.3.3=C2=A0 =C2=A0| 0..1=C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------------+---------+-------------+
> > >>
> > >>
> > >>
> > >>
> > >> > > IMO ephemeral data support needs to be a real = statement
> > >> > > that can be used with refine-stmt and=C2=A0 de= viate-stmt.
> > >> > > It is a real property of a data node.
> > >> >
> > >> > Note: it is still not clear that such a statement (= base or extension)
> > >> > is needed at all.
> > >> >
> > >> >
> > >>
> > >> Maybe not to you, but according to the I2RS ephemeral re= quirements,
> > >> it is needed, so unless you have a better plan, this is = the default.
> > >>
> > >> Explain how ephemeral state can be identified within a d= ata node.
> > >> It must be possible to use groupings to define such data= nodes.
> > >> If must be possible to refine these groupings.
> > >> It must be possible for a vendor to write deviation stat= ements.
> > >> All YANG tools must recognize the ephemeral data propert= y.
> > >> It should not be isolated to a particular YANG module, w= hich would
> > >> create a dependency in all future YANG modules.
> > >>
> > >>
> > >> Andy
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> >
> > >> > /martin
> > >> >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a1134946c89b0b7051c2e2030-- From nobody Fri Jul 31 10:07:08 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 E8C1C1A884F for ; Fri, 31 Jul 2015 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 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_210=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 x7zUj8bc3hhS for ; Fri, 31 Jul 2015 10:06:59 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 36DE31B2EFE for ; Fri, 31 Jul 2015 10:06:59 -0700 (PDT) Received: (qmail 19969 invoked by uid 0); 31 Jul 2015 17:06:58 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 31 Jul 2015 17:06:58 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id z4mq1q00R2SSUrH014mtdY; Fri, 31 Jul 2015 10:46:55 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=xskcdSivAAAA:8 a=VvmPA7fAAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=j3Z76cjpAAAA:8 a=R6xbwTdjTzjX2Zpa4VgA:9 a=yFXKeuQivpldNszv:21 a=ps2uKiEWRuqMqTyL:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=utQ-ZuE7t14A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=WXV026hp5qeqrkAz/LbFQuVOOwGSRXtKBlk0XLPxxRM=; b=wGLqV8blDHiQ5whoQeS3xJqvG8Z5EZygEYb0cpujzRJ+DIWDAslgRbxG/pulCi40I+iE0v/vV31NSjliWRuPWR7a6JI4T7+NRUpEU4YFadSvshxFeRV+58/NxbqucsDz; Received: from box313.bluehost.com ([69.89.31.113]:39453 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZLDSN-0003Di-SF; Fri, 31 Jul 2015 10:46:52 -0600 Message-ID: <55BBA679.7070508@labn.net> Date: Fri, 31 Jul 2015 12:46:49 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Bierman References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Fri, 31 Jul 2015 17:07:07 -0000 Andy, On 07/27/2015 12:58 PM, Andy Bierman wrote: > Hi, > > I don't think a standard for relocating subtrees would be worth it. > I am not in favor of moving /interfaces or /system to a new location. > That's not how YANG works. It only allows "obsolete and start over". > > I would suggest pursuing solutions that don't cause > as much disruption and expense as possible. > I think it would be really good to explore other, less "disruptive" options. Perhaps you'd be willing to have a brain storming session off-line? (Of course, any proposed changes/approaches would be brought to the WG for normal WG processing.) Lou > For example, a resource directory of symlinks > (YANG leaf, type instance-identifier) would allow > standard or vendor modules to be supported. > The exact location of the data nodes can change over time, > and be different on each server. > > > Andy > > On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger > wrote: > > Andy, > > Thanks for the good information. (I'll followup off line a bit if > that's okay.) Of course there's a small matter of getting something > standardized. > > Lou > > On July 27, 2015 2:19:09 AM Andy Bierman > wrote: > >> >> >> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger > > wrote: >> >> Andy, >> >> Have you thought through implications / possibilities for >> existing models, e.g., interfaces? >> >> >> >> First we have to define various forms of relocation. >> >> (1) Aggregation of datastores >> >> The simplest form is aggregation. >> It is possible to define a YANG container that is a conceptual >> document root, such that the set of child nodes matches the set >> of top-level YANG data nodes supported by the server. >> >> A YANG extension can mark a YANG container or anyxml as a docroot. >> Yuma-based code has been doing this for years with a YANG >> extension called "root" >> >> http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 >> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html >> (See Y34-04) >> >> The node below is a document root: >> >> container servers { >> list server { >> key addr; >> leaf addr { type inet:ip-address; } >> anydata config { >> ncx:root; >> } >> } >> } >> >> XPath evaluation requires certain inputs, including a context node >> and a document root. The 'root' extension tells the tool to use >> the node with the 'root' tag as the document root, when processing >> XPath within its descendant nodes. Without the tag, the XPath parser >> would use 'servers' as the document root, which is incorrect for >> the relocated YANG nodes within 'config'. >> >> (2) Move a subtree within the datastore >> >> This is the hardest (of course) because it involves moving the >> context node >> not the document root. It is possible for tools to get fooled >> about the intent >> of the XPath writer. Basically the tool has to remember the >> original context node, >> and do some complicated data manipulation, processing [4] Step >> in XPath 1.0. Multiple relocated subtrees gets even more complicated. >> >> It may be possible to come up with some guidelines on XPath to avoid. >> Basically any Xpath that selects nodes by specific names can be >> relocated automatically. Nodes selected by function, wildcard, >> axis, etc. >> will not be so easy. >> >> >> >> >> Thanks, >> Lou >> >> >> >> Andy >> >> >> On July 26, 2015 4:41:32 PM Andy Bierman > > wrote: >> >>> Hi Acee, >>> >>> I agree that "Relocatable YANG" would be very useful, and >>> have been >>> thinking about the problem for awhile. I think the key is to >>> precisely >>> define a protocol-independent document root for each of the >>> various >>> YANG XPath contexts. In most cases the expression can be >>> automatically relocated to an ancestor root. For the rest, a >>> YANG mechanism is needed to tell the compiler to force evaluation >>> on the old docroot (not the new docroot ancestor). >>> >>> >>> Andy >>> >>> >>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) >>> > wrote: >>> >>> I think being able to place a given model anywhere in the >>> device tree >>> would be useful and this would allow a model to be rooted >>> in different >>> locations on different devices. Similarly, we’d need the >>> ability to prefix >>> XPATH references to data nodes in the model with the root. >>> Thanks, >>> Acee >>> >>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen >>> Schoenwaelder" >>> >>> on behalf of >>> j.schoenwaelder@jacobs-university.de >>> > wrote: >>> >>> >Lada, >>> > >>> >Y34 is closed and I have not seen any new argument here >>> that indicates >>> >we made a major mistake with the resolution of Y34. As >>> such, Y34 >>> >remains closed. >>> > >>> >If you want to discuss new ideas to relocate or >>> "symlink" data models, >>> >please do so in a separate thread. (And no, we do not >>> accept new >>> >issues for YANG 1.1 either at this point in time.) >>> > >>> >/js >>> > >>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav >>> Lhotka wrote: >>> >> >>> >> > On 20 Jul 2015, at 19:29, Andy Bierman >>> > wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka >>> > >>> >>wrote: >>> >> > >>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman >>> > wrote: >>> >> > > >>> >> > > >>> >> > > >>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka >>> > >>> >>wrote: >>> >> > > >>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman >>> > wrote: >>> >> > > > >>> >> > > > Hi, >>> >> > > > >>> >> > > > Can you explain why we need 2 broken anyxmls? >>> >> > > > (The original and a synonym?) The whole point of >>> >> > > > anydata is that it does not have XML cruft in it. >>> >> > > >>> >> > > Yes, I understand this was your main priority. For >>> implementors >>> >>using off-the-shelf XML parsers and tools the XML cruft >>> is not an issue >>> >>at all. >>> >> > > >>> >> > > >>> >> > > yes it is an issue. >>> >> > > We need something to model a container full of >>> arbitrary YANG data >>> >>nodes. >>> >> > > This is something that can be applied to the >>> contents of a >>> >>datastore. >>> >> > >>> >> > anyxml can do that, too. >>> >> > >>> >> > >>> >> > the WG already decided it can't. >>> >> > The extra XML PIs, etc. are not accepted by all >>> servers, remember? >>> >> > There is no use for the extra stuff in the datastore. >>> >> > I don't see why we need 2 anyxml constructs that >>> are not >>> >> > supported by the industry. One is already too many. >>> >> >>> >> I agree, but this is what we are going to have. My >>> proposal was to have >>> >>just one with two different names. >>> >> >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > Anyway, I believe there are use cases for >>> arbitrary XML/JSON/CBOR/… >>> >>with no (YANG) schema available. My only complaint to >>> “anyxml” has >>> >>always been that it is a misnomer for encodings other >>> than XML. >>> >> > > >>> >> > > The message encoding on the wire is not the same issue >>> >> > > as the contents of a datastore. Our server stores >>> its own >>> >> > > internal data structures. XML, JSON, CBOR are >>> just message >>> >> > > encoding formats between client and server. The >>> datastore >>> >> > > is not encoded in any of these formats. >>> >> > >>> >> > The payload of anyxml needn’t directly map to a data >>> subtree in the >>> >>usual sense. >>> >> > >>> >> > that's precisely the difference between anyxml and >>> anydata. >>> >> > The anydata node MUST map directly into data subtrees. >>> >> >>> >> If the server doesn’t know the YANG data model at run >>> time (which is >>> >>possible) then it cannot do it - for instance, it >>> cannot properly map >>> >>module names to namespace URI or handle lists. >>> >> >>> >> > >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > I also don't get the value of a single top-level >>> node called >>> >>'device' >>> >> > > > that every YANG model on the planet is supposed >>> to augment. >>> >> > > > Can you explain why a protocol operation to >>> retrieve the >>> >> > > > document root (/) is not sufficient for the >>> top-level node? >>> >> > > >>> >> > > I don’t intend to defend their model, the more >>> serious problem IMO >>> >>is that a model for a single device/function may be >>> needed in another >>> >>device that hosts many virtualised devices/functions of >>> the former type. >>> >>We don’t have a good solution for this rather typical >>> situation. >>> >> > > >>> >> > > But a single container called "whatever" provides >>> no such >>> >>aggregation. >>> >> > > You would need a list for that. And the NMS might >>> have multiple >>> >> > > layers of hierarchy to represent various >>> aggregations. The NP >>> >> > > container called "device" is not helpful for >>> aggregation. >>> >> > >>> >> > The parent node can be a list as well. The “root” >>> node would be like >>> >>a mount point in a Unix filesystem. >>> >> > >>> >> > >>> >> > Are you saying all data on a device needs to be in a >>> top-level list >>> >>called 'device' >>> >> > because an NMS might exist that wants to have the >>> datastores from >>> >>lots of devices? >>> >> > As Martin pointed out several times, the NMS can >>> make its own >>> >>container or >>> >> > lists. It does not need the device to mirror its >>> own structure. >>> >> >>> >> As I said, I don’t care that much about the “device” >>> container. What >>> >>would be really useful is to have the possibility to do >>> e.g. this: >>> >> >>> >> virtual-node* [name] >>> >> name >>> >> if:interfaces >>> >> ... >>> >> >>> >> to support the use case where all virtual nodes are >>> managed by the same >>> >>NETCONF/RESTCONF server. >>> >> >>> >> Lada >>> >> >>> >> > >>> >> > >>> >> > >>> >> > Lada >>> >> > >>> >> > Andy >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > Lada >>> >> > > >>> >> > > >>> >> > > Andy >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > Andy >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka >>> > >>> >>wrote: >>> >> > > > >>> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka >>> > wrote: >>> >> > > > > >>> >> > > > > Hi, >>> >> > > > > >>> >> > > > > after listening to the presentation of >>> >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG >>> session, I am >>> >>wondering >>> >> > > > > whether the solution chosen for Y34 is really >>> useful. >>> >> > > > > >>> >> > > > > The draft states they want to reuse >>> ietf-interfaces but their >>> >>tree in >>> >> > > > > fact is >>> >> > > > > >>> >> > > > > +--rw device >>> >> > > > > +--rw info >>> >> > > > > | +--rw device-type? enumeration >>> >> > > > > +--rw hardware >>> >> > > > > +--rw interfaces >>> >> > > > > | +--rw interface* [name] >>> >> > > > > | ... >>> >> > > > > +--rw qos >>> >> > > > > >>> >> > > > > So the "interfaces" container is no more a >>> top-level node. >>> >>There are >>> >> > > > > three possible options: >>> >> > > > > >>> >> > > > > 1. Change the ietf-interfaces module. >>> >> > > > > 2. Replicate its contents in another module. >>> >> > > > > 3. Extend YANG so that a *specific* schema >>> tree can be grafted >>> >>at a >>> >> > > > > given data node. >>> >> > > > > >>> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 >>> was essentially #3 >>> >>but it >>> >> > > > > seems it is not so because it doesn't specify >>> a concrete data >>> >>model >>> >> > > > > that's allowed at a given location. >>> >> > > > > >>> >> > > > > On the other hand, the only real contribution >>> of "anydata" over >>> >>"anyxml" >>> >> > > > > is that is doesn't permit mixed content in >>> XML, which is IMO >>> >>not much. >>> >> > > > > >>> >> > > > > I know Y34 was already closed but I think it >>> is more important >>> >>to do >>> >> > > > > things right before YANG 1.1 becomes an RFC. >>> >> > > > > >>> >> > > > > What I want to propose is this: >>> >> > > > > >>> >> > > > > - Rename "anydata" as a synonym to "anyxml", >>> and deprecate >>> >>"anyxml" (but >>> >> > > > > keep it for backward compatibility). >>> >> > > > >>> >> > > > s/Rename/Introduce/ >>> >> > > > >>> >> > > > > >>> >> > > > > - Introduce a new statement and data node >>> type, e.g. "root", >>> >>that will >>> >> > > > > extend the schema tree starting from that >>> data node with a >>> >>precisely >>> >> > > > > specified data model. The specification can >>> be same or similar >>> >>as >>> >> > > > > in yang-library. >>> >> > > > > >>> >> > > > > I believe there are other use cases in the >>> existing modules. For >>> >> > > > > example, the ietf-routing module could simply >>> define the data >>> >>model for >>> >> > > > > a single routing instance (i.e. without >>> "routing-instance" list >>> >>at the >>> >> > > > > top), and it can be then used without changes >>> on simple >>> >>devices, and >>> >> > > > > more complex router implementations can graft >>> it as a subtree >>> >>under >>> >> > > > > "routing-instance", "networking-instance" or >>> whatever. >>> >> > > > > >>> >> > > > > Lada >>> >> > > > > >>> >> > > > > -- >>> >> > > > > 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 >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > _______________________________________________ >>> >> > > > 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 >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > 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 >>> > >>> >-- >>> >Juergen Schoenwaelder Jacobs University Bremen >>> gGmbH >>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 >>> Bremen | Germany >>> >Fax: +49 421 200 3103 >>> >>> > >>> >_______________________________________________ >>> >netmod mailing list >>> >netmod@ietf.org >>> >https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> > From nobody Fri Jul 31 12:05:47 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 9FDFF1B2E8A for ; Fri, 31 Jul 2015 12:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_210=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 rwAn0Pbl_Te6 for ; Fri, 31 Jul 2015 12:05:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.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 47CE31B2E40 for ; Fri, 31 Jul 2015 12:05:40 -0700 (PDT) Received: by obbop1 with SMTP id op1so60775501obb.2 for ; Fri, 31 Jul 2015 12:05:39 -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=g0ut8AhRJsRUK0h8I3oxjH4rq8DhsJaRqhh8H76wATA=; b=UiM/C4G50m/vqadveqkSzusg6Jw0tSUq7J0WOTPrxBiyvIgweJf2FTw4rbYAOgSiUc ubphOnumsOLWo1xlXQD/NcObWCA9DVQ3nr4RWn7ysVLMJMG2ieTVe8P+KFU9XB+WagKI 09wVV6ezgulTz23NTN3BPS5L1qqYTCxdjxxxOL9FfZXgOA5IbxX52j/H2WJwGCGoyp5a OTbCPTJGrzuaLpIwRX8ymT9tcWOArtZF5H1VrhQRwdQgKQO8Je4vwIaqZzFy9jmjvXc2 YpGCiWFkBH6Ba1UZJiF/Ctt0rhb7jkVPVdnEP2M1ADVbWcuNdKYfotvSqBcuKn5Uk0Ep t+GA== X-Gm-Message-State: ALoCoQl+45Q+HR8lM1kMthHOPeuvuMyAHILudkgZWIU/skNlyjVC3jdS4Ui0guaNruoTyq8pNNx2 MIME-Version: 1.0 X-Received: by 10.60.39.136 with SMTP id p8mr4933147oek.45.1438369539640; Fri, 31 Jul 2015 12:05:39 -0700 (PDT) Received: by 10.202.189.196 with HTTP; Fri, 31 Jul 2015 12:05:39 -0700 (PDT) In-Reply-To: <55BBA679.7070508@labn.net> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> Date: Fri, 31 Jul 2015 12:05:39 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=089e0160bd10777353051c308174 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Fri, 31 Jul 2015 19:05:46 -0000 --089e0160bd10777353051c308174 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2015 at 9:46 AM, Lou Berger wrote: > Andy, > > On 07/27/2015 12:58 PM, Andy Bierman wrote: > > Hi, > > > > I don't think a standard for relocating subtrees would be worth it. > > I am not in favor of moving /interfaces or /system to a new location. > > That's not how YANG works. It only allows "obsolete and start over". > > > > I would suggest pursuing solutions that don't cause > > as much disruption and expense as possible. > > > > I think it would be really good to explore other, less "disruptive" > options. > > Perhaps you'd be willing to have a brain storming session off-line? (Of > course, any proposed changes/approaches would be brought to the WG for > normal WG processing.) > > OK -- send an email invite to the meeting. > Lou > > Andy > > For example, a resource directory of symlinks > > (YANG leaf, type instance-identifier) would allow > > standard or vendor modules to be supported. > > The exact location of the data nodes can change over time, > > and be different on each server. > > > > > > Andy > > > > On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger > > wrote: > > > > Andy, > > > > Thanks for the good information. (I'll followup off line a bit if > > that's okay.) Of course there's a small matter of getting something > > standardized. > > > > Lou > > > > On July 27, 2015 2:19:09 AM Andy Bierman > > wrote: > > > >> > >> > >> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger >> > wrote: > >> > >> Andy, > >> > >> Have you thought through implications / possibilities for > >> existing models, e.g., interfaces? > >> > >> > >> > >> First we have to define various forms of relocation. > >> > >> (1) Aggregation of datastores > >> > >> The simplest form is aggregation. > >> It is possible to define a YANG container that is a conceptual > >> document root, such that the set of child nodes matches the set > >> of top-level YANG data nodes supported by the server. > >> > >> A YANG extension can mark a YANG container or anyxml as a docroot. > >> Yuma-based code has been doing this for years with a YANG > >> extension called "root" > >> > >> http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554 > >> > >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html > >> (See Y34-04) > >> > >> The node below is a document root: > >> > >> container servers { > >> list server { > >> key addr; > >> leaf addr { type inet:ip-address; } > >> anydata config { > >> ncx:root; > >> } > >> } > >> } > >> > >> XPath evaluation requires certain inputs, including a context node > >> and a document root. The 'root' extension tells the tool to use > >> the node with the 'root' tag as the document root, when processing > >> XPath within its descendant nodes. Without the tag, the XPath pars= er > >> would use 'servers' as the document root, which is incorrect for > >> the relocated YANG nodes within 'config'. > >> > >> (2) Move a subtree within the datastore > >> > >> This is the hardest (of course) because it involves moving the > >> context node > >> not the document root. It is possible for tools to get fooled > >> about the intent > >> of the XPath writer. Basically the tool has to remember the > >> original context node, > >> and do some complicated data manipulation, processing [4] Step > >> in XPath 1.0. Multiple relocated subtrees gets even more > complicated. > >> > >> It may be possible to come up with some guidelines on XPath to > avoid. > >> Basically any Xpath that selects nodes by specific names can be > >> relocated automatically. Nodes selected by function, wildcard, > >> axis, etc. > >> will not be so easy. > >> > >> > >> > >> > >> Thanks, > >> Lou > >> > >> > >> > >> Andy > >> > >> > >> On July 26, 2015 4:41:32 PM Andy Bierman >> > wrote: > >> > >>> Hi Acee, > >>> > >>> I agree that "Relocatable YANG" would be very useful, and > >>> have been > >>> thinking about the problem for awhile. I think the key is to > >>> precisely > >>> define a protocol-independent document root for each of the > >>> various > >>> YANG XPath contexts. In most cases the expression can be > >>> automatically relocated to an ancestor root. For the rest, a > >>> YANG mechanism is needed to tell the compiler to force > evaluation > >>> on the old docroot (not the new docroot ancestor). > >>> > >>> > >>> Andy > >>> > >>> > >>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) > >>> > wrote: > >>> > >>> I think being able to place a given model anywhere in the > >>> device tree > >>> would be useful and this would allow a model to be rooted > >>> in different > >>> locations on different devices. Similarly, we=E2=80=99d n= eed the > >>> ability to prefix > >>> XPATH references to data nodes in the model with the root= . > >>> Thanks, > >>> Acee > >>> > >>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen > >>> Schoenwaelder" > >>> > >>> on behalf of > >>> j.schoenwaelder@jacobs-university.de > >>> > wrote: > >>> > >>> >Lada, > >>> > > >>> >Y34 is closed and I have not seen any new argument here > >>> that indicates > >>> >we made a major mistake with the resolution of Y34. As > >>> such, Y34 > >>> >remains closed. > >>> > > >>> >If you want to discuss new ideas to relocate or > >>> "symlink" data models, > >>> >please do so in a separate thread. (And no, we do not > >>> accept new > >>> >issues for YANG 1.1 either at this point in time.) > >>> > > >>> >/js > >>> > > >>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav > >>> Lhotka wrote: > >>> >> > >>> >> > On 20 Jul 2015, at 19:29, Andy Bierman > >>> > wrote: > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka > >>> > > >>> >>wrote: > >>> >> > > >>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman > >>> > wrote: > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka > >>> > > >>> >>wrote: > >>> >> > > > >>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman > >>> > wrote: > >>> >> > > > > >>> >> > > > Hi, > >>> >> > > > > >>> >> > > > Can you explain why we need 2 broken anyxmls? > >>> >> > > > (The original and a synonym?) The whole point o= f > >>> >> > > > anydata is that it does not have XML cruft in it= . > >>> >> > > > >>> >> > > Yes, I understand this was your main priority. For > >>> implementors > >>> >>using off-the-shelf XML parsers and tools the XML cruft > >>> is not an issue > >>> >>at all. > >>> >> > > > >>> >> > > > >>> >> > > yes it is an issue. > >>> >> > > We need something to model a container full of > >>> arbitrary YANG data > >>> >>nodes. > >>> >> > > This is something that can be applied to the > >>> contents of a > >>> >>datastore. > >>> >> > > >>> >> > anyxml can do that, too. > >>> >> > > >>> >> > > >>> >> > the WG already decided it can't. > >>> >> > The extra XML PIs, etc. are not accepted by all > >>> servers, remember? > >>> >> > There is no use for the extra stuff in the datastore= . > >>> >> > I don't see why we need 2 anyxml constructs that > >>> are not > >>> >> > supported by the industry. One is already too many. > >>> >> > >>> >> I agree, but this is what we are going to have. My > >>> proposal was to have > >>> >>just one with two different names. > >>> >> > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > >>> >> > > Anyway, I believe there are use cases for > >>> arbitrary XML/JSON/CBOR/=E2=80=A6 > >>> >>with no (YANG) schema available. My only complaint to > >>> =E2=80=9Canyxml=E2=80=9D has > >>> >>always been that it is a misnomer for encodings other > >>> than XML. > >>> >> > > > >>> >> > > The message encoding on the wire is not the same > issue > >>> >> > > as the contents of a datastore. Our server stores > >>> its own > >>> >> > > internal data structures. XML, JSON, CBOR are > >>> just message > >>> >> > > encoding formats between client and server. The > >>> datastore > >>> >> > > is not encoded in any of these formats. > >>> >> > > >>> >> > The payload of anyxml needn=E2=80=99t directly map t= o a data > >>> subtree in the > >>> >>usual sense. > >>> >> > > >>> >> > that's precisely the difference between anyxml and > >>> anydata. > >>> >> > The anydata node MUST map directly into data subtree= s. > >>> >> > >>> >> If the server doesn=E2=80=99t know the YANG data model= at run > >>> time (which is > >>> >>possible) then it cannot do it - for instance, it > >>> cannot properly map > >>> >>module names to namespace URI or handle lists. > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > > >>> >> > > > I also don't get the value of a single top-level > >>> node called > >>> >>'device' > >>> >> > > > that every YANG model on the planet is supposed > >>> to augment. > >>> >> > > > Can you explain why a protocol operation to > >>> retrieve the > >>> >> > > > document root (/) is not sufficient for the > >>> top-level node? > >>> >> > > > >>> >> > > I don=E2=80=99t intend to defend their model, the = more > >>> serious problem IMO > >>> >>is that a model for a single device/function may be > >>> needed in another > >>> >>device that hosts many virtualised devices/functions of > >>> the former type. > >>> >>We don=E2=80=99t have a good solution for this rather t= ypical > >>> situation. > >>> >> > > > >>> >> > > But a single container called "whatever" provides > >>> no such > >>> >>aggregation. > >>> >> > > You would need a list for that. And the NMS might > >>> have multiple > >>> >> > > layers of hierarchy to represent various > >>> aggregations. The NP > >>> >> > > container called "device" is not helpful for > >>> aggregation. > >>> >> > > >>> >> > The parent node can be a list as well. The =E2=80=9C= root=E2=80=9D > >>> node would be like > >>> >>a mount point in a Unix filesystem. > >>> >> > > >>> >> > > >>> >> > Are you saying all data on a device needs to be in a > >>> top-level list > >>> >>called 'device' > >>> >> > because an NMS might exist that wants to have the > >>> datastores from > >>> >>lots of devices? > >>> >> > As Martin pointed out several times, the NMS can > >>> make its own > >>> >>container or > >>> >> > lists. It does not need the device to mirror its > >>> own structure. > >>> >> > >>> >> As I said, I don=E2=80=99t care that much about the = =E2=80=9Cdevice=E2=80=9D > >>> container. What > >>> >>would be really useful is to have the possibility to do > >>> e.g. this: > >>> >> > >>> >> virtual-node* [name] > >>> >> name > >>> >> if:interfaces > >>> >> ... > >>> >> > >>> >> to support the use case where all virtual nodes are > >>> managed by the same > >>> >>NETCONF/RESTCONF server. > >>> >> > >>> >> Lada > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > Lada > >>> >> > > >>> >> > Andy > >>> >> > > >>> >> > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > Lada > >>> >> > > > >>> >> > > > >>> >> > > Andy > >>> >> > > > >>> >> > > > >>> >> > > > > >>> >> > > > Andy > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > >>> > > >>> >>wrote: > >>> >> > > > > >>> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka > >>> > wrote: > >>> >> > > > > > >>> >> > > > > Hi, > >>> >> > > > > > >>> >> > > > > after listening to the presentation of > >>> >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG > >>> session, I am > >>> >>wondering > >>> >> > > > > whether the solution chosen for Y34 is really > >>> useful. > >>> >> > > > > > >>> >> > > > > The draft states they want to reuse > >>> ietf-interfaces but their > >>> >>tree in > >>> >> > > > > fact is > >>> >> > > > > > >>> >> > > > > +--rw device > >>> >> > > > > +--rw info > >>> >> > > > > | +--rw device-type? enumeration > >>> >> > > > > +--rw hardware > >>> >> > > > > +--rw interfaces > >>> >> > > > > | +--rw interface* [name] > >>> >> > > > > | ... > >>> >> > > > > +--rw qos > >>> >> > > > > > >>> >> > > > > So the "interfaces" container is no more a > >>> top-level node. > >>> >>There are > >>> >> > > > > three possible options: > >>> >> > > > > > >>> >> > > > > 1. Change the ietf-interfaces module. > >>> >> > > > > 2. Replicate its contents in another module. > >>> >> > > > > 3. Extend YANG so that a *specific* schema > >>> tree can be grafted > >>> >>at a > >>> >> > > > > given data node. > >>> >> > > > > > >>> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 > >>> was essentially #3 > >>> >>but it > >>> >> > > > > seems it is not so because it doesn't specify > >>> a concrete data > >>> >>model > >>> >> > > > > that's allowed at a given location. > >>> >> > > > > > >>> >> > > > > On the other hand, the only real contribution > >>> of "anydata" over > >>> >>"anyxml" > >>> >> > > > > is that is doesn't permit mixed content in > >>> XML, which is IMO > >>> >>not much. > >>> >> > > > > > >>> >> > > > > I know Y34 was already closed but I think it > >>> is more important > >>> >>to do > >>> >> > > > > things right before YANG 1.1 becomes an RFC. > >>> >> > > > > > >>> >> > > > > What I want to propose is this: > >>> >> > > > > > >>> >> > > > > - Rename "anydata" as a synonym to "anyxml", > >>> and deprecate > >>> >>"anyxml" (but > >>> >> > > > > keep it for backward compatibility). > >>> >> > > > > >>> >> > > > s/Rename/Introduce/ > >>> >> > > > > >>> >> > > > > > >>> >> > > > > - Introduce a new statement and data node > >>> type, e.g. "root", > >>> >>that will > >>> >> > > > > extend the schema tree starting from that > >>> data node with a > >>> >>precisely > >>> >> > > > > specified data model. The specification can > >>> be same or similar > >>> >>as > >>> >> > > > > in yang-library. > >>> >> > > > > > >>> >> > > > > I believe there are other use cases in the > >>> existing modules. For > >>> >> > > > > example, the ietf-routing module could simply > >>> define the data > >>> >>model for > >>> >> > > > > a single routing instance (i.e. without > >>> "routing-instance" list > >>> >>at the > >>> >> > > > > top), and it can be then used without changes > >>> on simple > >>> >>devices, and > >>> >> > > > > more complex router implementations can graft > >>> it as a subtree > >>> >>under > >>> >> > > > > "routing-instance", "networking-instance" or > >>> whatever. > >>> >> > > > > > >>> >> > > > > Lada > >>> >> > > > > > >>> >> > > > > -- > >>> >> > > > > 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 > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > _______________________________________________ > >>> >> > > > 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 > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > _______________________________________________ > >>> >> > 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 > >>> > > >>> >-- > >>> >Juergen Schoenwaelder Jacobs University Bremen > >>> gGmbH > >>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 > >>> Bremen | Germany > >>> >Fax: +49 421 200 3103 > >>> > >>> > > >>> >_______________________________________________ > >>> >netmod mailing list > >>> >netmod@ietf.org > >>> >https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > > > > --089e0160bd10777353051c308174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 9:46 AM, Lou Berger <lberger@labn.net> wrote:
Andy,

On 07/27/2015 12:58 PM, Andy Bierman wrote:
> Hi,
>
> I don't think a standard for relocating subtrees would be worth it= .
> I am not in favor of moving /interfaces or /system to a new location.<= br> > That's not how YANG works. It only allows "obsolete and start= over".
>
> I would suggest pursuing solutions that don't cause
> as much disruption and expense as possible.
>

I think it would be really good to explore other, less "disruptive&quo= t;
options.

Perhaps you'd be willing to have a brain storming session off-line?=C2= =A0 (Of
course, any proposed changes/approaches would be brought to the WG for
normal WG processing.)


OK -- send an email invite to the meet= ing.

=C2=A0
Lou



Andy
=C2=A0
> For example, a resource directory of symlinks
> (YANG leaf, type instance-identifier) would allow
> standard or vendor modules to be supported.
> The exact location of the data nodes can change over time,
> and be different on each server.
>
>
> Andy
>
> On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Andy,
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the good information.=C2=A0 (I'll fo= llowup off line a bit if
>=C2=A0 =C2=A0 =C2=A0that's okay.) Of course there's a small mat= ter of getting something
>=C2=A0 =C2=A0 =C2=A0standardized.
>
>=C2=A0 =C2=A0 =C2=A0Lou
>
>=C2=A0 =C2=A0 =C2=A0On July 27, 2015 2:19:09 AM Andy Bierman <andy@yumaworks.com
>=C2=A0 =C2=A0 =C2=A0<mailto:an= dy@yumaworks.com>> wrote:
>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <= ;lberger@labn.net
>>=C2=A0 =C2=A0 =C2=A0<mailto:= lberger@labn.net>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Have you thought through implicat= ions / possibilities for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0existing models,=C2=A0 e.g., inte= rfaces?
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0First we have to define various forms of reloca= tion.
>>
>>=C2=A0 =C2=A0 =C2=A0(1) Aggregation of datastores
>>
>>=C2=A0 =C2=A0 =C2=A0The simplest form is aggregation.
>>=C2=A0 =C2=A0 =C2=A0It is possible to define a YANG container that = is a conceptual
>>=C2=A0 =C2=A0 =C2=A0document root, such that the set of child nodes= matches the set
>>=C2=A0 =C2=A0 =C2=A0of top-level YANG data nodes supported by the s= erver.
>>
>>=C2=A0 =C2=A0 =C2=A0A YANG extension can mark a YANG container or a= nyxml as a docroot.
>>=C2=A0 =C2=A0 =C2=A0Yuma-based code has been doing this for years w= ith a YANG
>>=C2=A0 =C2=A0 =C2=A0extension called "root"
>>
>>=C2=A0 =C2=A0 =C2=A0http:/= /www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554
>>
>>=C2=A0 =C2=A0 =C2=A0http://svn.t= ools.ietf.org/svn/wg/netmod/yang-1.1/issues.html
>>=C2=A0 =C2=A0 =C2=A0(See Y34-04)
>>
>>=C2=A0 =C2=A0 =C2=A0The <config> node below is a document roo= t:
>>
>>=C2=A0 =C2=A0 =C2=A0container servers {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0list server {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key addr;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf addr { type inet:ip-a= ddress; }
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anydata config {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ncx:root; >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>=C2=A0 =C2=A0 =C2=A0}
>>
>>=C2=A0 =C2=A0 =C2=A0XPath evaluation requires certain inputs, inclu= ding a context node
>>=C2=A0 =C2=A0 =C2=A0and a document root.=C2=A0 The 'root' e= xtension tells the tool to use
>>=C2=A0 =C2=A0 =C2=A0the node with the 'root' tag as the doc= ument root, when processing
>>=C2=A0 =C2=A0 =C2=A0XPath within its descendant nodes. Without the = tag, the XPath parser
>>=C2=A0 =C2=A0 =C2=A0would use 'servers' as the document roo= t, which is incorrect for
>>=C2=A0 =C2=A0 =C2=A0the relocated YANG nodes within 'config'= ;.
>>
>>=C2=A0 =C2=A0 =C2=A0(2) Move a subtree within the datastore
>>
>>=C2=A0 =C2=A0 =C2=A0This is the hardest (of course) because it invo= lves moving the
>>=C2=A0 =C2=A0 =C2=A0context node
>>=C2=A0 =C2=A0 =C2=A0not the document root. It is possible for tools= to get fooled
>>=C2=A0 =C2=A0 =C2=A0about the intent
>>=C2=A0 =C2=A0 =C2=A0of the XPath writer.=C2=A0 Basically the tool h= as to remember the
>>=C2=A0 =C2=A0 =C2=A0original context node,
>>=C2=A0 =C2=A0 =C2=A0and do some complicated data manipulation, proc= essing [4] Step
>>=C2=A0 =C2=A0 =C2=A0in XPath 1.0.=C2=A0 Multiple relocated subtrees= gets even more complicated.
>>
>>=C2=A0 =C2=A0 =C2=A0It may be possible to come up with some guideli= nes on XPath to avoid.
>>=C2=A0 =C2=A0 =C2=A0Basically any Xpath that selects nodes by speci= fic names can be
>>=C2=A0 =C2=A0 =C2=A0relocated automatically.=C2=A0 Nodes selected b= y function, wildcard,
>>=C2=A0 =C2=A0 =C2=A0axis, etc.
>>=C2=A0 =C2=A0 =C2=A0will not be so easy.
>>
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lou
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Andy
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On July 26, 2015 4:41:32 PM Andy = Bierman <andy@yumaworks.com >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:andy@yumaworks.com>> wrote:
>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Acee,
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I agree that "Relocatabl= e YANG" would be very useful, and
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have been
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thinking about the problem fo= r awhile.=C2=A0 I think the key is to
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0precisely
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0define a protocol-independent= document root for each of the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0various
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0YANG XPath contexts.=C2=A0 In= most cases the expression can be
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0automatically relocated to an= ancestor root.=C2=A0 For the rest, a
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0YANG mechanism is needed to t= ell the compiler to force evaluation
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on the old docroot (not the n= ew docroot ancestor).
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sun, Jul 26, 2015 at 10:49= AM, Acee Lindem (acee)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<acee@cisco.com <mailto:ac= ee@cisco.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think being a= ble to place a given model anywhere in the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device tree
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would be useful= and this would allow a model to be rooted
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in different >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0locations on di= fferent devices. Similarly, we=E2=80=99d need the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ability to pref= ix
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0XPATH reference= s to data nodes in the model with the root.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Acee
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 7/20/15, 11:= 00 PM, "netmod on behalf of Juergen
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Schoenwaelder&q= uot;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<netmod-bounces@ietf.org <mailto:netmod-bounces@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on behalf of >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0j.schoenwaelder@jacobs-university.= de
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:j.schoenwaelder@jacobs-= university.de>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>Lada,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>Y34 is clos= ed and I have not seen any new argument here
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that indicates<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>we made a m= ajor mistake with the resolution of Y34. As
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such, Y34
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>remains clo= sed.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>If you want= to discuss new ideas to relocate or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"symlink&q= uot; data models,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>please do s= o in a separate thread. (And no, we do not
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accept new
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>issues for = YANG 1.1 either at this point in time.)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>/js
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>On Mon, Jul= 20, 2015 at 07:42:49PM +0200, Ladislav
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lhotka wrote: >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > O= n 20 Jul 2015, at 19:29, Andy Bierman
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > O= n Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<lhotka@nic.cz <mailto:lhotka@nic.cz>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>wrote:<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; On 20 Jul 2015, at 17:00, Andy Bierman
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<lhotka@nic.cz <mailto:lhotka@nic.cz>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>wrote:<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > On 20 Jul 2015, at 14:55, Andy Bierman
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > Hi,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > Can you explain why we need 2 broken anyxmls?
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > (The original and a synonym?)=C2=A0 The whole point of
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > anydata is that it does not have XML cruft in it.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; Yes, I understand this was your main priority. For
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementors >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>using o= ff-the-shelf XML parsers and tools the XML cruft
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is not an issue=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>at all.=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; yes it is an issue.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; We need something to model a container full of
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arbitrary YANG = data
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>nodes.<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; This is something that can be applied to the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contents of a >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>datasto= re.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > a= nyxml can do that, too.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > t= he WG already decided it can't.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > T= he extra XML PIs, etc. are not accepted by all
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0servers, rememb= er?
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > T= here is no use for the extra stuff in the datastore.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> >= =C2=A0 I don't see why we need 2 anyxml constructs that
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are not
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > s= upported by the industry.=C2=A0 One is already too many.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I agre= e, but this is what we are going to have. My
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposal was to= have
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>just on= e with two different names.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; Anyway, I believe there are use cases for
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arbitrary XML/J= SON/CBOR/=E2=80=A6
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>with no= (YANG) schema available. My only complaint to
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=9Canyxml= =E2=80=9D has
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>always = been that it is a misnomer for encodings other
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than XML.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; The message encoding on the wire is not the same issue
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; as the contents of a datastore.=C2=A0 Our server stores
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its own
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; internal data structures.=C2=A0 XML, JSON, CBOR are
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0just message >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; encoding formats between client and server.=C2=A0 The
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; is not encoded in any of these formats.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > T= he payload of anyxml needn=E2=80=99t directly map to a data
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subtree in the<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>usual s= ense.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > t= hat's precisely the difference between anyxml and
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anydata.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > T= he anydata node MUST map directly into data subtrees.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> If the= server doesn=E2=80=99t know the YANG data model at run
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time (which is<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>possibl= e) then it cannot do it - for instance, it
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cannot properly= map
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>module = names to namespace URI or handle lists.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > I also don't get the value of a single top-level
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0node called
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>'de= vice'
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > that every YANG model on the planet is supposed
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to augment.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > Can you explain why a protocol operation to
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retrieve the >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > document root (/) is not sufficient for the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0top-level node?=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; I don=E2=80=99t intend to defend their model, the more
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0serious problem= IMO
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>is that= a model for a single device/function may be
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0needed in anoth= er
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>device = that hosts many virtualised devices/functions of
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the former type= .
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>We don= =E2=80=99t have a good solution for this rather typical
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0situation.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; But a single container called "whatever" provides
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no such
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>aggrega= tion.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; You would need a list for that. And the NMS might
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have multiple >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; layers of hierarchy to represent various
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aggregations.= =C2=A0 The NP
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; container called "device" is not helpful for
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aggregation. >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > T= he parent node can be a list as well. The =E2=80=9Croot=E2=80=9D
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0node would be l= ike
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>a mount= point in a Unix filesystem.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > A= re you saying all data on a device needs to be in a
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0top-level list<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>called = 'device'
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > b= ecause an NMS might exist that=C2=A0 wants to have the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datastores from=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>lots of= devices?
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > A= s Martin pointed out several times, the NMS can
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0make its own >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>contain= er or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > l= ists.=C2=A0 It does not need the device to mirror its
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0own structure.<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> As I s= aid, I don=E2=80=99t care that much about the =E2=80=9Cdevice=E2=80=9D
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container. What=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>would b= e really useful is to have the possibility to do
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e.g. this:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> virtua= l-node* [name]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 = =C2=A0 =C2=A0name
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 = =C2=A0 =C2=A0if:interfaces
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> to sup= port the use case where all virtual nodes are
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0managed by the = same
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>NETCONF= /RESTCONF server.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Lada >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > L= ada
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > A= ndy
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; Lada
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; Andy
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > Andy
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<lhotka@nic.cz <mailto:lhotka@nic.cz>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>wrote:<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > On 20 Jul 2015, at 14:45, Ladislav Lhotka
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<lhotka@nic.cz <mailto:lhotka@nic.cz>> wrote:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > Hi,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > after listening to the presentation of
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session, I am >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>wonderi= ng
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > whether the solution chosen for Y34 is really
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0useful.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > The draft states they want to reuse
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-interfaces= but their
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>tree in=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > fact is
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0+--rw device
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw info
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw device-type?= =C2=A0 =C2=A0enumeration
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw hardware
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interfaces
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw interface* [n= ame]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0... >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw qos
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > So the "interfaces" container is no more a
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0top-level node.=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>There a= re
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > three possible options:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > 1. Change the ietf-interfaces module.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > 2. Replicate its contents in another module.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > 3. Extend YANG so that a *specific* schema
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tree can be gra= fted
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>at a >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 =C2=A0given data node.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > IMO #1 & #2 are really bad. I thought Y34-04
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was essentially= #3
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>but it<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > seems it is not so because it doesn't specify
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a concrete data=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>model >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > that's allowed at a given location.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > On the other hand, the only real contribution
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of "anydat= a" over
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>"a= nyxml"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > is that is doesn't permit mixed content in
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0XML, which is I= MO
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>not muc= h.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > I know Y34 was already closed but I think it
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is more importa= nt
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>to do >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > things right before YANG 1.1 becomes an RFC.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > What I want to propose is this:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > - Rename "anydata" as a synonym to "anyxml&quo= t;,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and deprecate >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>"a= nyxml" (but
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 keep it for backward compatibility).
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > s/Rename/Introduce/
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > - Introduce a new statement and data node
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type, e.g. &quo= t;root",
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>that wi= ll
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 extend the schema tree starting from that
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node with = a
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>precise= ly
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 specified data model. The specification can
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be same or simi= lar
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>as
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >=C2=A0 in yang-library.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > I believe there are other use cases in the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0existing module= s. For
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > example, the ietf-routing module could simply
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0define the data=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>model f= or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > a single routing instance (i.e. without
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"routing-i= nstance" list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>at the<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > top), and it can be then used without changes
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on simple
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>devices= , and
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > more complex router implementations can graft
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it as a subtree=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>under >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > "routing-instance", "networking-instance"= or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0whatever.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > Lada
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > --
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > Ladislav Lhotka, CZ.NIC Labs
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > PGP Key ID: E74E8C0C
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > _______________________________________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > netmod mailing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > netmod@ietf.org <ma= ilto:netmod@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > > https://www.ietf.org/mailman/listinfo/net= mod
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > --
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > Ladislav Lhotka, CZ.NIC Labs
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > PGP Key ID: E74E8C0C
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > _______________________________________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > netmod mailing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > netmod@ietf.org <mailto:= netmod@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; > https://www.ietf.org/mailman/listinfo/netmod
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; --
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; Ladislav Lhotka, CZ.NIC Labs
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt; PGP Key ID: E74E8C0C
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > &= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > -= -
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > L= adislav Lhotka, CZ.NIC Labs
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > P= GP Key ID: E74E8C0C
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > _= ______________________________________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > n= etmod mailing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > <= a href=3D"mailto:netmod@ietf.org">netmod@ietf.org <mailto:netmod@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> > <= a href=3D"https://www.ietf.org/mailman/listinfo/netmod" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> --
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Ladisl= av Lhotka, CZ.NIC Labs
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> PGP Ke= y ID: E74E8C0C
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> ______= _________________________________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> netmod= mailing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> https://www.ietf.org/mailman/listinfo/netmod
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>--
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>Juergen Sch= oenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gGmbH
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>Phone: +49 = 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bremen | German= y
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>Fax:=C2=A0 = =C2=A0+49 421 200 3103
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= p://www.jacobs-university.de/>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>___________= ____________________________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>netmod mail= ing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>netmod@ietf.org <mailto:netmod@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________= ________________________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmod mailing = list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmod@ietf.org <mailto:netmod@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________= __________________
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmod mailing list
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmod@ietf.org <mailto:netmod%40ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ww= w.ietf.org/mailman/listinfo/netmod
>>>
>>
>


--089e0160bd10777353051c308174-- From nobody Fri Jul 31 23:52:03 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 63CD41B2AF2 for ; Fri, 31 Jul 2015 23:52: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 EV8caCGi8Mbh for ; Fri, 31 Jul 2015 23:51: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 3764D1B2AEA for ; Fri, 31 Jul 2015 23:51:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 465761439; Sat, 1 Aug 2015 08:51:51 +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 mV1vd7KTTzIK; Sat, 1 Aug 2015 08:51: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; Sat, 1 Aug 2015 08:51:50 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B0EB20046; Sat, 1 Aug 2015 08:51:55 +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 xXKR4dJ9zS5o; Sat, 1 Aug 2015 08:51:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 024A420045; Sat, 1 Aug 2015 08:51:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 839273606F4D; Sat, 1 Aug 2015 08:51:51 +0200 (CEST) Date: Sat, 1 Aug 2015 08:51:50 +0200 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20150801065150.GA67416@elstar.local> Mail-Followup-To: Lou Berger , Andy Bierman , NETMOD Working Group References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BBA679.7070508@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 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: Sat, 01 Aug 2015 06:52:01 -0000 On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > Andy, > > On 07/27/2015 12:58 PM, Andy Bierman wrote: > > Hi, > > > > I don't think a standard for relocating subtrees would be worth it. > > I am not in favor of moving /interfaces or /system to a new location. > > That's not how YANG works. It only allows "obsolete and start over". > > > > I would suggest pursuing solutions that don't cause > > as much disruption and expense as possible. > > > > I think it would be really good to explore other, less "disruptive" > options. > I think the first step is to find out whether there is a problem worth to be fixed. Why are the RFCs in question broken? (Yes, I have read the openconfig IDs, I listened to the virtual interim meetings, I assume you have read draft-bjorklund-netmod-openconfig-reply.) Lets get the core of the openconfig argument on the table why the existing RFCs are flawed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103