From nobody Mon Dec 1 00:09:22 2014 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 8F99A1A1A8D for ; Mon, 1 Dec 2014 00:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qwiRkiSva04l for ; Mon, 1 Dec 2014 00:09:15 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9661A0397 for ; Mon, 1 Dec 2014 00:09:14 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id sB189BoY016829; Mon, 1 Dec 2014 09:09:11 +0100 Message-ID: <547C2221.7010605@mg-soft.com> Date: Mon, 01 Dec 2014 09:09:05 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20141128.122916.638757582101311806.mbj@tail-f.com> In-Reply-To: <20141128.122916.638757582101311806.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TOp8rH_VLOqilaZrLyXU3ipzF9k Cc: netmod@ietf.org Subject: Re: [netmod] LL review of draft-ietf-netmod-rfc6020bis-02 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, 01 Dec 2014 08:09:19 -0000 Dne 28.11.2014 12:29, piše Martin Bjorklund: > Lada, > > Thank you for this review! Comments inline. > > > Ladislav Lhotka wrote: >> Hi, >> >> below are my comments to YANG 1.1 draft. >> >> Lada >> >> **** Sec. 4.2.7 >> I think this is incorrect terminology: "When a node from one case >> is created, ..." - sec. 3 defines "data node" as a node in the >> schema tree. It should be "When a data node instance from one >> case is created, ...". Sec. 3 should probably also define what >> "instance" means. > (This text hasn't changed from RFC 6020) > > How about: "When a node from one case is created in the data tree, > ..."? > > >> **** Sec. 4.2.2.2 >> OLD >> A leaf-list is a sequence of leaf nodes with exactly one value of a >> particular type per leaf. >> NEW >> A leaf-list instance is a sequence of values of a particular type. > (This text hasn't changed from RFC 6020) > > How about using similar language as in 4.2.2.4 for lists: "A leaf-list > defines a sequence of values of a particular type." > > >> **** Sec. 7.5.3 >> The issue Y41 is marked as REVIEW, so I'd expect some text in >> this section explaining how "must" expressions on NP-containers >> are evaluated. > Yes you are right. Today there is actually some duplication of text > between section 6.4.1 and 7.5.3. Instead of adding to the > duplication, I suggest we do: > > OLD: > > 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. > > NEW: > > When a datastore is validated, all "must" constraints are conceptually > evaluated once for each data node in the accessible tree (see > Section 6.4.1). > > >> **** Sec. 7.19.5 >> The second paragraph should say that a list key MUST NOT have a >> "when" statement. Such a statement has a different context node >> than a "when" statement on its ancestor, so it could break even >> if the two statements are identical. > Ok, I agree. Phil made the same comment at the mic in Honolulu, so > unless anyone objects, I'll make this change. > > >> **** Sec. 9.10.3 >> In the last paragraph, what is "the prefix"? It depends on >> namespace declarations that are in effect, and there can even be >> multiple prefixes declared for the same URI. >> >> Therefore, I think the string value has to be the exact value of >> the node (with no prefix if there is none). > This would break modules like ietf-system, which use the > : value. > > The idea is that the prefix is the prefix used in the import > statement. > > NEW: > > The string value of a node of type identityref in a "must" or > "when" XPath expression is the referred identity's qualified name > with the prefix present. If the referred identity is defined in an > imported module, the prefix in the string value is the prefix > defined in the corresponding "import" statement. Otherwise, the > prefix in the string value is the prefix for the current module. > > >> Consequently, >> comparison of identities in XPath expressions should always be >> performed via special XPath functions. >> **** Sec. 9.10.5 >> The "when" expression in the example should be >> >> when 'derived-from-or-self(../crypto, "my-crypto", "aes")'; >> >> (see also my comment to sec. 10.4.1 below). > See above. > >> **** Sec. 9.12 >> The validation procedure is too XML-centric. The value of a union >> instance needn't be a string. >> >> OLD >> When a string representing a union data type is validated, >> the string is validated against each member type, ... >> NEW >> A value representing a union data type is validated >> consecutively against each member type, ... > Ok, fixed. > >> **** Sec. 10 >> - The first paragraph should say that function signatures >> are specified in the same form as in XPath 1.0 spec. > Ok. > >> - Titles of subsections 10.1 and 10.2 could be "Node Set >> Functions" and "String Functions" (XPath spec uses these >> titles). > But then it wouldn't be consistent with the other subsections... > >> ***** Sec. 10.1 >> OLD >> The function current() takes no input parameters, and >> returns a node set with the initial context node. >> NEW >> The function current() takes no input parameters, and >> returns a node-set that has the context node as its only >> member. > Ok, fixed. > >> ***** Sec. 10.3.1 >> Instead of the deref() function I'd suggest to define a more >> general function evaluate(), that already exists in EXSLT, see >> http://www.exslt.org/dyn/functions/evaluate/: >> >> object evaluate(string expr) >> >> The evaluate() function takes a string, evaluates it as an XPath >> expression and returns the resulting value, which may be a >> node-set, string, number or boolean. > I would like to hear other peoples opinion on this. This would require implementations to implement XPath 1.0. If XPath is still just "used as a notation" in YANG 1.1, I don't think this would be acceptable. You don't need a full XPath 1.0 implementation to evaluate leafref paths or instance identifiers, but arbitrary expressions decided at runtime are a whole different kind of beast. With 'evaluate()' the following text from 6.4 becomes impossible to achieve: An implementation may choose to implement them by hand, rather than using the XPath expression directly. You can't implement a dynamic XPath expression by hand since it is not part of a model at implementation time. @Ladislav, just to make sure - you are suggesting this, right? augment "/path/to/some/container" { when "evaluate(../../foo)"; // evaluates string-value of an instantiated data node } ... ../foo2 = 'dark magic' ... Jernej > >> ***** Sec. 10.4.1 >> A similar function that's also needed is derived-from-or-self(). > Ok, added. > >> It would be needed in example 10.4.1.1 for doing things like >> >> augment "/interface" { >> when 'derived-from-or-self(type, >> "example-interface", >> "fast-ethernet")'; >> // fast-ethernet-specific definitions here >> } >> Alternatively, we could state in YANG 1.1 that derivation of >> identities is a reflexive relation, and then derived-from() >> would probably suffice. >> ***** Sec. 10.6.1 >> Maybe bit() is a better name than bit-is-set()? > I prefer a more descriptive name than just "bit". > > is-bit-set() > bit-set() -- not good, sounds like it might set the bit > bit-set-p() > bit-is-set() > > >> ***** Sec. 13 >> I don't know how how important it is to have the ABNF >> unambiguous. Previously, Jernej pointed out that refine-stmt >> makes the grammar ambiguous: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg07740.html >> The if-feature-expr production is another source of >> ambiguity. > Why is it ambiguous? > >> An unambiguous set of productions could look like >> this: >> >> if-feature-expr = if-feature-disj >> if-feature-disj = if-feature-conj >> if-feature-conj = identifier-ref-arg >> if-feature-expr = if-feature-expr 'or' if-feature-disj >> if-feature-disj = if-feature-disj 'and' if-feature-conj >> if-feature-conj = 'not' if-feature-conj / '(' if-feature-expr ')' > Hmm, this can't be right; you're defining each LHS twice. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 2 02:17:28 2014 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 217351A0264 for ; Tue, 2 Dec 2014 02:17:27 -0800 (PST) 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_44=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 JJI5SXicOkBq for ; Tue, 2 Dec 2014 02:17:25 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A9E1A03A5 for ; Tue, 2 Dec 2014 02:17:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 52B80540653; Tue, 2 Dec 2014 11:17:21 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPNz0JgOiUqP; Tue, 2 Dec 2014 11:17:15 +0100 (CET) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3C03354042E; Tue, 2 Dec 2014 11:17:14 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 02 Dec 2014 11:17:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a4wpqqe75pRARrt9fNzXtH1sBrE Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-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: Tue, 02 Dec 2014 10:17:27 -0000 Andy Bierman writes: > Hi, > > This draft defines 2 annotations: "inactive" and "type". > I am strongly opposed to the "inactive" annotation. > The "Conditional Enablement" draft by Kent Watsen should > be used for this purpose. This topic is more complicated than > just defining an "inactive" flag. The "inactive" annotation is Kent's "simple expression". The other expression types (complex, time) could be added but I'd strongly suggest to use a specific name for each. It might be a good idea though to add if-feature as an optional substatement of the "annotation" statement. > > The "type" annotation seems useless because the YANG parser > decides what internal type gets assigned to a union. > Sending the types inside the instance document is normally > only done if there is no schema. Some encoding formats (JSON in the first place) carry partial type info, and this annotation allows both clients and servers to specify the exact type of a union value in all encodings. It would be immediately useful e.g. for inet:host type because the other party then needn't match the value against multiple regexps to figure out whether it is an IPv4, IPv6 address or a domain name. Do you have other annotations that could be of general interest? Lada > > > > Andy > > > > On Fri, Nov 28, 2014 at 5:36 AM, Ladislav Lhotka wrote: >> Hi, >> >> this draft contains the module =E2=80=9Cietf-yang-annotations=E2=80=9D t= hat is intended to contain definitions of generally useful metadata annotat= ions. I included two annotations that I think might be handy. If you know a= bout others, please let me know. >> >> Thanks, Lada >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-lhotka-netmod-yang-annotati= ons-00.txt >>> Date: 28 Nov 2014 14:31:57 GMT+1 >>> To: Ladislav Lhotka , "Ladislav Lhotka" >>> >>> >>> A new version of I-D, draft-lhotka-netmod-yang-annotations-00.txt >>> has been successfully submitted by Ladislav Lhotka and posted to the >>> IETF repository. >>> >>> Name: draft-lhotka-netmod-yang-annotations >>> Revision: 00 >>> Title: Common Metadata Annotations for Data Modelled wit= h YANG >>> Document date: 2014-11-28 >>> Group: Individual Submission >>> Pages: 9 >>> URL: http://www.ietf.org/internet-drafts/draft-lhotka-netmod= -yang-annotations-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-lhotka-netmod-ya= ng-annotations/ >>> Htmlized: http://tools.ietf.org/html/draft-lhotka-netmod-yang-ann= otations-00 >>> >>> >>> Abstract: >>> This document introduces a collection of common metadata annotations >>> intended for use in data modeled with the YANG language. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> >> -- >> 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 From nobody Tue Dec 2 03:04:09 2014 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 AB72F1A1A99 for ; Tue, 2 Dec 2014 03:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geMGLAT-L019 for ; Tue, 2 Dec 2014 03:04:06 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DE81A1A91 for ; Tue, 2 Dec 2014 03:04:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0CDC8540653; Tue, 2 Dec 2014 12:04:04 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SCUqAavKpAU; Tue, 2 Dec 2014 12:03:59 +0100 (CET) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 36EBA54042E; Tue, 2 Dec 2014 12:03:58 +0100 (CET) From: Ladislav Lhotka To: Jernej Tuljak , Martin Bjorklund In-Reply-To: <547C2221.7010605@mg-soft.com> References: <20141128.122916.638757582101311806.mbj@tail-f.com> <547C2221.7010605@mg-soft.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 02 Dec 2014 12:03:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xhfQzik0Ediv83QV4HtlQiK75Ew Cc: netmod@ietf.org Subject: Re: [netmod] LL review of draft-ietf-netmod-rfc6020bis-02 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, 02 Dec 2014 11:04:07 -0000 Jernej Tuljak writes: ... >>> ***** Sec. 10.3.1 >>> Instead of the deref() function I'd suggest to define a more >>> general function evaluate(), that already exists in EXSLT, see >>> http://www.exslt.org/dyn/functions/evaluate/: >>> >>> object evaluate(string expr) >>> >>> The evaluate() function takes a string, evaluates it as an XPath >>> expression and returns the resulting value, which may be a >>> node-set, string, number or boolean. >> I would like to hear other peoples opinion on this. > > This would require implementations to implement XPath 1.0. If XPath is > still just "used as a notation" in YANG 1.1, I don't think this would be > acceptable. You don't need a full XPath 1.0 implementation to evaluate > leafref paths or instance identifiers, but arbitrary expressions decided > at runtime are a whole different kind of beast. That's a fair point, but my motivation was to make it simpler for implementations that *do* use standard XPath libraries that support the evaluate function, such as libxslt or Saxon. > > With 'evaluate()' the following text from 6.4 becomes impossible to achieve: > > An implementation may choose to implement them > by hand, rather than using the XPath expression directly. > > You can't implement a dynamic XPath expression by hand since it is not > part of a model at implementation time. I don't see any difference here - the XPath expressions appearing in "must" or "when" have to be evaluated against an instance document, i.e. at runtime. > > @Ladislav, just to make sure - you are suggesting this, right? > > augment "/path/to/some/container" { > when "evaluate(../../foo)"; // evaluates string-value of an instantiated > data node > } > > ... > ../foo2 = 'dark magic' > ... Yes, but again I don't think it is that much different from when "deref(../../foo)"; and ../dark/magic Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 2 03:46:12 2014 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 DB1BD1A1ACC for ; Tue, 2 Dec 2014 03:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 EZx_JTdzTIVw for ; Tue, 2 Dec 2014 03:46:08 -0800 (PST) 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 F1D3E1A1AC9 for ; Tue, 2 Dec 2014 03:46:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 01316F87; Tue, 2 Dec 2014 12:46:06 +0100 (CET) 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 hMWCv-rs8C84; Tue, 2 Dec 2014 12:45:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Dec 2014 12:46:05 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46FBF20034; Tue, 2 Dec 2014 12:46:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cpmtPmemXjsW; Tue, 2 Dec 2014 12:46:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC2ED20017; Tue, 2 Dec 2014 12:46:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6DDBB2FE77B3; Tue, 2 Dec 2014 12:46:01 +0100 (CET) Date: Tue, 2 Dec 2014 12:46:01 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141202114601.GC23660@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> 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: http://mailarchive.ietf.org/arch/msg/netmod/yrsxzKIUQt3Qe-S6Ne-4lazOgUY Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt 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, 02 Dec 2014 11:46:10 -0000 On Tue, Dec 02, 2014 at 11:17:14AM +0100, Ladislav Lhotka wrote: > > > > The "type" annotation seems useless because the YANG parser > > decides what internal type gets assigned to a union. > > Sending the types inside the instance document is normally > > only done if there is no schema. > > Some encoding formats (JSON in the first place) carry partial type info, > and this annotation allows both clients and servers to specify the exact > type of a union value in all encodings. > > It would be immediately useful e.g. for inet:host type because the > other party then needn't match the value against multiple regexps to > figure out whether it is an IPv4, IPv6 address or a domain name. > The litmus test for any extension statements and annotations is that clients not understanding an extension or annotation must be able to ignore it without causing any interoperability issues. It seems we are on slippery grounds if a type annotation tries to override the type matching rules of RFC 6020. /js (writing as technical contributor) -- 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 Dec 2 04:24:27 2014 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 47FA61A1B1E for ; Tue, 2 Dec 2014 04:24:24 -0800 (PST) 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 lYYe8YxIsYBp for ; Tue, 2 Dec 2014 04:24:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDC91A1B19 for ; Tue, 2 Dec 2014 04:24:22 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 7406D13F741; Tue, 2 Dec 2014 13:24:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417523060; bh=4Ief21RihHUFSgjQ6aZpGnsSuurRlUf+MBcU8zpipuY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ry5F9bqqP3W4Yb0+CCEBTCuVWxaQwcFLYaQxI5kqfAKbfT1/mspKq1mp4OJk6/QvM AfcbRuZw1dJ3LQpj6nU1pWwEpdrnCPlijRVXF+bEg2Fl0V1+vqDBWtAVGMtzj1h9BH FFGDLoGsnfaAva6wkLgO/kTXzcyM7cM0Z6e3Gn34= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20141202114601.GC23660@elstar.local> Date: Tue, 2 Dec 2014 13:24:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4F2EC8CF-ECF3-43E6-98E4-BE70B9FC5A22@nic.cz> References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> <20141202114601.GC23660@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tnNTpMUzHADGIXyZerdFdDDwutA Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-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: Tue, 02 Dec 2014 12:24:24 -0000 > On 02 Dec 2014, at 12:46, Juergen Schoenwaelder = wrote: >=20 > On Tue, Dec 02, 2014 at 11:17:14AM +0100, Ladislav Lhotka wrote: >>>=20 >>> The "type" annotation seems useless because the YANG parser >>> decides what internal type gets assigned to a union. >>> Sending the types inside the instance document is normally >>> only done if there is no schema. >>=20 >> Some encoding formats (JSON in the first place) carry partial type = info, >> and this annotation allows both clients and servers to specify the = exact >> type of a union value in all encodings. >>=20 >> It would be immediately useful e.g. for inet:host type because the >> other party then needn't match the value against multiple regexps to >> figure out whether it is an IPv4, IPv6 address or a domain name. >>=20 >=20 > The litmus test for any extension statements and annotations is that > clients not understanding an extension or annotation must be able to > ignore it without causing any interoperability issues. It seems we are They would ignore it and use the type discrimination algorithm that=E2=80=99= s default for a given encoding. Please give me an example how this could = cause interoperability issues. > on slippery grounds if a type annotation tries to override the type > matching rules of RFC 6020. RFC 6020 says in sec. 9.12: The union built-in type represents a value that corresponds to one of its member types. As I already pointed out in my review of 6020bis, the following = paragraph really makes sense only for (serialised) XML data: =E2=80=9CWhen a string representing a union data type is validated, = =E2=80=A6=E2=80=9D A union value (in value space) needn=E2=80=99t be a string. Lada =20 =20 >=20 > /js (writing as technical contributor) >=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 Dec 2 04:35:30 2014 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 8E2651A1A65 for ; Tue, 2 Dec 2014 04:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 vdWzgQXPzrqY for ; Tue, 2 Dec 2014 04:35:25 -0800 (PST) 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 1D16A1A1B01 for ; Tue, 2 Dec 2014 04:35:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E14E3879; Tue, 2 Dec 2014 13:35:23 +0100 (CET) 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 wHtHH3EUIrM5; Tue, 2 Dec 2014 13:35:15 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Dec 2014 13:35:23 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5E9C20017; Tue, 2 Dec 2014 13:35:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uJUOuu6TXQZW; Tue, 2 Dec 2014 13:35:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1B5C2002C; Tue, 2 Dec 2014 13:35:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A60972FE787C; Tue, 2 Dec 2014 13:35:21 +0100 (CET) Date: Tue, 2 Dec 2014 13:35:21 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141202123521.GA23881@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> <20141202114601.GC23660@elstar.local> <4F2EC8CF-ECF3-43E6-98E4-BE70B9FC5A22@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F2EC8CF-ECF3-43E6-98E4-BE70B9FC5A22@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/g_JWqVgBR7q6omLrsjSV2tmAfZA Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt 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, 02 Dec 2014 12:35:26 -0000 On Tue, Dec 02, 2014 at 01:24:20PM +0100, Ladislav Lhotka wrote: > > > On 02 Dec 2014, at 12:46, Juergen Schoenwaelder wrote: > > > > On Tue, Dec 02, 2014 at 11:17:14AM +0100, Ladislav Lhotka wrote: > >>> > >>> The "type" annotation seems useless because the YANG parser > >>> decides what internal type gets assigned to a union. > >>> Sending the types inside the instance document is normally > >>> only done if there is no schema. > >> > >> Some encoding formats (JSON in the first place) carry partial type info, > >> and this annotation allows both clients and servers to specify the exact > >> type of a union value in all encodings. > >> > >> It would be immediately useful e.g. for inet:host type because the > >> other party then needn't match the value against multiple regexps to > >> figure out whether it is an IPv4, IPv6 address or a domain name. > >> > > > > The litmus test for any extension statements and annotations is that > > clients not understanding an extension or annotation must be able to > > ignore it without causing any interoperability issues. It seems we are > > They would ignore it and use the type discrimination algorithm that’s default for a given encoding. Please give me an example how this could cause interoperability issues. We discussed this before and one of the examples was a union of a string and and int which always leads to the string interpretation in RFC 6020. > > on slippery grounds if a type annotation tries to override the type > > matching rules of RFC 6020. > > RFC 6020 says in sec. 9.12: > > The union built-in type represents a value that corresponds to one of > its member types. > > As I already pointed out in my review of 6020bis, the following paragraph really makes sense only for (serialised) XML data: > > “When a string representing a union data type is validated, …” > > A union value (in value space) needn’t be a string. So far, everything is encoded into a string. You do not like this but this is how YANG currently works. /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 Dec 2 07:26:58 2014 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 712281A1BDB for ; Tue, 2 Dec 2014 07:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=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 ly-DHTWjPXAh for ; Tue, 2 Dec 2014 07:26:54 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACCA1ACDFF for ; Tue, 2 Dec 2014 07:26:36 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ms9so10710787lab.24 for ; Tue, 02 Dec 2014 07:26:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=pFtV/anYT+1N2/AVKoDUjHPySxbvR99K8UCsJ6050MI=; b=Y9crEdlhQh71waWerr7GxOj9T4lYuMR2L8MsZ+EnZH8zajSvNXxp7r/tPmUpAAvea/ uTIalD7zzbsxmEzsEPy/DCfUuAEPfuP8OJKTj5FEhOW9Up1N2gQsFR9+ISK4iuFc4B27 rlcuVGprz5/f5mDMeH4KbtMf90YcyowufrJ6tP2Psz5Hy7sYgXrD7NVcdkO3MOMxk8/B SquMytcW4BAz8r2CZ74Mq4Lw7EpaJrclZjJ0bBVWa45aSm76CHhOtE5Gm7Zh3WRgyt2v F1BmSYc1Do1e1Z4L7FgNkwdX5RMjFquNCCAb8+lBqvl6v0sUfiCsmIhgu5pkFzT4IoRP X1vA== X-Gm-Message-State: ALoCoQkWGvkLuBRYbUW6XD2v5L0Qhf17FxCv8QSyGJJvXRskbR/sQ3MTtGm+9xxGovhg1TIXs/fA MIME-Version: 1.0 X-Received: by 10.112.140.135 with SMTP id rg7mr61223537lbb.100.1417533995227; Tue, 02 Dec 2014 07:26:35 -0800 (PST) Received: by 10.112.157.233 with HTTP; Tue, 2 Dec 2014 07:26:35 -0800 (PST) In-Reply-To: <20141202123521.GA23881@elstar.local> References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> <20141202114601.GC23660@elstar.local> <4F2EC8CF-ECF3-43E6-98E4-BE70B9FC5A22@nic.cz> <20141202123521.GA23881@elstar.local> Date: Tue, 2 Dec 2014 07:26:35 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , NETMOD Working Group Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/09bpLKfzSYPAIiwmuGm6dlQ97Tw Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-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: Tue, 02 Dec 2014 15:26:56 -0000 On Tue, Dec 2, 2014 at 4:35 AM, Juergen Schoenwaelder wrote: > On Tue, Dec 02, 2014 at 01:24:20PM +0100, Ladislav Lhotka wrote: >> >> > On 02 Dec 2014, at 12:46, Juergen Schoenwaelder wrote: >> > >> > On Tue, Dec 02, 2014 at 11:17:14AM +0100, Ladislav Lhotka wrote: >> >>> >> >>> The "type" annotation seems useless because the YANG parser >> >>> decides what internal type gets assigned to a union. >> >>> Sending the types inside the instance document is normally >> >>> only done if there is no schema. >> >> >> >> Some encoding formats (JSON in the first place) carry partial type in= fo, >> >> and this annotation allows both clients and servers to specify the ex= act >> >> type of a union value in all encodings. >> >> >> >> It would be immediately useful e.g. for inet:host type because the >> >> other party then needn't match the value against multiple regexps to >> >> figure out whether it is an IPv4, IPv6 address or a domain name. >> >> >> > >> > The litmus test for any extension statements and annotations is that >> > clients not understanding an extension or annotation must be able to >> > ignore it without causing any interoperability issues. It seems we are >> >> They would ignore it and use the type discrimination algorithm that=E2= =80=99s default for a given encoding. Please give me an example how this co= uld cause interoperability issues. > > We discussed this before and one of the examples was a union of a > string and and int which always leads to the string interpretation in > RFC 6020. > >> > on slippery grounds if a type annotation tries to override the type >> > matching rules of RFC 6020. >> >> RFC 6020 says in sec. 9.12: >> >> The union built-in type represents a value that corresponds to one of >> its member types. >> >> As I already pointed out in my review of 6020bis, the following paragrap= h really makes sense only for (serialised) XML data: >> >> =E2=80=9CWhen a string representing a union data type is validated, =E2= =80=A6=E2=80=9D >> >> A union value (in value space) needn=E2=80=99t be a string. > > So far, everything is encoded into a string. You do not like this but > this is how YANG currently works. > IMO the union type works fine in YANG. The tool goes through the type-stmts in order, and matches the first one that accepts/converts the string value into the specified YANG type. This extension is not needed. It also does not work for inline types or nested unions. type union { type int32 { range 1..10; } type enumeration { enum red; enum green; } type union { ... } type string; } > /js Andy > > -- > 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 Dec 2 08:25:51 2014 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 4E4641A1BE4 for ; Tue, 2 Dec 2014 08:25:48 -0800 (PST) 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_44=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 qhYRDlHBmg_k for ; Tue, 2 Dec 2014 08:25:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B3B1A1BD4 for ; Tue, 2 Dec 2014 08:25:45 -0800 (PST) Received: from [IPv6:2001:718:1a02::6914:d8ca:c719:bf12] (unknown [IPv6:2001:718:1a02:0:6914:d8ca:c719:bf12]) by mail.nic.cz (Postfix) with ESMTPSA id D5FB913F741; Tue, 2 Dec 2014 17:25:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417537543; bh=u6MpjKU/c6BtdxRJEvawrnx0NdFRfxFPeku6UCSESCQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nzQyFa5LulvRPue6+kY3LTCSgFX51GF0mGIjHxOtzBWWALtbZ7RGxQ/y8V+k60v9A zTIbsxPiBABk5aAF+ez6zW9e2Eota9BvnUgHfWsebfwiALT93wmypX0Rl6lmAL7TNS kLfLA4tlrPfy19Ea1zcuy01MbGo58p38BliCPBVA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 2 Dec 2014 17:25:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48B2F7FC-7EB0-4FB7-AA95-47B79C4BA2A7@nic.cz> References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> <20141202114601.GC23660@elstar.local> <4F2EC8CF-ECF3-43E6-98E4-BE70B9FC5A22@nic.cz> <20141202123521.GA23881@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GYSQL4b9yUUUrtnJZr4TPtltjgE Cc: NETMOD Working Group Subject: Re: [netmod] New Version Notification for draft-lhotka-netmod-yang-annotations-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: Tue, 02 Dec 2014 16:25:48 -0000 > On 02 Dec 2014, at 16:26, Andy Bierman wrote: >=20 > On Tue, Dec 2, 2014 at 4:35 AM, Juergen Schoenwaelder > wrote: >> On Tue, Dec 02, 2014 at 01:24:20PM +0100, Ladislav Lhotka wrote: >>>=20 >>>> On 02 Dec 2014, at 12:46, Juergen Schoenwaelder = wrote: >>>>=20 >>>> On Tue, Dec 02, 2014 at 11:17:14AM +0100, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> The "type" annotation seems useless because the YANG parser >>>>>> decides what internal type gets assigned to a union. >>>>>> Sending the types inside the instance document is normally >>>>>> only done if there is no schema. >>>>>=20 >>>>> Some encoding formats (JSON in the first place) carry partial type = info, >>>>> and this annotation allows both clients and servers to specify the = exact >>>>> type of a union value in all encodings. >>>>>=20 >>>>> It would be immediately useful e.g. for inet:host type because the >>>>> other party then needn't match the value against multiple regexps = to >>>>> figure out whether it is an IPv4, IPv6 address or a domain name. >>>>>=20 >>>>=20 >>>> The litmus test for any extension statements and annotations is = that >>>> clients not understanding an extension or annotation must be able = to >>>> ignore it without causing any interoperability issues. It seems we = are >>>=20 >>> They would ignore it and use the type discrimination algorithm = that=E2=80=99s default for a given encoding. Please give me an example = how this could cause interoperability issues. >>=20 >> We discussed this before and one of the examples was a union of a >> string and and int which always leads to the string interpretation in >> RFC 6020. >>=20 >>>> on slippery grounds if a type annotation tries to override the type >>>> matching rules of RFC 6020. >>>=20 >>> RFC 6020 says in sec. 9.12: >>>=20 >>> The union built-in type represents a value that corresponds to one = of >>> its member types. >>>=20 >>> As I already pointed out in my review of 6020bis, the following = paragraph really makes sense only for (serialised) XML data: >>>=20 >>> =E2=80=9CWhen a string representing a union data type is validated, = =E2=80=A6=E2=80=9D >>>=20 >>> A union value (in value space) needn=E2=80=99t be a string. >>=20 >> So far, everything is encoded into a string. You do not like this but >> this is how YANG currently works. >>=20 >=20 > IMO the union type works fine in YANG. > The tool goes through the type-stmts in order, and matches > the first one that accepts/converts the string value into the > specified YANG type. Except that this may involve matching several regexp patterns before you = get the result. I don=E2=80=99t understand how the extra information = could be harmful. >=20 > This extension is not needed. It also does not work for inline types > or nested unions. >=20 > type union { > type int32 { range 1..10; } > type enumeration { > enum red; > enum green; > } > type union { ... } > type string; > } >=20 Yes, this may not be able to discriminate among multiple inline types = but nested unions are OK: the annotation would just contain the leaf = member type that=E2=80=99s inside the inner union. Lada >=20 >> /js >=20 > Andy >=20 >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 2 08:45:01 2014 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 A7BAA1A1EF8 for ; Tue, 2 Dec 2014 08:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=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 VVySX0w-ZStN for ; Tue, 2 Dec 2014 08:44:53 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E481A1EF9 for ; Tue, 2 Dec 2014 08:44:53 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so11039945lab.32 for ; Tue, 02 Dec 2014 08:44:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sN+bxtLHsIWRTgRlVeM4RX/CYaF3YWD4MHSmbvN84k0=; b=XRgDafbiHe02M8XRLKFrgFIvOsaZO20vZUeSNsLg0O7K/Eva4HJFmWt91HoTItvoIZ gmI7/VMybauWAOmLPEzuiSckzyfCLSEsFEYgUCxwX1K3/+cP7vt8vHI5T1EumEOXl0ue ccDw2aNCDvrqubGupzxl01NsQgLzG1nx3SSAlqmaZA3/4umAc/v5ApyNcwnQN8zraYW2 2IJe0CNxfsrmHNFVHHf0b7dXUCp2JT5pNeRVu2r8QiO4dDbM8SbFKTjUG92G3AsW0Wbo ehNLYbE0Po3lTqlGFgqeGQQJPwE9w0w81NbaewYZlFMJV7jwKUF5Sq3zGeaUWhlhHIj4 EJNw== X-Gm-Message-State: ALoCoQmp09FiUrJUmUHA4IgIO71f40Wz4nlUimkHpwVDbvs/eNjxBmk6FWqZwb6Nq5Ceikg0sfMs MIME-Version: 1.0 X-Received: by 10.153.8.137 with SMTP id dk9mr187348lad.82.1417538691809; Tue, 02 Dec 2014 08:44:51 -0800 (PST) Received: by 10.112.157.233 with HTTP; Tue, 2 Dec 2014 08:44:51 -0800 (PST) In-Reply-To: <48B2F7FC-7EB0-4FB7-AA95-47B79C4BA2A7@nic.cz> References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> <20141202114601.GC23660@elstar.local> <4F2EC8CF-ECF3-43E6-98E4-BE70B9FC5A22@nic.cz> <20141202123521.GA23881@elstar.local> <48B2F7FC-7EB0-4FB7-AA95-47B79C4BA2A7@nic.cz> Date: Tue, 2 Dec 2014 08:44:51 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kPyokw4bURFD89Zayhu0JDCyxL8 Cc: NETMOD Working Group Subject: Re: [netmod] New Version Notification for draft-lhotka-netmod-yang-annotations-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: Tue, 02 Dec 2014 16:44:57 -0000 On Tue, Dec 2, 2014 at 8:25 AM, Ladislav Lhotka wrote: > >> On 02 Dec 2014, at 16:26, Andy Bierman wrote: >> >> On Tue, Dec 2, 2014 at 4:35 AM, Juergen Schoenwaelder >> wrote: >>> On Tue, Dec 02, 2014 at 01:24:20PM +0100, Ladislav Lhotka wrote: >>>> >>>>> On 02 Dec 2014, at 12:46, Juergen Schoenwaelder wrote: >>>>> >>>>> On Tue, Dec 02, 2014 at 11:17:14AM +0100, Ladislav Lhotka wrote: >>>>>>> >>>>>>> The "type" annotation seems useless because the YANG parser >>>>>>> decides what internal type gets assigned to a union. >>>>>>> Sending the types inside the instance document is normally >>>>>>> only done if there is no schema. >>>>>> >>>>>> Some encoding formats (JSON in the first place) carry partial type i= nfo, >>>>>> and this annotation allows both clients and servers to specify the e= xact >>>>>> type of a union value in all encodings. >>>>>> >>>>>> It would be immediately useful e.g. for inet:host type because the >>>>>> other party then needn't match the value against multiple regexps to >>>>>> figure out whether it is an IPv4, IPv6 address or a domain name. >>>>>> >>>>> >>>>> The litmus test for any extension statements and annotations is that >>>>> clients not understanding an extension or annotation must be able to >>>>> ignore it without causing any interoperability issues. It seems we ar= e >>>> >>>> They would ignore it and use the type discrimination algorithm that=E2= =80=99s default for a given encoding. Please give me an example how this co= uld cause interoperability issues. >>> >>> We discussed this before and one of the examples was a union of a >>> string and and int which always leads to the string interpretation in >>> RFC 6020. >>> >>>>> on slippery grounds if a type annotation tries to override the type >>>>> matching rules of RFC 6020. >>>> >>>> RFC 6020 says in sec. 9.12: >>>> >>>> The union built-in type represents a value that corresponds to one o= f >>>> its member types. >>>> >>>> As I already pointed out in my review of 6020bis, the following paragr= aph really makes sense only for (serialised) XML data: >>>> >>>> =E2=80=9CWhen a string representing a union data type is validated, = =E2=80=A6=E2=80=9D >>>> >>>> A union value (in value space) needn=E2=80=99t be a string. >>> >>> So far, everything is encoded into a string. You do not like this but >>> this is how YANG currently works. >>> >> >> IMO the union type works fine in YANG. >> The tool goes through the type-stmts in order, and matches >> the first one that accepts/converts the string value into the >> specified YANG type. > > Except that this may involve matching several regexp patterns before you = get the result. I don=E2=80=99t understand how the extra information could = be harmful. > So what? The algorithm is very simple and validating types is what servers have to d= o. Overriding the YANG type is not needed and not even a good thing to do. The JSON types do not matter -- there is only 1 schema which is in the YANG module. >> >> This extension is not needed. It also does not work for inline types >> or nested unions. >> >> type union { >> type int32 { range 1..10; } >> type enumeration { >> enum red; >> enum green; >> } >> type union { ... } >> type string; >> } >> > > Yes, this may not be able to discriminate among multiple inline types but= nested unions are OK: the annotation would just contain the leaf member ty= pe that=E2=80=99s inside the inner union. > > Lada Andy > >> >>> /js >> >> Andy >> >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Dec 2 11:53:02 2014 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 AB3A91A1F02 for ; Tue, 2 Dec 2014 11:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE10yf5YGtAy for ; Tue, 2 Dec 2014 11:52:56 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734CC1A1E0E for ; Tue, 2 Dec 2014 11:52:56 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id s18so11404402lam.15 for ; Tue, 02 Dec 2014 11:52:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qULdx56rgwbURZezITZMRZDHueTmKFcjmebjY0b8OMI=; b=msZ5YV+M25Oq7iCVWYLiJgrd+UwkkA/Ye2EkHeeiTCzQjS1b3rI5ZqsL5TygN3klBv e/g/7nLxvo+aRUAqT6oCBO6h5ecb4I0BDzDeBJX3Gr/gg/ETnrK/zYKuXANZfsI+x2cQ s183ez1gSrOaLcxo/OMQTciR86WWJ0eypUlajKZN1tJWMrkS+c0DFfUY4ZGaCDNDJCaF bhFnmG4W3IWPZIh4gVA1siCOfqgMClj4p0VeUyu+fJ0Qo30Q6mIDV6E0q4a516ljbyRS lb4KpKmsB/Ywnpuauomz475YtDVkvgLt49syXIKt6UiicC5KAHoxpLLLSeq8WXswMbcf lefQ== X-Gm-Message-State: ALoCoQkuiAoi22HKkBqk6YM2Xs3ujinGzYMIp8COjbRqfAhvR63W0FNjhmxELlZoVgAX/vXR/iAB MIME-Version: 1.0 X-Received: by 10.153.8.137 with SMTP id dk9mr950273lad.82.1417549974841; Tue, 02 Dec 2014 11:52:54 -0800 (PST) Received: by 10.112.157.233 with HTTP; Tue, 2 Dec 2014 11:52:54 -0800 (PST) In-Reply-To: <547C2221.7010605@mg-soft.com> References: <20141128.122916.638757582101311806.mbj@tail-f.com> <547C2221.7010605@mg-soft.com> Date: Tue, 2 Dec 2014 11:52:54 -0800 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JCbS-Bp5Y8eMnT8caPsTbm85Db4 Cc: "netmod@ietf.org" Subject: Re: [netmod] LL review of draft-ietf-netmod-rfc6020bis-02 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, 02 Dec 2014 19:52:58 -0000 On Mon, Dec 1, 2014 at 12:09 AM, Jernej Tuljak w= rote: > Dne 28.11.2014 12:29, pi=C5=A1e Martin Bjorklund: >> >> Lada, >> >> Thank you for this review! Comments inline. >> >> >> Ladislav Lhotka wrote: >>> >>> Hi, ... >>> ***** Sec. 10.3.1 >>> Instead of the deref() function I'd suggest to define a more >>> general function evaluate(), that already exists in EXSLT, see >>> http://www.exslt.org/dyn/functions/evaluate/: >>> >>> object evaluate(string expr) >>> >>> The evaluate() function takes a string, evaluates it as an XPath >>> expression and returns the resulting value, which may be a >>> node-set, string, number or boolean. >> >> I would like to hear other peoples opinion on this. > > I agree with Jernej. Just to make sure I understand... You want to use nodes in the datastore to hold XPath expressions set by the client, that get evaluated inside of a must/when evaluation? So the evaluate(../../foo) expression below would read the value of the foo leaf and evaluate that string as an XPath expression? I prefer the current deref function. It is clear, constrained, and does not require a customized XPath parser, or any XPath parser, to implement in a server. Andy > This would require implementations to implement XPath 1.0. If XPath is st= ill > just "used as a notation" in YANG 1.1, I don't think this would be > acceptable. You don't need a full XPath 1.0 implementation to evaluate > leafref paths or instance identifiers, but arbitrary expressions decided = at > runtime are a whole different kind of beast. > > With 'evaluate()' the following text from 6.4 becomes impossible to achie= ve: > > An implementation may choose to implement them > by hand, rather than using the XPath expression directly. > > You can't implement a dynamic XPath expression by hand since it is not pa= rt > of a model at implementation time. > > @Ladislav, just to make sure - you are suggesting this, right? > > augment "/path/to/some/container" { > when "evaluate(../../foo)"; // evaluates string-value of an instantiated > data node > } > > ... > ../foo2 =3D 'dark magic' > ... > > Jernej > >> >>> ***** Sec. 10.4.1 >>> A similar function that's also needed is derived-from-or-self(). >> >> Ok, added. >> >>> It would be needed in example 10.4.1.1 for doing things like >>> >>> augment "/interface" { >>> when 'derived-from-or-self(type, >>> "example-interface", >>> "fast-ethernet")'; >>> // fast-ethernet-specific definitions here >>> } >>> Alternatively, we could state in YANG 1.1 that derivation of >>> identities is a reflexive relation, and then derived-from() >>> would probably suffice. >>> ***** Sec. 10.6.1 >>> Maybe bit() is a better name than bit-is-set()? >> >> I prefer a more descriptive name than just "bit". >> >> is-bit-set() >> bit-set() -- not good, sounds like it might set the bit >> bit-set-p() >> bit-is-set() >> >> >>> ***** Sec. 13 >>> I don't know how how important it is to have the ABNF >>> unambiguous. Previously, Jernej pointed out that refine-stmt >>> makes the grammar ambiguous: >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg07740.htm= l >>> The if-feature-expr production is another source of >>> ambiguity. >> >> Why is it ambiguous? >> >>> An unambiguous set of productions could look like >>> this: >>> >>> if-feature-expr =3D if-feature-disj >>> if-feature-disj =3D if-feature-conj >>> if-feature-conj =3D identifier-ref-arg >>> if-feature-expr =3D if-feature-expr 'or' if-feature-disj >>> if-feature-disj =3D if-feature-disj 'and' if-feature-conj >>> if-feature-conj =3D 'not' if-feature-conj / '(' if-feature-expr = ')' >> >> Hmm, this can't be right; you're defining each LHS twice. >> >> >> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 2 12:30:29 2014 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 171C01A854B for ; Tue, 2 Dec 2014 12:30:28 -0800 (PST) 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 km21BsQ5KXm7 for ; Tue, 2 Dec 2014 12:30:26 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB6F1A7012 for ; Tue, 2 Dec 2014 12:30:25 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 27C4313F741; Tue, 2 Dec 2014 21:30:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417552224; bh=FT/774Y6ETdTHu4oCymW8RNdznuxJ0LBRY8Lpkh0gvU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E9K21MsbMmpcUMpE334+APieT7CAKof5kHfvquEYThAbT7Xm6uKKisoZWy1S0v7Ka VYOt2tJIP+O/6GzDNBQLu84+bwhvbKuH0qVAyRKVYNjJKaDcp6qMHerdHKEVh/O6XA ZurD80jfts5+P2k0Gs7+9nSb/8MDoB4GvbXSkzMk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 2 Dec 2014 21:30:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76F23973-EBE8-48E0-B3F3-A0C2546C53A6@nic.cz> References: <20141128.122916.638757582101311806.mbj@tail-f.com> <547C2221.7010605@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5U_3pTiZaJafQ87iVmO3HNdZ1j0 Cc: "netmod@ietf.org" Subject: Re: [netmod] LL review of draft-ietf-netmod-rfc6020bis-02 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, 02 Dec 2014 20:30:28 -0000 > On 02 Dec 2014, at 20:52, Andy Bierman wrote: >=20 > On Mon, Dec 1, 2014 at 12:09 AM, Jernej Tuljak = wrote: >> Dne 28.11.2014 12:29, pi=C5=A1e Martin Bjorklund: >>>=20 >>> Lada, >>>=20 >>> Thank you for this review! Comments inline. >>>=20 >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> Hi, > ... >=20 >=20 >>>> ***** Sec. 10.3.1 >>>> Instead of the deref() function I'd suggest to define a more >>>> general function evaluate(), that already exists in EXSLT, = see >>>> http://www.exslt.org/dyn/functions/evaluate/: >>>>=20 >>>> object evaluate(string expr) >>>>=20 >>>> The evaluate() function takes a string, evaluates it as an = XPath >>>> expression and returns the resulting value, which may be a >>>> node-set, string, number or boolean. >>>=20 >>> I would like to hear other peoples opinion on this. >>=20 >>=20 >=20 > I agree with Jernej. > Just to make sure I understand... > You want to use nodes in the datastore to hold XPath expressions > set by the client, that get evaluated inside of a must/when = evaluation? > So the evaluate(../../foo) expression below would read the value of > the foo leaf and evaluate that string as an XPath expression? Yes, this is what these existing extensions do: - http://www.exslt.org/dyn/functions/evaluate/ - = http://www.saxonica.com/documentation9.4-demo/html/extensions/functions/ev= aluate.html The same function is now also in XSLT 3.0 standard: - http://www.w3.org/TR/xslt-30/#element-evaluate >=20 > I prefer the current deref function. > It is clear, constrained, and does not require a customized XPath = parser, > or any XPath parser, to implement in a server. OK. Lada >=20 >=20 >=20 > Andy >=20 >=20 >=20 >=20 >> This would require implementations to implement XPath 1.0. If XPath = is still >> just "used as a notation" in YANG 1.1, I don't think this would be >> acceptable. You don't need a full XPath 1.0 implementation to = evaluate >> leafref paths or instance identifiers, but arbitrary expressions = decided at >> runtime are a whole different kind of beast. >>=20 >> With 'evaluate()' the following text from 6.4 becomes impossible to = achieve: >>=20 >> An implementation may choose to implement them >> by hand, rather than using the XPath expression directly. >>=20 >> You can't implement a dynamic XPath expression by hand since it is = not part >> of a model at implementation time. >>=20 >> @Ladislav, just to make sure - you are suggesting this, right? >>=20 >> augment "/path/to/some/container" { >> when "evaluate(../../foo)"; // evaluates string-value of an = instantiated >> data node >> } >>=20 >> ... >> ../foo2 =3D 'dark magic' >> ... >>=20 >> Jernej >>=20 >>>=20 >>>> ***** Sec. 10.4.1 >>>> A similar function that's also needed is = derived-from-or-self(). >>>=20 >>> Ok, added. >>>=20 >>>> It would be needed in example 10.4.1.1 for doing things like >>>>=20 >>>> augment "/interface" { >>>> when 'derived-from-or-self(type, >>>> "example-interface", >>>> "fast-ethernet")'; >>>> // fast-ethernet-specific definitions here >>>> } >>>> Alternatively, we could state in YANG 1.1 that derivation of >>>> identities is a reflexive relation, and then derived-from() >>>> would probably suffice. >>>> ***** Sec. 10.6.1 >>>> Maybe bit() is a better name than bit-is-set()? >>>=20 >>> I prefer a more descriptive name than just "bit". >>>=20 >>> is-bit-set() >>> bit-set() -- not good, sounds like it might set the bit >>> bit-set-p() >>> bit-is-set() >>>=20 >>>=20 >>>> ***** Sec. 13 >>>> I don't know how how important it is to have the ABNF >>>> unambiguous. Previously, Jernej pointed out that refine-stmt >>>> makes the grammar ambiguous: >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/netmod/current/msg07740.html >>>> The if-feature-expr production is another source of >>>> ambiguity. >>>=20 >>> Why is it ambiguous? >>>=20 >>>> An unambiguous set of productions could look like >>>> this: >>>>=20 >>>> if-feature-expr =3D if-feature-disj >>>> if-feature-disj =3D if-feature-conj >>>> if-feature-conj =3D identifier-ref-arg >>>> if-feature-expr =3D if-feature-expr 'or' if-feature-disj >>>> if-feature-disj =3D if-feature-disj 'and' if-feature-conj >>>> if-feature-conj =3D 'not' if-feature-conj / '(' = if-feature-expr ')' >>>=20 >>> Hmm, this can't be right; you're defining each LHS twice. >>>=20 >>>=20 >>> /martin >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=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 Dec 3 03:21:06 2014 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 2A6461A1A63 for ; Wed, 3 Dec 2014 03:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.31 X-Spam-Level: X-Spam-Status: No, score=-8.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-5, 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 p768ZNOrOgTy for ; Wed, 3 Dec 2014 03:21:02 -0800 (PST) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984941A1A40 for ; Wed, 3 Dec 2014 03:21:02 -0800 (PST) Received: from jva2tc102.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda11.webex.com (Postfix) with ESMTP id 4DCFFC035E for ; Wed, 3 Dec 2014 11:21:02 +0000 (GMT) Received: from jva2tc102.webex.com (localhost [127.0.0.1]) by jva2tc102.webex.com (Postfix) with ESMTP id E5E1721EF3D for ; Wed, 3 Dec 2014 11:21:01 +0000 (GMT) Date: Wed, 3 Dec 2014 11:21:01 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <291018528.73772.1417605661927.JavaMail.nobody@jva2tc102.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_73770_1303187955.1417605661927" X-Priority: 3 Importance: normal Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ykh0eYmncOHUYbM-VHmKDYQIW_0 Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:21:04 -0000 ------=_Part_73770_1303187955.1417605661927 Content-Type: multipart/Alternative; boundary="----=_Part_73771_494243932.1417605661927" ------=_Part_73771_494243932.1417605661927 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCldlZG5lc2RheSwgRGVjZW1iZXIgMywgMjAx NAo0OjAwIHBtICB8ICBFdXJvcGUgVGltZSAoQmVybGluLCBHTVQrMDE6MDApICB8ICAyIGhyCgoK Sk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElE PW0zZWI5N2Q1MDA0MjJiODljNzkzMTZhZWU3YzdjMDhmOQpNZWV0aW5nIG51bWJlcjogNjQ5IDA1 OCAyOTEKTWVldGluZyBwYXNzd29yZDogU2UzR2FlZGkKCg0KSk9JTiBCWSBQSE9ORQ0KMS04Nzct NjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00Nzkt MzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDkgMDU4 IDI5MQoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJleC5j b20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcgdG8g eW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEz ODdiZTY2YzY0NmQ2ZTRhM2IyNWI3MzM5NmIwZWE2DQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5n PyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jCgoK SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLgo= ------=_Part_73771_494243932.1417605661927 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+V2Vk bmVzZGF5LCBEZWNlbWJlciAzLCAyMDE0CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD40OjAwIHBtJm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwO0V1cm9wZSBUaW1lIChCZXJsaW4sIEdNVCswMTowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MiBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxl PgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0 eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTNlYjk3ZDUwMDQyMmI4OWM3OTMx NmFlZTdjN2MwOGY5IgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQt c2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBtZWV0aW5n PC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFi bGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQi PgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRp bmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8L3RkPgoJ CQkJCQkJCTx0ZD42NDkgMDU4IDI5MQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJ PHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGluZyBwYXNz d29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5TZTNHYWVkaTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8 L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0 eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQg c3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIg c3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxsLWlu IHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46 MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3MgY29k ZTombmJzcDs2NDkgMDU4IDI5MTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48 YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMwMEFG Rjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFibGU+ CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxlPSJm b250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bTEzODdiZTY2YzY0NmQ2ZTRhM2IyNWI3MzM5NmIwZWE2IiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1lZXRp bmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9udC1z aXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAgIENh bid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAgICAg ICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0YWJs ZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJCQkJ CQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJCUlN UE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8g YmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIu IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1 Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vz c2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwvdHI+ CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_73771_494243932.1417605661927-- ------=_Part_73770_1303187955.1417605661927 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTIxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEyMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE0MTIwM1QxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTQxMjAzVDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxClVJRDpXRUJFWC1NRUVUSU5HIENFTlRF Ui02LjA0NTY2ODAtMzEyNzM3MDc3LVNVPWlldGYKRFRTVEFNUDoyMDE0MTIwM1QxNTAwMDBaCkRF U0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTNlYjk3ZDUwMDQyMmI4OWM3OTMxNmFlZTdjN2MwOGY5XG5NZWV0 aW5nIG51bWJlcjogNjQ5IDA1OCAyOTFcbk1lZXRpbmcgcGFzc3dvcmQ6IFNlM0dhZWRpXG5cblxu Sk9JTiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChV Uy9DYW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KVxuQWNjZXNzIGNvZGU6IDY0OSAwNTggMjkxXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0 aW9uczogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztG TVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4g PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0zZWI5N2Q1MDA0MjJiODljNzkzMTZhZWU3YzdjMDhm OSI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4 IG1lZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9G T05UPgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjY0OSAwNTggMjkxPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8 L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+U2UzR2FlZGk8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4m bmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIz IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+ MS04NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ5IDA1OCAyOTE8L0ZP TlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVf cmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFy aWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJS PjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVm PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0i IzAwQUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8 QlI+Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUK Q0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRF U0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_73770_1303187955.1417605661927-- From nobody Wed Dec 3 03:52:22 2014 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 996951A1A7A for ; Wed, 3 Dec 2014 03:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 WaGOhodBhMIb for ; Wed, 3 Dec 2014 03:52:19 -0800 (PST) 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 84E951A1A74 for ; Wed, 3 Dec 2014 03:52:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5731389D for ; Wed, 3 Dec 2014 12:52:18 +0100 (CET) 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 zzMYpJdVGWWV for ; Wed, 3 Dec 2014 12:52:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 3 Dec 2014 12:52:17 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB4EC20017 for ; Wed, 3 Dec 2014 12:52:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mFPAwG4Rbhwq; Wed, 3 Dec 2014 12:52:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC1592002C; Wed, 3 Dec 2014 12:52:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B6BF42FE9A9D; Wed, 3 Dec 2014 12:52:15 +0100 (CET) Date: Wed, 3 Dec 2014 12:52:15 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141203115215.GA27092@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cSk7YKs6BpSLVUtJp_XQfIPit6A Subject: [netmod] VRFY :Y05: unprefixed path in top-level typedef 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, 03 Dec 2014 11:52:20 -0000 Hi, The 2014-11-19 virtual interim meeting proposal is to adopt solution Y05-01. Please speak up by Wednesday 2014-12-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 3 04:03:57 2014 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 418541A1A7F for ; Wed, 3 Dec 2014 04:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 4ray_z7popTi for ; Wed, 3 Dec 2014 04:03:53 -0800 (PST) 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 D6E9D1A1A74 for ; Wed, 3 Dec 2014 04:03:52 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9B3031013 for ; Wed, 3 Dec 2014 13:03:51 +0100 (CET) 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 caL1raO2QGJH for ; Wed, 3 Dec 2014 13:03:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 3 Dec 2014 13:03:50 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF5CA2002C for ; Wed, 3 Dec 2014 13:03:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5Nh7ilQsUfAM; Wed, 3 Dec 2014 13:03:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFF3E20017; Wed, 3 Dec 2014 13:03:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E0FA72FE9AF6; Wed, 3 Dec 2014 13:03:49 +0100 (CET) Date: Wed, 3 Dec 2014 13:03:49 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141203120349.GA27188@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aH1MqlA9VuAKljuDeLqDPdkEsjg Subject: [netmod] DEAD :Y54: remove the advertisement of conformance information in NETCONF hello message 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, 03 Dec 2014 12:03:54 -0000 Hi, the 2014-11-19 virtual interim meeting proposal is to declare this issue DEAD since it is addressed by Y16. Please speak up by Wednesday 2014-12-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 3 06:11:45 2014 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 964061A1B26 for ; Wed, 3 Dec 2014 06:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 LxSObGINAPT7 for ; Wed, 3 Dec 2014 06:11:41 -0800 (PST) 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 9BD181A1A4E for ; Wed, 3 Dec 2014 06:11:41 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 68AF6E61 for ; Wed, 3 Dec 2014 15:11:40 +0100 (CET) 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 t9bjIPPbEXjp for ; Wed, 3 Dec 2014 15:11:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 3 Dec 2014 15:11:39 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC3EF2002C for ; Wed, 3 Dec 2014 15:11:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wDtJ04GHDNAO; Wed, 3 Dec 2014 15:11:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F408320017; Wed, 3 Dec 2014 15:11:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DDBE72FE9D88; Wed, 3 Dec 2014 15:11:38 +0100 (CET) Date: Wed, 3 Dec 2014 15:11:38 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141203141138.GA27516@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20141105140817.GA24310@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141105140817.GA24310@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yqSMd1OfDr--36JmtYAvqZCxHkM Subject: Re: [netmod] VRFY :Y13: allow multiple inheritance for identities 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, 03 Dec 2014 14:11:44 -0000 On Wed, Nov 05, 2014 at 03:08:17PM +0100, Juergen Schoenwaelder wrote: > The 2014-10-15 virtual interim meeting proposal is to adopt Y13-01. > Please speak up by Wednesday 2014-11-12 if you disagree with this > proposal. > > For more details, see the issues list and the virtual interim meeting > minutes available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > Reviewing the discussion, I tend to move this to the EDIT state since I did not see an strong objections and it seems to be implementable. If you disagree, make your point now. /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 Dec 3 06:41:03 2014 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 B69331A1B22 for ; Wed, 3 Dec 2014 06:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 1pbioimGfkKm for ; Wed, 3 Dec 2014 06:41:01 -0800 (PST) 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 654351A1AD9 for ; Wed, 3 Dec 2014 06:41:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 38EE6103A for ; Wed, 3 Dec 2014 15:41:00 +0100 (CET) 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 Yz62jYpiHV2v for ; Wed, 3 Dec 2014 15:40:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 3 Dec 2014 15:40:59 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4697220017 for ; Wed, 3 Dec 2014 15:40:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Zku6hcjUSST2; Wed, 3 Dec 2014 15:40:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24A5D2002C; Wed, 3 Dec 2014 15:40:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4B3AA2FE9F5D; Wed, 3 Dec 2014 15:40:56 +0100 (CET) Date: Wed, 3 Dec 2014 15:40:56 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141203144056.GA27469@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eZB_26XIJSVrFZdhkG18CBQ_JnI Subject: [netmod] netmod virtual interim meeting 2014-12-03 details 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, 03 Dec 2014 14:41:02 -0000 Hi, the webex information was posted to the list and I am not repeating it here. We will use this etherpad instance: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2014-12-03?useMonospaceFont=true Here is the list of things I think we have to work through: * Y09 introduce optional keys Martin did writeup Y09-03. On 2014-11-19, we agreed to Y09-03. This should be a quick check that we are still in sync on this. There was quite some mailing list discussion as well. It seems this boils down to the question whether expanding the syntax of instance identifiers falls into the scope of YANG 1.1. * Y16 module advertisement optimization Martin has done his action item and we should try to decide between Y16-01, Y16-02, and Y16-03. * Y18 fix "when" expression context problem Did Martin complete the action item? If so, can we wrap this up? * Y59 restrict use of 64-bit numbers in XPath expressions New issue, no reaction on the mailing list so far. Should we propose adoption as a bug fix / clarification issue? * Y25 make enum numbering purely informative and optional Last time we discussed this we reached rough concensus for Y25-01. Shall we try to resolve this on the list? If so, JS to create a thread, e.g., to VRFY adoption of Y25-01 and then we will see. * Y26 allow mandatory nodes in augment Discussion on the list went into philosophical aspects. The question is whether someone can write down rules in which conditions adding mandatory nodes in an augment is OK. Volunteers for a homework? * Y58 associate an actions with a data node Verification failed since there is no NACM support for actions nor are actions part of the NETCONF architecture (Andy). Phil questions the need for actions since everything can be done with RPCs. Changed back to OPEN. Need to decide how to proceed with this one. * Y34 remove/deprecate/replace the 'anyxml' statement Quite some debate on the mailing list. Apparently some think anydata means 'any data in the encoding used' while others think 'anydata is data that can be modelled in YANG'. Andy suggested to restrict what can be in anyxml. We also see differences in opinion what the function of an encoding really is. Another obstacle are the lexical representation rules for instance-identifier (9.13.3 of RFC 6020). * Y49 clarify nested submodule behavior Need to discuss Martin's solution proposal Y49-03. * Y57 non-unique leaf-list [...] * Y45 better conformance mechanism [...] /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 Dec 3 06:47:47 2014 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 5DD611A1B22 for ; Wed, 3 Dec 2014 06:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 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, WEIRD_PORT=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 QVhDyix644da for ; Wed, 3 Dec 2014 06:47:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E461A1B01 for ; Wed, 3 Dec 2014 06:47:43 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 8857E13F853; Wed, 3 Dec 2014 15:47:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417618061; bh=yop63puiPODu4/L6flCjLaHPNHqzMW2mlR3yawnG208=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yLv/AtYHUnq0mhnwf41+zi7yMUvw1wmK9RUPWZYvDD7DEPaNmYNgfl482RvAL+VHV fTbh2uzEu8bvW+fcXDva9MfClK2WQP3tURNtp3crVvcCAxEGC3pIVvPXM3fSvH4ObC JnauJuFn4u69lpjiYetacQY4gDTeksb1iU313vTY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20141203144056.GA27469@elstar.local> Date: Wed, 3 Dec 2014 15:47:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86B1615D-827D-4250-833D-A444A4042381@nic.cz> References: <20141203144056.GA27469@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HHqIXcJOwofsY-OBnoG15E16ckY Cc: netmod@ietf.org Subject: Re: [netmod] netmod virtual interim meeting 2014-12-03 details 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, 03 Dec 2014 14:47:45 -0000 Hi, I added a new alternative solution Y49-04 and I=E2=80=99d like to = discuss it. Lada > On 03 Dec 2014, at 15:40, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > the webex information was posted to the list and I am not repeating it > here. We will use this etherpad instance: >=20 > = http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-20= 14-12-03?useMonospaceFont=3Dtrue >=20 > Here is the list of things I think we have to work through: >=20 > * Y09 introduce optional keys >=20 > Martin did writeup Y09-03. On 2014-11-19, we agreed to Y09-03. This > should be a quick check that we are still in sync on this. There was > quite some mailing list discussion as well. It seems this boils down > to the question whether expanding the syntax of instance identifiers > falls into the scope of YANG 1.1. >=20 > * Y16 module advertisement optimization >=20 > Martin has done his action item and we should try to decide between > Y16-01, Y16-02, and Y16-03. >=20 > * Y18 fix "when" expression context problem >=20 > Did Martin complete the action item? If so, can we wrap this up? >=20 > * Y59 restrict use of 64-bit numbers in XPath expressions >=20 > New issue, no reaction on the mailing list so far. Should we propose > adoption as a bug fix / clarification issue? >=20 > * Y25 make enum numbering purely informative and optional >=20 > Last time we discussed this we reached rough concensus for > Y25-01. Shall we try to resolve this on the list? If so, JS to > create a thread, e.g., to VRFY adoption of Y25-01 and then we will > see. >=20 > * Y26 allow mandatory nodes in augment >=20 > Discussion on the list went into philosophical aspects. The question > is whether someone can write down rules in which conditions adding > mandatory nodes in an augment is OK. Volunteers for a homework? >=20 > * Y58 associate an actions with a data node >=20 > Verification failed since there is no NACM support for actions nor > are actions part of the NETCONF architecture (Andy). Phil questions > the need for actions since everything can be done with RPCs. Changed > back to OPEN. Need to decide how to proceed with this one. >=20 > * Y34 remove/deprecate/replace the 'anyxml' statement >=20 > Quite some debate on the mailing list. Apparently some think anydata > means 'any data in the encoding used' while others think 'anydata is > data that can be modelled in YANG'. Andy suggested to restrict what > can be in anyxml. We also see differences in opinion what the > function of an encoding really is. Another obstacle are the lexical > representation rules for instance-identifier (9.13.3 of RFC 6020). >=20 > * Y49 clarify nested submodule behavior >=20 > Need to discuss Martin's solution proposal Y49-03. >=20 > * Y57 non-unique leaf-list >=20 > [...] >=20 > * Y45 better conformance mechanism >=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 > _______________________________________________ > 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 Dec 3 06:50:13 2014 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 1CEFF1A1B32 for ; Wed, 3 Dec 2014 06:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTlunAwmDAwB for ; Wed, 3 Dec 2014 06:49:57 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2D91A1B5D for ; Wed, 3 Dec 2014 06:49:49 -0800 (PST) Received: from localhost (unknown [75.35.230.210]) by mail.tail-f.com (Postfix) with ESMTPSA id B3E8F1280B6D; Wed, 3 Dec 2014 15:49:47 +0100 (CET) Date: Wed, 03 Dec 2014 15:49:47 +0100 (CET) Message-Id: <20141203.154947.1865348500323435719.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141203144056.GA27469@elstar.local> References: <20141203144056.GA27469@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DXnGvJrEgUZ0Ac2OD4-1sF5fV6E Cc: netmod@ietf.org Subject: Re: [netmod] netmod virtual interim meeting 2014-12-03 details 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, 03 Dec 2014 14:50:02 -0000 Hi, I am sorry for the late notice, but I am travelling and cannot join the meeting today. Some quick comments inline. Juergen Schoenwaelder wrote: > * Y09 introduce optional keys > > Martin did writeup Y09-03. On 2014-11-19, we agreed to Y09-03. This > should be a quick check that we are still in sync on this. There was > quite some mailing list discussion as well. It seems this boils down > to the question whether expanding the syntax of instance identifiers > falls into the scope of YANG 1.1. > > * Y16 module advertisement optimization > > Martin has done his action item and we should try to decide between > Y16-01, Y16-02, and Y16-03. > > * Y18 fix "when" expression context problem > > Did Martin complete the action item? If so, can we wrap this up? No I missed this one. > * Y59 restrict use of 64-bit numbers in XPath expressions > > New issue, no reaction on the mailing list so far. Should we propose > adoption as a bug fix / clarification issue? > > * Y25 make enum numbering purely informative and optional > > Last time we discussed this we reached rough concensus for > Y25-01. Shall we try to resolve this on the list? If so, JS to > create a thread, e.g., to VRFY adoption of Y25-01 and then we will > see. I am still against this. It doesn't solve any realy problem, and it removes a feature from 1.0. /martin > * Y26 allow mandatory nodes in augment > > Discussion on the list went into philosophical aspects. The question > is whether someone can write down rules in which conditions adding > mandatory nodes in an augment is OK. Volunteers for a homework? > > * Y58 associate an actions with a data node > > Verification failed since there is no NACM support for actions nor > are actions part of the NETCONF architecture (Andy). Phil questions > the need for actions since everything can be done with RPCs. Changed > back to OPEN. Need to decide how to proceed with this one. > > * Y34 remove/deprecate/replace the 'anyxml' statement > > Quite some debate on the mailing list. Apparently some think anydata > means 'any data in the encoding used' while others think 'anydata is > data that can be modelled in YANG'. Andy suggested to restrict what > can be in anyxml. We also see differences in opinion what the > function of an encoding really is. Another obstacle are the lexical > representation rules for instance-identifier (9.13.3 of RFC 6020). > > * Y49 clarify nested submodule behavior > > Need to discuss Martin's solution proposal Y49-03. > > * Y57 non-unique leaf-list > > [...] > > * Y45 better conformance mechanism > > [...] > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Dec 3 13:55:36 2014 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 5C0C11ACD22 for ; Wed, 3 Dec 2014 13:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K45s6nZ846AJ for ; Wed, 3 Dec 2014 13:55:31 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB33F1ACD1F for ; Wed, 3 Dec 2014 13:55:30 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ms9so13166652lab.24 for ; Wed, 03 Dec 2014 13:55:28 -0800 (PST) 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=44DpVYyj+Jb+1Lmj/gEgmsd4U4URuZDpaJq8riyJP5I=; b=g9UFh7WvKZHwy6BiVvN9Rz+Clpyq24AWFpai9jOgJ7jWNkQAsZB/pJRMS1mYTP5zsD zArImWAeQHpl5rgqMPpxug3y3FVXyt5UPZ69MwRfCHLTdK1BoCJkLDbyL7zuMvx0FZsT Gj3EeXHPVTlLHrF2ypjq4ZQuXCvRsOVuZnCLfafHygtiNdjGtgFZuiZuX0OyFEQQX73e NLeyEjoUA4kp14w2g6anE2hNPsuzRrQyWma+Gv3ZZ4apc2inAU+giUyPyaGONSrGT9Ti yrhrcdncOjoUsqXmOMNFDgJE73O8uJPoTCy79fj5fsw5fDMhS6AYlYhEsg7A2wMpSkNG OCVw== X-Gm-Message-State: ALoCoQn8R42vrrBqGPsYIPYo+t4EjAz55nYLronAQHj3r8ylISCCJsXlZ0LdpgPBzRDmGSN0XFqm MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr2249900lbz.100.1417643728368; Wed, 03 Dec 2014 13:55:28 -0800 (PST) Received: by 10.112.157.233 with HTTP; Wed, 3 Dec 2014 13:55:28 -0800 (PST) In-Reply-To: <201411191520.sAJFKV77089498@idle.juniper.net> References: <20141119.101745.2177484091559539160.mbj@tail-f.com> <201411191520.sAJFKV77089498@idle.juniper.net> Date: Wed, 3 Dec 2014 13:55:28 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BjkzRWF_ber38HixfYNRUzhaYkk Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Wed, 03 Dec 2014 21:55:33 -0000 On Wed, Nov 19, 2014 at 7:20 AM, Phil Shafer wrote: > Martin Bjorklund writes: >>(*) section 5 might be needed unless we make include-by revision >>mandatory. But I think I am the only one that thinks that would be a >>good solution. > > I wouldn't say make it mandatory, but certainly mandatory for > anything externally published, including IETF work. Using > revision agnostic imports might be suitable for internal and > development work, but once a spec is supposed to be fixed and > hardened, all imports should be by-revision. > >>+1. A lot of the confusion comes from this. Obviously, the spec is >>not clear on this - it doesn't specify what it means to "implement" a >>module. > > Yes, this should be clarified. > This might be the least painful solution, except it needs some clarification. The most common use of typedefs and groupings is to use them in the module they are defined, so conformance for meta-data and real data has to be separated. I think this simple set of rules might work: 1) Import-by-revision and include-by-revision everywhere 2) imported meta-data from A is from the specified revision when used in B 3) for conformance of real objects in A, the most recent advertised revision must be implemented 4) even if multiple revisions of A are advertised (B->A.1, C->A.2) any protocol accessible data must use the most recent advertised revision 5) not clear if the most recent revision of any identities and extensions needs to be used or not >>It must be ok to advertise b and a@2014-05-01. > > Yes, since the contract for 'a' remains in place. > >>A very simple alternative would be to not allow updated typedefs and >>groupings at all. > > This shifts the version tracking task on to the author and > reader. "foo_v2", "foo_v3", "foo_v2014-04-01", etc. The > updating costs and possibility of errors would be significant. > > Thanks, > Phil > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 4 01:18:44 2014 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 39FE31A0113 for ; Thu, 4 Dec 2014 01:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE8n4gCXt6ji for ; Thu, 4 Dec 2014 01:18:19 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1A51A0101 for ; Thu, 4 Dec 2014 01:18:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6998154060F for ; Thu, 4 Dec 2014 10:18:17 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1xopSj2kR5l for ; Thu, 4 Dec 2014 10:18:11 +0100 (CET) Received: from localhost (unknown [195.113.220.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 706A35402AB for ; Thu, 4 Dec 2014 10:18:11 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 04 Dec 2014 10:18:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Qa8orIGMMdR7p71vBD5BcieVphg Subject: [netmod] Y59 action 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, 04 Dec 2014 09:18:29 -0000 Hi, as per discussion during yesterday's virtual interim, I updated Solution Y59-01. This is the new text proposed for sec. 6.4 (before subsection 6.4.1): Numbers in XPath 1.0 are IEEE 754 double-precision floating-point values, see Section 3.5 in [XPATH]. This means that some values of uint64, int64 and decimal64 types (Section 9.2 and 9.3) cannot be exactly represented in XPath expressions. Therefore, due caution should be exercised when using nodes with 64-bit numeric values in XPath expressions. In particular, numerical comparisons involving equality may yield unexpected results. For example, consider the following definition: leaf lxiv { type decimal64 { fraction-digits 18; } must ". <= 10"; } An instance of the "lxiv" leaf having the value of 10.0000000000000001 will then successfully pass validation. Please comment. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 4 02:14:16 2014 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 55BAF1A0149 for ; Thu, 4 Dec 2014 02:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhdljjR9uuCV for ; Thu, 4 Dec 2014 02:14:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C6B1A0146 for ; Thu, 4 Dec 2014 02:14:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DF29754060F for ; Thu, 4 Dec 2014 11:14:07 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzzfg00CUpGM for ; Thu, 4 Dec 2014 11:14:03 +0100 (CET) Received: from localhost (unknown [195.113.220.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B52CF5401F1 for ; Thu, 4 Dec 2014 11:14:03 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 04 Dec 2014 11:14:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BntmoB018W-LqVyiVECHV8n4IRI Subject: [netmod] backward compatibility 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, 04 Dec 2014 10:14:15 -0000 Hi, it seems that most YANG 1.1 issues where we cannot reach consensus have to do with old client compatibility requirements in Sec. 11, and similar rules for augments. One example: Y25 would become a non-issue if it wasn't for this item in Sec. 11: o An "enumeration" type may have new enums added, provided the old enums's values do not change. Maybe we should really consider lifting or relaxing these rules because: - they bind our hands and may lead to ugly modules that contain tricky workarounds, obsolete nodes or groupings, and/or whose constraints are too loose; - the rules are not fool-proof and backward compatibility may still be broken in a number of ways (I can give examples if somebody is interested); - when we upgrade our existing modules to YANG 1.1, there will be no backward compatibility; - vendors wanting to introduce incompatible changes will always have the option to rename the module, which is IMO much worse for all clients, old or new. I think it is fully appropriate to demand a strict discipline wrt revision management and backward compatibility for modules that are being developed in the IETF, but then corresponding guidelines should go to 6087bis. And even then, I believe that at this stage RFCs containing YANG modules should still be tagged with clearly visible road work signs - everybody has to understand that incompatible changes may sometimes be necessary. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 4 07:58:02 2014 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 1C6BD1AD480 for ; Thu, 4 Dec 2014 07:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GfwAM9tjQau2 for ; Thu, 4 Dec 2014 07:57:59 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068BD1AD44A for ; Thu, 4 Dec 2014 07:57:58 -0800 (PST) Received: from BLUPR05CA0073.namprd05.prod.outlook.com (10.141.20.43) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 4 Dec 2014 15:57:36 +0000 Received: from BN1AFFO11FD036.protection.gbl (2a01:111:f400:7c10::153) by BLUPR05CA0073.outlook.office365.com (2a01:111:e400:855::43) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Thu, 4 Dec 2014 15:57:35 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1AFFO11FD036.mail.protection.outlook.com (10.58.52.240) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Thu, 4 Dec 2014 15:57:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 4 Dec 2014 07:57:34 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB4FvWR61691; Thu, 4 Dec 2014 07:57:33 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB4FvIso027338; Thu, 4 Dec 2014 10:57:19 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412041557.sB4FvIso027338@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Thu, 4 Dec 2014 10:57:18 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(69596002)(106466001)(31966008)(6806004)(54356999)(97736003)(86362001)(105596002)(92566001)(4396001)(92726001)(107046002)(81156004)(48376002)(84676001)(120916001)(99396003)(87936001)(64706001)(47776003)(20776003)(53416004)(50466002)(62966003)(77156002)(50986999)(76506005)(77096005)(110136001)(46102003)(68736005)(103666002)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB433; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; X-Forefront-PRVS: 041517DFAB Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Cv52Ng2b5vvD4fJppuRaxVP_q6g Cc: netmod@ietf.org Subject: Re: [netmod] backward compatibility 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, 04 Dec 2014 15:58:01 -0000 Ladislav Lhotka writes: >And even then, I believe that at this stage RFCs containing YANG modules >should still be tagged with clearly visible road work signs - everybody >has to understand that incompatible changes may sometimes be necessary. People are using NETCONF and YANG to perform real work. Telling them that this technology isn't stable enough for real work use will result in them choosing other technologies. In fact, I would strongly (very strongly) suggest the opposite. Any change that we are considering that contributes even vaguely to the perception that this technology isn't stable enough for real work should be avoided. Clarifications and coverage of odd corner cases are acceptable. Real changes are not. Thanks, Phil From nobody Thu Dec 4 08:11:48 2014 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 CE4A91A1A15 for ; Thu, 4 Dec 2014 08:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vrIE59NPx_t7 for ; Thu, 4 Dec 2014 08:11:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944371A1B6F for ; Thu, 4 Dec 2014 08:11:33 -0800 (PST) Received: from BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) by BN1PR05MB027.namprd05.prod.outlook.com (10.255.202.152) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 16:11:32 +0000 Received: from CO2PR05CA029.namprd05.prod.outlook.com (10.141.241.157) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 16:11:31 +0000 Received: from BN1AFFO11FD024.protection.gbl (2a01:111:f400:7c10::137) by CO2PR05CA029.outlook.office365.com (2a01:111:e400:1429::29) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Thu, 4 Dec 2014 16:11:30 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1AFFO11FD024.mail.protection.outlook.com (10.58.52.84) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Thu, 4 Dec 2014 16:11:29 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 4 Dec 2014 08:11:25 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB4GBNR75591; Thu, 4 Dec 2014 08:11:24 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB4GBAv4027422; Thu, 4 Dec 2014 11:11:10 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412041611.sB4GBAv4027422@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Thu, 4 Dec 2014 11:11:10 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(164054003)(189002)(46102003)(97736003)(120916001)(87936001)(31966008)(76506005)(20776003)(21056001)(47776003)(77096005)(50466002)(77156002)(48376002)(62966003)(19580405001)(19580395003)(107046002)(69596002)(15975445006)(6806004)(68736005)(64706001)(84676001)(53416004)(50986999)(54356999)(103666002)(92566001)(92726001)(110136001)(99396003)(575784001)(86362001)(4396001)(106466001)(105596002)(81156004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Forefront-PRVS: 041517DFAB Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB027; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/M95N1TYqPtEN-NE-2IVPMl6Eri4 Cc: netmod@ietf.org Subject: Re: [netmod] Y59 action 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, 04 Dec 2014 16:11:47 -0000 I'm assuming the reader's reaction to this will be the same as mine: it sounds crazy. I understand the need, but without talking about type conversion and rounding, it will be confusing. And talking about those topics will also be confusing. Is there a more complete discussion of this topic we can refer to? Thanks, Phil Ladislav Lhotka writes: >Hi, > >as per discussion during yesterday's virtual interim, I updated Solution >Y59-01. This is the new text proposed for sec. 6.4 (before subsection >6.4.1): > > Numbers in XPath 1.0 are IEEE 754 double-precision floating-point > values, see Section 3.5 in [XPATH]. This means that some values of > uint64, int64 and decimal64 types (Section 9.2 and 9.3) cannot be > exactly represented in XPath expressions. Therefore, due caution should > be exercised when using nodes with 64-bit numeric values in XPath > expressions. In particular, numerical comparisons involving equality > may yield unexpected results. > > For example, consider the following definition: > > leaf lxiv { > type decimal64 { > fraction-digits 18; > } > must ". <= 10"; > } > > An instance of the "lxiv" leaf having the value of > 10.0000000000000001 will then successfully pass validation. > > >Please comment. > >Lada > >-- >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 Dec 4 08:21:52 2014 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 66FCC1A1B9E for ; Thu, 4 Dec 2014 08:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbcW1o965I3n for ; Thu, 4 Dec 2014 08:21:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 221861A0164 for ; Thu, 4 Dec 2014 08:21:49 -0800 (PST) Received: from localhost (unknown [75.35.230.210]) by mail.tail-f.com (Postfix) with ESMTPSA id A901D1280B68; Thu, 4 Dec 2014 17:21:46 +0100 (CET) Date: Thu, 04 Dec 2014 17:21:45 +0100 (CET) Message-Id: <20141204.172145.1693539153861912929.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201412041611.sB4GBAv4027422@idle.juniper.net> References: <201412041611.sB4GBAv4027422@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fun1NTjSgTQBXw6-5GvuwqZ12y8 Cc: netmod@ietf.org Subject: Re: [netmod] Y59 action 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, 04 Dec 2014 16:21:51 -0000 Phil Shafer wrote: > I'm assuming the reader's reaction to this will be the same as mine: > it sounds crazy. I understand the need, but without talking about > type conversion and rounding, it will be confusing. And talking > about those topics will also be confusing. Is there a more complete > discussion of this topic we can refer to? How about adding this to the guidelines document instead? /martin > > Thanks, > Phil > > > > Ladislav Lhotka writes: > >Hi, > > > >as per discussion during yesterday's virtual interim, I updated Solution > >Y59-01. This is the new text proposed for sec. 6.4 (before subsection > >6.4.1): > > > > Numbers in XPath 1.0 are IEEE 754 double-precision floating-point > > values, see Section 3.5 in [XPATH]. This means that some values of > > uint64, int64 and decimal64 types (Section 9.2 and 9.3) cannot be > > exactly represented in XPath expressions. Therefore, due caution should > > be exercised when using nodes with 64-bit numeric values in XPath > > expressions. In particular, numerical comparisons involving equality > > may yield unexpected results. > > > > For example, consider the following definition: > > > > leaf lxiv { > > type decimal64 { > > fraction-digits 18; > > } > > must ". <= 10"; > > } > > > > An instance of the "lxiv" leaf having the value of > > 10.0000000000000001 will then successfully pass validation. > > > > > >Please comment. > > > >Lada > > > >-- > >Ladislav Lhotka, CZ.NIC Labs > >PGP Key ID: E74E8C0C > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Dec 4 08:25:12 2014 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 D6FE41AD490 for ; Thu, 4 Dec 2014 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YmNzumcebup2 for ; Thu, 4 Dec 2014 08:25:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B314E1AD49C for ; Thu, 4 Dec 2014 08:25:06 -0800 (PST) Received: from BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) by BN1PR05MB186.namprd05.prod.outlook.com (10.255.205.13) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 16:24:44 +0000 Received: from BY2PR05CA031.namprd05.prod.outlook.com (10.141.250.21) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 16:24:42 +0000 Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::174) by BY2PR05CA031.outlook.office365.com (2a01:111:e400:2c5f::21) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Thu, 4 Dec 2014 16:24:41 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Thu, 4 Dec 2014 16:24:40 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 4 Dec 2014 08:24:33 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB4GOSR87379; Thu, 4 Dec 2014 08:24:31 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB4GOEIJ027513; Thu, 4 Dec 2014 11:24:14 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412041624.sB4GOEIJ027513@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 4 Dec 2014 11:24:14 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(6806004)(64706001)(68736005)(69596002)(107046002)(53416004)(84676001)(77096005)(47776003)(21056001)(50466002)(20776003)(77156002)(48376002)(62966003)(105596002)(81156004)(106466001)(103666002)(50986999)(54356999)(4396001)(86362001)(92566001)(110136001)(99396003)(92726001)(97736003)(120916001)(230783001)(46102003)(76506005)(87936001)(31966008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Forefront-PRVS: 041517DFAB Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB186; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-7BnOMsQN_Gf4m9c63680y8gUu0 Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Thu, 04 Dec 2014 16:25:11 -0000 Andy Bierman writes: >The most common use of typedefs and groupings is to use them in >the module they are defined, so conformance for meta-data and real data >has to be separated. We should be careful of the term "meta-data" here. Metadata is data that describes data, so all YANG is meta data. I think you are talking about typedefs and groupings which might be better termed "macro data". >I think this simple set of rules might work: > 1) Import-by-revision and include-by-revision everywhere > 2) imported meta-data from A is from the specified revision > when used in B > 3) for conformance of real objects in A, the most recent advertised > revision must be implemented We should clarify that advertising module A at revision X means that all top-level containers, lists, leafs, leaf-lists and augments are supported. Imported modules used by module A do not need to be advertised. Advertising imported modules mean that you are supporting all top-level containers, lists, leafs, leaf-lists and augments from that module, without regard to their use in A. If module A support a top-level container, and module B augments that top-level container, advertising B without advertising A is a logic error. > 4) even if multiple revisions of A are advertised (B->A.1, C->A.2) > any protocol accessible data must use the most recent > advertised revision Only one revision of any module should ever be advertised. By advertising, you are saying that you will be bound by the contract given in that module, so saying you support multiple revisions would be a logic error. > 5) not clear if the most recent revision of any identities and extensions > needs to be used or not This is trickier, but still clear. If A-2014-01-01 lists an extension and B-2014-01-02 imports and uses it, then advertising B-2014-01-02 means that anything in B-2014-01-02 that uses that extension means the A-2014-01-01 implementation of that extension. If A-2014-02-01 change the meaning of the extension (is that even allowed?) and C-2014-02-02 uses it, then anything in C-2014-02-02 wants the A-2014-01-01 implementation of that extension. B-2014-01-02 would continue to want the older definition. Thanks, Phil From nobody Thu Dec 4 08:28:46 2014 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 13D7F1AD4B2 for ; Thu, 4 Dec 2014 08:28:39 -0800 (PST) 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 me0orxeoxGMY for ; Thu, 4 Dec 2014 08:28:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21CE1AD4B0 for ; Thu, 4 Dec 2014 08:28:37 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 3B73813FAFC; Thu, 4 Dec 2014 17:28:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417710516; bh=SuniJQ2MYBgFs9s8lwCb8CprHBIFzW0R6lQWHPXC5E0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iUQLIaRBs7tRCiPUxw0qsYBdg5aq52VfTBUOQZzUmp4F4fMTYZl9aTqtnLP4AG/Kv ZTv4uocaRwQjqJ2UAzvN1HQr63jcGnPVjRh465/X8wN5oZP1D6MKjB/VpgeHq1p8TD oYyJuXWFihWNsyfB60R255ECUiLtzJ08907eXE48= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <201412041557.sB4FvIso027338@idle.juniper.net> Date: Thu, 4 Dec 2014 17:28:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B4AE4DD-FF9E-4583-A3C0-90EE6C481B8A@nic.cz> References: <201412041557.sB4FvIso027338@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FEcvtj70uBoEe_w8GMgyGmQ_ZGw Cc: netmod@ietf.org Subject: Re: [netmod] backward compatibility 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, 04 Dec 2014 16:28:39 -0000 > On 04 Dec 2014, at 16:57, Phil Shafer wrote: >=20 > Ladislav Lhotka writes: >> And even then, I believe that at this stage RFCs containing YANG = modules >> should still be tagged with clearly visible road work signs - = everybody >> has to understand that incompatible changes may sometimes be = necessary. >=20 > People are using NETCONF and YANG to perform real work. Telling > them that this technology isn't stable enough for real work use > will result in them choosing other technologies. >=20 > In fact, I would strongly (very strongly) suggest the opposite. > Any change that we are considering that contributes even vaguely to > the perception that this technology isn't stable enough for real > work should be avoided. Clarifications and coverage of odd corner > cases are acceptable. Real changes are not. As the standard modules go, we are still at the very beginning, so how = could the IETF data model base be considered stable enough? Pretending = that both the language and the modules can be done at first try, and = what remains are only cosmetic changes, is IMO short-sighted. Routing folks are now evaluating the routing module, and I expect that = quite a few things in it may need revamping. The module was already = close to becoming an RFC but, in fact, we would be stuck if that had = happened. Some of the changes that are being proposed would become = impossible due to the Sec. 11 rules. What would you suggest in that case = - start a new routing-plus module? Lada >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 4 08:28:59 2014 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 551B61AD486 for ; Thu, 4 Dec 2014 08:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ilpiVtbK0Wpn for ; Thu, 4 Dec 2014 08:28:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D650F1AD4B1 for ; Thu, 4 Dec 2014 08:28:48 -0800 (PST) Received: from BY2PR05CA032.namprd05.prod.outlook.com (10.141.250.22) by DM2PR05MB448.namprd05.prod.outlook.com (10.141.104.152) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 16:28:47 +0000 Received: from BL2FFO11FD031.protection.gbl (2a01:111:f400:7c09::189) by BY2PR05CA032.outlook.office365.com (2a01:111:e400:2c5f::22) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Thu, 4 Dec 2014 16:28:46 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD031.mail.protection.outlook.com (10.173.160.71) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Thu, 4 Dec 2014 16:28:46 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 4 Dec 2014 08:28:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB4GSbR91228; Thu, 4 Dec 2014 08:28:40 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB4GSNqw027607; Thu, 4 Dec 2014 11:28:23 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412041628.sB4GSNqw027607@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20141204.172145.1693539153861912929.mbj@tail-f.com> Date: Thu, 4 Dec 2014 11:28:23 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(51704005)(189002)(24454002)(46102003)(92566001)(21056001)(92726001)(6806004)(99396003)(97736003)(19580395003)(19580405001)(87936001)(120916001)(20776003)(50466002)(4396001)(47776003)(86362001)(53416004)(103666002)(76506005)(77096005)(54356999)(48376002)(68736005)(50986999)(110136001)(62966003)(81156004)(77156002)(106466001)(84676001)(69596002)(105596002)(64706001)(31966008)(107046002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB448; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB448; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB448; X-Forefront-PRVS: 041517DFAB Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB448; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aTQGvFCJVGu-Sr8cIr1GrR3nEMY Cc: netmod@ietf.org Subject: Re: [netmod] Y59 action 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, 04 Dec 2014 16:28:54 -0000 Martin Bjorklund writes: >Phil Shafer wrote: >> I'm assuming the reader's reaction to this will be the same as mine: >> it sounds crazy. I understand the need, but without talking about >> type conversion and rounding, it will be confusing. And talking >> about those topics will also be confusing. Is there a more complete >> discussion of this topic we can refer to? > >How about adding this to the guidelines document instead? Fine w/ me. It's a stinky, ugly concept, sort of the dirty underbelly of IEEE math. I had to explain it to my son a couple weeks ago, how his AP-Programming task wasn't working right because it turns out computers don't really like floating point numbers that much. Thanks, Phil From nobody Thu Dec 4 08:42:13 2014 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 7A22E1AD4C7 for ; Thu, 4 Dec 2014 08:42:05 -0800 (PST) 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 xdFIRUhQSfIv for ; Thu, 4 Dec 2014 08:42:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C0C1AD4E4 for ; Thu, 4 Dec 2014 08:41:54 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id C7E60140106; Thu, 4 Dec 2014 17:41:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417711312; bh=5wRrxMM47AK73d2mgqPREsberdGsv9PlDAcLeKzJXRM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MaBaa6BrTjeuo1UDjZTqFGPKr0SAQylPbxuKyCsaujNNZ6ptn5GuF8JWPEC/w8DGS 3SsAo+r1OQYC8z+dP4wijEcII0SdcnC+0nO7rx28RwvVdxRVUcYKITzsBPY+oJ1BQ2 Lqf3eA1Vbt2cjJIeOwkG8c8cYAQ+uvIIXwGRE4QI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20141204.172145.1693539153861912929.mbj@tail-f.com> Date: Thu, 4 Dec 2014 17:41:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412041611.sB4GBAv4027422@idle.juniper.net> <20141204.172145.1693539153861912929.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wnntFskcr_pPbWgNJlWJ01wtKZA Cc: netmod@ietf.org Subject: Re: [netmod] Y59 action 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, 04 Dec 2014 16:42:05 -0000 > On 04 Dec 2014, at 17:21, Martin Bjorklund wrote: >=20 > Phil Shafer wrote: >> I'm assuming the reader's reaction to this will be the same as mine: >> it sounds crazy. I understand the need, but without talking about >> type conversion and rounding, it will be confusing. And talking >> about those topics will also be confusing. Is there a more complete >> discussion of this topic we can refer to? >=20 > How about adding this to the guidelines document instead? It is a potential security issue so IMO it needs to be mentioned in the = YANG spec. I think that everybody who has ever worked with floats must = be familiar with this problem. Of course, it may be considered a PR problem but I don=E2=80=99t think = that papering over it helps. Lada >=20 >=20 > /martin >=20 >=20 >>=20 >> Thanks, >> Phil >>=20 >>=20 >>=20 >> Ladislav Lhotka writes: >>> Hi, >>>=20 >>> as per discussion during yesterday's virtual interim, I updated = Solution >>> Y59-01. This is the new text proposed for sec. 6.4 (before = subsection >>> 6.4.1): >>>=20 >>> Numbers in XPath 1.0 are IEEE 754 double-precision floating-point >>> values, see Section 3.5 in [XPATH]. This means that some values of >>> uint64, int64 and decimal64 types (Section 9.2 and 9.3) cannot be >>> exactly represented in XPath expressions. Therefore, due caution = should >>> be exercised when using nodes with 64-bit numeric values in XPath >>> expressions. In particular, numerical comparisons involving = equality >>> may yield unexpected results. >>>=20 >>> For example, consider the following definition: >>>=20 >>> leaf lxiv { >>> type decimal64 { >>> fraction-digits 18; >>> } >>> must ". <=3D 10"; >>> } >>>=20 >>> An instance of the "lxiv" leaf having the value of >>> 10.0000000000000001 will then successfully pass validation. >>>=20 >>>=20 >>> Please comment. >>>=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 >> _______________________________________________ >> 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 Dec 4 09:30:24 2014 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 D18411A1B92 for ; Thu, 4 Dec 2014 09:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWgCi0k4Trah for ; Thu, 4 Dec 2014 09:30:18 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B8D1A0393 for ; Thu, 4 Dec 2014 09:30:17 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so15817985lbj.37 for ; Thu, 04 Dec 2014 09:30:16 -0800 (PST) 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=yAwTinFnc7NgDSFHtGq9HzwhUT6EAfFn2zhFtX0kqW4=; b=aszMztKim4r/PuDTFEyTJIs40Bq4SzNAtaZj847DeNCgL0ShiEPKXFizAMD5wA72Bo tiXcor1wAHcbc0dHf0qPd6j2sOeG2WoUPt69eSu116SZOTks2CNRQl98gRUABwFQp1XW vO+L+J5U9/dc6ZGSgTjNp8bd3wO/Wh5wn1GY8nZSj9+uiJJNJ+UoqKC4HH/15azTq3WV ilObCzO1aIMVnXHTqB1zwM9UIqbx3aFQi1w9p4DliyfqXGpMkh0A+8PnDreYf8I6RK9c o1GM5jry6bQfJ5Zx/XoTY9ff4H9bAgn7CxVshHap88GVHR1c3fv5EawoTHmVX5tnfUld Vz0g== X-Gm-Message-State: ALoCoQmtq0HEtu1aQLmYb7iRr9V9WJuuvbQwH2u3IpTfYuFnL+pjkESmIzzu0mhgMOExyazy7kRW MIME-Version: 1.0 X-Received: by 10.112.8.69 with SMTP id p5mr10491768lba.97.1417714216201; Thu, 04 Dec 2014 09:30:16 -0800 (PST) Received: by 10.112.157.233 with HTTP; Thu, 4 Dec 2014 09:30:16 -0800 (PST) In-Reply-To: <201412041557.sB4FvIso027338@idle.juniper.net> References: <201412041557.sB4FvIso027338@idle.juniper.net> Date: Thu, 4 Dec 2014 09:30:16 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/k3SfFEIgdgg4mCRGycsY7LFK_Uk Cc: "netmod@ietf.org" Subject: Re: [netmod] backward compatibility 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, 04 Dec 2014 17:30:22 -0000 On Thu, Dec 4, 2014 at 7:57 AM, Phil Shafer wrote: > Ladislav Lhotka writes: >>And even then, I believe that at this stage RFCs containing YANG modules >>should still be tagged with clearly visible road work signs - everybody >>has to understand that incompatible changes may sometimes be necessary. > > People are using NETCONF and YANG to perform real work. Telling > them that this technology isn't stable enough for real work use > will result in them choosing other technologies. > > In fact, I would strongly (very strongly) suggest the opposite. > Any change that we are considering that contributes even vaguely to > the perception that this technology isn't stable enough for real > work should be avoided. Clarifications and coverage of odd corner > cases are acceptable. Real changes are not. > This does seem to be the intent of the charter, and the intent of calling it YANG 1.1 instead of 1.5 or 2.0. I agree that stability is more important than new features, especially since customers are not really complaining about YANG 1.0 and not asking for YANG 1.1. However, no matter what is in the next version of YANG, all relevant tools need to be updated in order to use the first YANG 1.1 module. Tools that are not updated (not just clients) cannot use the new module or the feature it represents. IMO this is going to be much more important to vendors than some clarifications to YANG. Engineers will be asked to justify the use of YANG 1.1, since tool X will not implement it in time for the software release. So I support some new features like actions, but nothing that changes any data types (like optional keys). > Thanks, > Phil > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 4 13:08:59 2014 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 CDEE61A1A55 for ; Thu, 4 Dec 2014 13:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s1DvrITc-aIl for ; Thu, 4 Dec 2014 13:08:55 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCB91A1B83 for ; Thu, 4 Dec 2014 13:08:54 -0800 (PST) Received: from BL2PR05CA0046.namprd05.prod.outlook.com (10.255.226.46) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 21:08:53 +0000 Received: from BL2FFO11FD016.protection.gbl (2a01:111:f400:7c09::132) by BL2PR05CA0046.outlook.office365.com (2a01:111:e400:c04::46) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Thu, 4 Dec 2014 21:08:52 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Thu, 4 Dec 2014 21:08:52 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 4 Dec 2014 13:08:51 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB4L8nR20598; Thu, 4 Dec 2014 13:08:50 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB4L8al6029461; Thu, 4 Dec 2014 16:08:36 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412042108.sB4L8al6029461@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <9B4AE4DD-FF9E-4583-A3C0-90EE6C481B8A@nic.cz> Date: Thu, 4 Dec 2014 16:08:36 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(4396001)(77156002)(99396003)(64706001)(62966003)(69596002)(53416004)(50466002)(6806004)(48376002)(103666002)(50986999)(54356999)(47776003)(21056001)(20776003)(106466001)(105596002)(86362001)(87936001)(81156004)(92566001)(107046002)(84676001)(31966008)(97736003)(76506005)(46102003)(110136001)(77096005)(68736005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB445; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-Forefront-PRVS: 041517DFAB Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QOF7Z5lcte2M9w2dAYID1S99uhM Cc: netmod@ietf.org Subject: Re: [netmod] backward compatibility 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, 04 Dec 2014 21:08:57 -0000 Ladislav Lhotka writes: >Routing folks are now evaluating the routing module, and I expect that quite a few thing >s in it may need revamping. The module was already close to becoming an RFC but, in fact >, we would be stuck if that had happened. Some of the changes that are being proposed wo >uld become impossible due to the Sec. 11 rules. What would you suggest in that case - st >art a new routing-plus module? Has anyone implemnted the routing module? If not, there's not cost. But many people have implemented YANG engines, so changing the way it works is not without cost. Thanks, Phil From nobody Thu Dec 4 13:53:52 2014 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 EE0471A1EF0 for ; Thu, 4 Dec 2014 13:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O5M6sEgKbiwd for ; Thu, 4 Dec 2014 13:53:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C391A1AA0 for ; Thu, 4 Dec 2014 13:53:44 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB362.namprd05.prod.outlook.com (10.141.51.147) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 21:53:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 21:53:20 +0000 From: Kent Watsen To: Phil Shafer , Andy Bierman Thread-Topic: [netmod] review of draft-bierman-netmod-yang-conformance-04 Thread-Index: AQHQA6H9AlQpYILMKEWxoFxOqEHAjZxnrBeAgABlW4CAFm79AIABNckAgAAIIQA= Date: Thu, 4 Dec 2014 21:53:20 +0000 Message-ID: References: <201412041624.sB4GOEIJ027513@idle.juniper.net> In-Reply-To: <201412041624.sB4GOEIJ027513@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB362; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB362; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(40100003)(20776003)(87936001)(107046002)(99396003)(68736005)(77156002)(64706001)(62966003)(66066001)(122556002)(86362001)(21056001)(36756003)(230783001)(2656002)(83506001)(97736003)(31966008)(105586002)(106116001)(106356001)(101416001)(54356999)(50986999)(99286002)(76176999)(4396001)(46102003)(1941001)(92566001)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB362; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hCvsSdsl2hTO9gieC3t5ji2PFps Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Thu, 04 Dec 2014 21:53:48 -0000 >We should clarify that advertising module A at revision X means >that all top-level containers, lists, leafs, leaf-lists and augments >are supported. Imported modules used by module A do not need to >be advertised. Advertising imported modules mean that you are >supporting all top-level containers, lists, leafs, leaf-lists and >augments from that module, without regard to their use in A. +1 >If module A support a top-level container, and module B augments >that top-level container, advertising B without advertising A >is a logic error. Why an error? It seems more like a MAY than a MUST to me... >Only one revision of any module should ever be advertised. By >advertising, >you are saying that you will be bound by the contract given in that >module, >so saying you support multiple revisions would be a logic error. Yes, since the passed namespace doesn't qualify revision Thanks, Kent From nobody Thu Dec 4 14:39:12 2014 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 083851A8547 for ; Thu, 4 Dec 2014 14:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l62r5QA2WpC for ; Thu, 4 Dec 2014 14:39:08 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BD01A6FF8 for ; Thu, 4 Dec 2014 14:39:07 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so14872607lab.20 for ; Thu, 04 Dec 2014 14:39:06 -0800 (PST) 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=IBpR4SL3o1vz4s+VQjZPe7HSaQuVX5s5Dt/1Ph13mGE=; b=fKSn57X0hfKpb9GYP4gRxag4lyxL59PJXkXsv9KTq5F/P9K+qzbwvGCvUWPfwMoKWY ik1pFXUh72xnMIls9Lgw/vYhK03SASeuTIALt8DMbxhLpTwI9cSf1f0g1s+jcbIJwhy4 46a3Wv52Y3bot64Nen1xbPi1MoHzdqt1TLs+9ozXR+14RhTjgHQE+OgfUMPfptf/DukT vlS+KIJNMVdC3AS2PJPL6YjH1RY7z1enorOSPkQJwRssCjkPU6tRObYAk4iUZwjxcVAD K64Ij/Un6gdgTK09gsQKVBs0trUs+/+UQq60U+/MwHDM8r07j9Xt05ycizMgRn6nfoUw hpLg== X-Gm-Message-State: ALoCoQkmJehj5GOQLKJNVZqdlqQf2QivjYYfm4glxlFQgR46ITb3yOmN1zZM+p57iE1Y34wHxUwJ MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr12183694lau.42.1417732746525; Thu, 04 Dec 2014 14:39:06 -0800 (PST) Received: by 10.112.157.233 with HTTP; Thu, 4 Dec 2014 14:39:06 -0800 (PST) In-Reply-To: References: <201412041624.sB4GOEIJ027513@idle.juniper.net> Date: Thu, 4 Dec 2014 14:39:06 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Bdi7Ch8sS3Cl8BOpYh17f4B-xwo Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Thu, 04 Dec 2014 22:39:10 -0000 On Thu, Dec 4, 2014 at 1:53 PM, Kent Watsen wrote: > > >>We should clarify that advertising module A at revision X means >>that all top-level containers, lists, leafs, leaf-lists and augments >>are supported. Imported modules used by module A do not need to >>be advertised. Advertising imported modules mean that you are >>supporting all top-level containers, lists, leafs, leaf-lists and >>augments from that module, without regard to their use in A. > > +1 > The term "advertise" is no longer accurate. For example, RESTCONF uses the ietf-yang-library to specify all the YANG modules it uses. There is a leaf called conformance to distinguish between a module listed for complete module inventory vs. conformance: leaf conformance { type boolean; mandatory true; description "If 'true', then the server is claiming conformance to the YANG module identified in this entry. If 'false', then the server is not claiming any conformance for the YANG module identified by this entry. The module may be needed for reusable definitions such as extensions, features, identifies, typedefs, or groupings."; } So the server will list all the revisions of module A, but only set the 'conformance' flag to true on 1 of them. > >>If module A support a top-level container, and module B augments >>that top-level container, advertising B without advertising A >>is a logic error. > > Why an error? It seems more like a MAY than a MUST to me... > What happens if B augments /A:foo in R1 but the server implements R2 of the /A:foo container? What if /A:foo is changed to obsolete in R2? How can the server stick to its original A.n contract it it changes any status to obsolete in A.n+i? > > > >>Only one revision of any module should ever be advertised. By >>advertising, >>you are saying that you will be bound by the contract given in that >>module, >>so saying you support multiple revisions would be a logic error. > > Yes, since the passed namespace doesn't qualify revision > YANG 1.1 is not going to advertise modules, just an opaque identifier to indicate the module set ID. > > > > Thanks, > Kent > Andy From nobody Thu Dec 4 15:00:50 2014 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 A050E1A8725 for ; Thu, 4 Dec 2014 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zGZgulKpx4JL for ; Thu, 4 Dec 2014 15:00:45 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ECA1A871D for ; Thu, 4 Dec 2014 15:00:45 -0800 (PST) Received: from CO2PR05CA030.namprd05.prod.outlook.com (10.141.241.158) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 4 Dec 2014 23:00:43 +0000 Received: from BN1BFFO11FD044.protection.gbl (2a01:111:f400:7c10::1:184) by CO2PR05CA030.outlook.office365.com (2a01:111:e400:1429::30) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Thu, 4 Dec 2014 23:00:42 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1BFFO11FD044.mail.protection.outlook.com (10.58.144.107) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Thu, 4 Dec 2014 23:00:41 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 4 Dec 2014 15:00:34 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB4N0HR06334; Thu, 4 Dec 2014 15:00:30 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB4N030V030100; Thu, 4 Dec 2014 18:00:04 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412042300.sB4N030V030100@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Thu, 4 Dec 2014 18:00:03 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(51704005)(68736005)(48376002)(54356999)(106466001)(62966003)(81156004)(105596002)(50986999)(110136001)(76506005)(103666002)(20776003)(53416004)(77096005)(31966008)(107046002)(1941001)(69596002)(84676001)(77156002)(86362001)(64706001)(230783001)(46102003)(21056001)(4396001)(50466002)(92566001)(87936001)(97736003)(47776003)(6806004)(99396003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Forefront-PRVS: 041517DFAB Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2LavKEHmtvyyLYD98Acufhe8s1U Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Thu, 04 Dec 2014 23:00:47 -0000 Kent Watsen writes: >>If module A support a top-level container, and module B augments >>that top-level container, advertising B without advertising A >>is a logic error. > >Why an error? It seems more like a MAY than a MUST to me... module A { container a { ... } } module B { augment /a:a { container b { ... } } } If you don't support the /a:a container, how can you augment it with /a:a/b:b? To implement any sort of meaningful augmentation, you'd have to implement the contract the base node appears in. Otherwise, you'd be implementing /a:a without implementing any sort of content under it. Thanks, Phil From nobody Thu Dec 4 16:10:51 2014 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 027981A87ED for ; Thu, 4 Dec 2014 16:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fwJ6NLYLwdkQ for ; Thu, 4 Dec 2014 16:10:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::785]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2841A87F1 for ; Thu, 4 Dec 2014 16:10:26 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB364.namprd05.prod.outlook.com (10.141.51.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 5 Dec 2014 00:10:03 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) with mapi id 15.01.0026.003; Fri, 5 Dec 2014 00:10:03 +0000 From: Kent Watsen To: Phil Shafer Thread-Topic: [netmod] review of draft-bierman-netmod-yang-conformance-04 Thread-Index: AQHQA6H9AlQpYILMKEWxoFxOqEHAjZxnrBeAgABlW4CAFm79AIABNckAgAAIIQCAAGZ2gP//v74A Date: Fri, 5 Dec 2014 00:10:02 +0000 Message-ID: References: <201412042300.sB4N030V030100@idle.juniper.net> In-Reply-To: <201412042300.sB4N030V030100@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB364; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB364; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(51704005)(199003)(20776003)(101416001)(110136001)(36756003)(102836002)(64706001)(66066001)(87936001)(68736005)(2656002)(31966008)(46102003)(105586002)(4396001)(106116001)(106356001)(97736003)(99286002)(77156002)(62966003)(21056001)(107046002)(1941001)(92566001)(54356999)(86362001)(230783001)(83506001)(99396003)(50986999)(76176999)(122556002)(40100003)(120916001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB364; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8sUoo52AaA1QSlK1Yqrq7ihf-9g Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Fri, 05 Dec 2014 00:10:35 -0000 >>Why an error? It seems more like a MAY than a MUST to me... > >module A { > container a { ... } >} > >module B { > augment /a:a { > container b { ... } > } >} > >If you don't support the /a:a container, how can you augment it >with /a:a/b:b? To implement any sort of meaningful augmentation, >you'd have to implement the contract the base node appears in. >Otherwise, you'd be implementing /a:a without implementing any >sort of content under it. What if A contains more than one top-level container, but B only augments one of them? Does the server still have to implement all of A? Thanks, Kent From nobody Fri Dec 5 01:45:27 2014 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 14B4F1ACE18 for ; Fri, 5 Dec 2014 01:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS6f7II1DMDp for ; Fri, 5 Dec 2014 01:45:23 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6881ACE0E for ; Fri, 5 Dec 2014 01:45:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 505925407E6; Fri, 5 Dec 2014 10:45:19 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7xgTF53bHdz; Fri, 5 Dec 2014 10:45:15 +0100 (CET) Received: from localhost (unknown [195.113.220.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 4D751540030; Fri, 5 Dec 2014 10:45:15 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201412042108.sB4L8al6029461@idle.juniper.net> References: <201412042108.sB4L8al6029461@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 05 Dec 2014 10:45:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8IYaPE3w6RUfGoHMD4ZayKcLKrU Cc: netmod@ietf.org Subject: Re: [netmod] backward compatibility 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, 05 Dec 2014 09:45:25 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>Routing folks are now evaluating the routing module, and I expect that qu= ite a few thing >>s in it may need revamping. The module was already close to becoming an R= FC but, in fact >>, we would be stuck if that had happened. Some of the changes that are be= ing proposed wo >>uld become impossible due to the Sec. 11 rules. What would you suggest in= that case - st >>art a new routing-plus module? > > Has anyone implemnted the routing module? If not, there's not > cost. But many people have implemented YANG engines, so changing Exactly, but sec. 10 in RFC=C2=A06020 still applies, hence the update possibilities are severely limited. That's why I think these restrictions are counter-productive, and backward compatibility of module updates should be left to a qualified judgement of a data modeller or IETF WG. > the way it works is not without cost. This thread is not about YANG language upgrade, which is a separate problem. Lada > > Thanks, > Phil --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 5 01:52:28 2014 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 4DD5C1ACE18 for ; Fri, 5 Dec 2014 01:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXBDokQSS86W for ; Fri, 5 Dec 2014 01:52:24 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9901A897B for ; Fri, 5 Dec 2014 01:52:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 09C2D5407E6; Fri, 5 Dec 2014 10:52:23 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGTWeSmWs2rt; Fri, 5 Dec 2014 10:52:19 +0100 (CET) Received: from localhost (unknown [195.113.220.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3125E540030; Fri, 5 Dec 2014 10:52:18 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Phil Shafer In-Reply-To: References: <201412041557.sB4FvIso027338@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 05 Dec 2014 10:52:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Te6i8XvdvLMvKR_fOAOcfS40p28 Cc: "netmod@ietf.org" Subject: Re: [netmod] backward compatibility 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, 05 Dec 2014 09:52:26 -0000 Andy Bierman writes: > On Thu, Dec 4, 2014 at 7:57 AM, Phil Shafer wrote: >> Ladislav Lhotka writes: >>>And even then, I believe that at this stage RFCs containing YANG modules >>>should still be tagged with clearly visible road work signs - everybody >>>has to understand that incompatible changes may sometimes be necessary. >> >> People are using NETCONF and YANG to perform real work. Telling >> them that this technology isn't stable enough for real work use >> will result in them choosing other technologies. >> >> In fact, I would strongly (very strongly) suggest the opposite. >> Any change that we are considering that contributes even vaguely to >> the perception that this technology isn't stable enough for real >> work should be avoided. Clarifications and coverage of odd corner >> cases are acceptable. Real changes are not. >> > > This does seem to be the intent of the charter, and the intent of > calling I am not sure about the intent, but none of the proposed changes violate the charter's wording. Above that, we also agreed that semantics of existing statements must not change. > it YANG 1.1 instead of 1.5 or 2.0. I agree that stability is more important > than new features, especially since customers are not really complaining > about YANG 1.0 and not asking for YANG 1.1. > > However, no matter what is in the next version of YANG, all relevant tools > need to be updated in order to use the first YANG 1.1 module. > Tools that are not updated (not just clients) cannot use the new module > or the feature it represents. Agreed. > > IMO this is going to be much more important to vendors than some > clarifications to YANG. Engineers will be asked to justify the use of YANG 1.1, > since tool X will not implement it in time for the software release. > So I support some new features like actions, but nothing that changes > any data types (like optional keys). Well, then almost nothing would be left. For example, the new XPath functions won't be possible. Lada > > >> Thanks, >> Phil >> > > 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 Fri Dec 5 07:06:20 2014 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 0E8031ACE98 for ; Fri, 5 Dec 2014 07:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t-YDp2pkUKj for ; Fri, 5 Dec 2014 07:06:16 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031351ACE97 for ; Fri, 5 Dec 2014 07:06:15 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so813961lab.15 for ; Fri, 05 Dec 2014 07:06:14 -0800 (PST) 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=pnjpBDWt8o/pHwy9L/3n8GZiY1AZugLGMkHChLFEcls=; b=gOGNfOThGNd9arPT1eg8plJuAF5J2nv0FHh8n9Eg3ToELtSnRKAJhpMJpThRvYMEI/ HrZDBYhuNc+2i5scFdoRbocqTlozVczC/YBjSd2LEbkyyozYcIdDflcuE0FlmTgLeGTy BCnSQ8OLdCsGkgxjoFwfKMh+oFJfhtTnLbXTi7qBlA9LVvVQoH6h036nvCQhxv2oZF+p k+8o69Bt3iwiHXJfMff8bhxOMj/4r3+Lg1kny8UCIf4hvyO3f6jir9Ywe2o1ilvjlU9y VNPhx20qjK2HyoFtJhiIO4Iq4EDwGGhLR/HCJoz09qE254veTCZnFDikIwu1N97Lz/l7 3AnQ== X-Gm-Message-State: ALoCoQk+e4DlwNBQUNfil+S3oda49sC4Yqr7zed+V33uOn2FDQo4fbSWnAwfc4MjCL9uyvkWnSyt MIME-Version: 1.0 X-Received: by 10.152.121.1 with SMTP id lg1mr3347646lab.28.1417791974475; Fri, 05 Dec 2014 07:06:14 -0800 (PST) Received: by 10.112.157.233 with HTTP; Fri, 5 Dec 2014 07:06:14 -0800 (PST) In-Reply-To: References: <201412042108.sB4L8al6029461@idle.juniper.net> Date: Fri, 5 Dec 2014 07:06:14 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/piY4WXHdOeNUhjacbVZ4aAOTCSA Cc: "netmod@ietf.org" Subject: Re: [netmod] backward compatibility 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, 05 Dec 2014 15:06:18 -0000 On Fri, Dec 5, 2014 at 1:45 AM, Ladislav Lhotka wrote: > Phil Shafer writes: > >> Ladislav Lhotka writes: >>>Routing folks are now evaluating the routing module, and I expect that quite a few thing >>>s in it may need revamping. The module was already close to becoming an RFC but, in fact >>>, we would be stuck if that had happened. Some of the changes that are being proposed wo >>>uld become impossible due to the Sec. 11 rules. What would you suggest in that case - st >>>art a new routing-plus module? >> >> Has anyone implemnted the routing module? If not, there's not >> cost. But many people have implemented YANG engines, so changing > > Exactly, but sec. 10 in RFC 6020 still applies, hence the update > possibilities are severely limited. That's why I think these > restrictions are counter-productive, and backward compatibility of > module updates should be left to a qualified judgement of a data > modeller or IETF WG. > Not quite.... The routing modules are not published in RFCs so section 10 does not apply to them. In IETF terms, a work-in-progress can be changed at any time and in any way. We are only concerned with RFC to RFC changes. >> the way it works is not without cost. > > This thread is not about YANG language upgrade, which is a separate > problem. The YANG update rules have a huge impact on the cost of data model maintenance. Most vendors will want to make engineering tradeoffs that minimize code changes, even if that makes the YANG module less elegant. > > Lada > >> >> Thanks, >> Phil > Andy From nobody Fri Dec 5 07:47:12 2014 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 5FB751ACEC9 for ; Fri, 5 Dec 2014 07:47:11 -0800 (PST) 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 PFjYTAQ4S-ja for ; Fri, 5 Dec 2014 07:47:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD881A1B44 for ; Fri, 5 Dec 2014 07:47:09 -0800 (PST) Received: from [172.20.6.143] (unknown [172.20.6.143]) by mail.nic.cz (Postfix) with ESMTPSA id E1085140C02; Fri, 5 Dec 2014 16:47:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1417794427; bh=NH9yJphDTBrV4ryoxNxvnxEsWpbLHcOpkGyF1dJmUVM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ImzzhC4jdW7fdQWbMV19ccDMx7wZL5vQCIkX13TrAxeWJLKC1+n7NdZDhRglehUmM 5LVFrWjhvVfhd2QytVR5GBizwA9Zsb+KWKmxULvmrjgcofyeKa4yY1V87fcLSru65N ePPmBHcYSNHAtEL3QdTeC2G1c06/1flSJQm3lNQo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 5 Dec 2014 16:47:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412042108.sB4L8al6029461@idle.juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m0NhOaDz7UE8lZZLOAhOCvdEoMg Cc: "netmod@ietf.org" Subject: Re: [netmod] backward compatibility 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, 05 Dec 2014 15:47:11 -0000 > On 05 Dec 2014, at 16:06, Andy Bierman wrote: >=20 > On Fri, Dec 5, 2014 at 1:45 AM, Ladislav Lhotka wrote: >> Phil Shafer writes: >>=20 >>> Ladislav Lhotka writes: >>>> Routing folks are now evaluating the routing module, and I expect = that quite a few thing >>>> s in it may need revamping. The module was already close to = becoming an RFC but, in fact >>>> , we would be stuck if that had happened. Some of the changes that = are being proposed wo >>>> uld become impossible due to the Sec. 11 rules. What would you = suggest in that case - st >>>> art a new routing-plus module? >>>=20 >>> Has anyone implemnted the routing module? If not, there's not >>> cost. But many people have implemented YANG engines, so changing >>=20 >> Exactly, but sec. 10 in RFC 6020 still applies, hence the update >> possibilities are severely limited. That's why I think these >> restrictions are counter-productive, and backward compatibility of >> module updates should be left to a qualified judgement of a data >> modeller or IETF WG. >>=20 >=20 >=20 > Not quite.... > The routing modules are not published in RFCs so section 10 does not > apply to them. > In IETF terms, a work-in-progress can be changed at any time and in = any way. > We are only concerned with RFC to RFC changes. But that=E2=80=99s what I wrote: The I-D was close to becoming an RFC, = and if it had happened it would be impossible to realize some of the = recent suggestions such as remove route-filters. I would be *extremely* = reluctant to tag them as obsolete and then augment a new implementation = of route-filters from another module. If readability is supposed to have = the highest priority, why should readers of standard modules be harassed = by something like this? Yes, it hasn=E2=80=99t happened this time but I think it is bound to = happen with the routing module (if it ever gets published) or another. >=20 >>> the way it works is not without cost. >>=20 >> This thread is not about YANG language upgrade, which is a separate >> problem. >=20 > The YANG update rules have a huge impact on the cost of data model = maintenance. > Most vendors will want to make engineering tradeoffs that minimize = code changes, > even if that makes the YANG module less elegant. >=20 Less elegant might be acceptable but incomprehensible is not. I = understand it is your priority and why it is so but I think in the long = run it may lead to a terrible mess of bloated modules that nobody will = understand. Lada >=20 >>=20 >> Lada >>=20 >>>=20 >>> Thanks, >>> Phil >>=20 >=20 >=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 5 07:50:54 2014 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 838F71ACED2 for ; Fri, 5 Dec 2014 07:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CJuUfm11Po_7 for ; Fri, 5 Dec 2014 07:50:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EAC1ACEC0 for ; Fri, 5 Dec 2014 07:50:44 -0800 (PST) Received: from CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) by CO1PR05MB506.namprd05.prod.outlook.com (10.141.71.142) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 5 Dec 2014 15:50:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 5 Dec 2014 15:50:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.105]) with mapi id 15.01.0026.003; Fri, 5 Dec 2014 15:50:19 +0000 From: Kent Watsen To: Phil Shafer Thread-Topic: [netmod] review of draft-bierman-netmod-yang-conformance-04 Thread-Index: AQHQA6H9AlQpYILMKEWxoFxOqEHAjZxnrBeAgABlW4CAFm79AIABNckAgAAIIQCAAGZ2gP//v74AgAEGsAA= Date: Fri, 5 Dec 2014 15:50:19 +0000 Message-ID: References: <201412042300.sB4N030V030100@idle.juniper.net> 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 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(4396001)(31966008)(107046002)(2656002)(83506001)(1941001)(76176999)(105586002)(106116001)(101416001)(54356999)(97736003)(50986999)(46102003)(230783001)(99286002)(64706001)(20776003)(66066001)(110136001)(62966003)(450100001)(122556002)(21056001)(87936001)(106356001)(86362001)(120916001)(99396003)(92566001)(36756003)(40100003)(102836002)(68736005)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB363; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB506; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ch7pEJvww6h7kUBai4UoZqkkcDc Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Fri, 05 Dec 2014 15:50:50 -0000 >What if A contains more than one top-level container, but B only augments >one of them? Does the server still have to implement all of A? Never mind, I see it now. Yes, the server needs to implement all of A. Kent From nobody Fri Dec 5 08:06:58 2014 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 149821ACE1D for ; Fri, 5 Dec 2014 08:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWhG-EPMxuhz for ; Fri, 5 Dec 2014 08:06:55 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C891A1B66 for ; Fri, 5 Dec 2014 08:06:55 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so801414lbi.1 for ; Fri, 05 Dec 2014 08:06:53 -0800 (PST) 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=u209UqWqmYm2bBaeDU9JH4ok+PSqfNxusPLlR4R+YEs=; b=H6I4AozAN4thpnv6MpiC4xPnI7ZsRgSAnSlZ9mO5KkE1XkaSREee23Xyl+OxpEASiq mePXvvgzg2+vU5F84oPgcsT5tM1N+IldgIDM4zmvxJFhW2F40y7LInD+fLXLQE12bLNS Dxqw3KLPlYhB5MDm11ihCfnFfx7BrIlJLdQ0FblPzHo0oTARhARQvqDTql6vStooxlf2 OXe3NRYdRDzUTGwKV8jMkM76Hdd5JYqz2CR0fPo7f+WSUcJqkV1jBhE6W4iH2Twm/64E MJVT4G3SaXS2oxWvG6Fh7wmsxo0juS4a18bQl6ggY5FZ+fTbTwtz9akFwEB3pd3LDAQU R31Q== X-Gm-Message-State: ALoCoQk6RTCauCKsRQ4udsgmTXivijgxsB3LiBRSuOP5YYVjMjxD4+kf506NlGwLWzh0AeNq4Tx9 MIME-Version: 1.0 X-Received: by 10.112.166.74 with SMTP id ze10mr3624849lbb.68.1417795613384; Fri, 05 Dec 2014 08:06:53 -0800 (PST) Received: by 10.112.157.233 with HTTP; Fri, 5 Dec 2014 08:06:53 -0800 (PST) In-Reply-To: References: <201412042300.sB4N030V030100@idle.juniper.net> Date: Fri, 5 Dec 2014 08:06:53 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XWW8iCCY7D9vQ_e_fMY8Vto3H18 Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Fri, 05 Dec 2014 16:06:57 -0000 On Fri, Dec 5, 2014 at 7:50 AM, Kent Watsen wrote: > > >>What if A contains more than one top-level container, but B only augments >>one of them? Does the server still have to implement all of A? > > Never mind, I see it now. Yes, the server needs to implement all of A. > So what happens when module X augments rev. 1 of /A:foo, module Y augments rev. 2 of /A:foo, and the server advertises support for module A, rev. 3? What happens when module A is using typedefs from rev 3 in the /A:foo subtree, and modules X and Y are using the rev 1 and rev 2 versions of the typedefs? IMO the possible ways that multiple revisions can mix with import-by-revision is probably unmanageable. There are too many statements that can reference other nodes, so mixing revisions of macro-data will occur. > Kent > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 5 13:08:15 2014 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 4D6A01A1AE2 for ; Fri, 5 Dec 2014 13:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RtaQVe6agZD5 for ; Fri, 5 Dec 2014 13:08:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91561A1AA6 for ; Fri, 5 Dec 2014 13:08:06 -0800 (PST) Received: from BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) by BN1PR05MB294.namprd05.prod.outlook.com (10.141.64.15) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 5 Dec 2014 21:07:44 +0000 Received: from BL2PR05CA0023.namprd05.prod.outlook.com (10.255.226.23) by BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 5 Dec 2014 21:07:43 +0000 Received: from BY2FFO11FD055.protection.gbl (2a01:111:f400:7c0c::169) by BL2PR05CA0023.outlook.office365.com (2a01:111:e400:c04::23) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Fri, 5 Dec 2014 21:07:43 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD055.mail.protection.outlook.com (10.1.15.192) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Fri, 5 Dec 2014 21:07:43 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 5 Dec 2014 13:07:42 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB5L7eR85818; Fri, 5 Dec 2014 13:07:40 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB5L7Q8s036346; Fri, 5 Dec 2014 16:07:26 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412052107.sB5L7Q8s036346@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Fri, 5 Dec 2014 16:07:26 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(50986999)(46102003)(106466001)(4396001)(77156002)(62966003)(230783001)(54356999)(64706001)(76506005)(107046002)(77096005)(47776003)(68736005)(105596002)(20776003)(81156004)(86362001)(48376002)(110136001)(31966008)(92566001)(1941001)(87936001)(50466002)(84676001)(21056001)(99396003)(120916001)(103666002)(97736003)(69596002)(53416004)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB439; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601002); SRVR:BN1PR05MB439; X-Forefront-PRVS: 04163EF38A Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB294; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VVgD4lgWEMErMp9zD01EQoL5Hjk Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Fri, 05 Dec 2014 21:08:11 -0000 Kent Watsen writes: >What if A contains more than one top-level container, but B only augments >one of them? Does the server still have to implement all of A? Implementing half a module is equivalent to following half a contract. The client wouldn't be able to know what is and isn't there. Thanks, Phil From nobody Sun Dec 7 10:30:53 2014 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 D6CF51A8845 for ; Sun, 7 Dec 2014 10:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5SO7CU0ODtm for ; Sun, 7 Dec 2014 10:30:46 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A536A1A8848 for ; Sun, 7 Dec 2014 10:30:45 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so2817581lbd.34 for ; Sun, 07 Dec 2014 10:30:44 -0800 (PST) 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=UZSX24vB5zvBT4QjZYNlwSY35HdVwmy+dE5qu+ESmpA=; b=TrMia2q6zUtoF7FQyefi8d6E3e7dIREi2mVXJyeFWiBJlcNC1UdGOn7wcDervMN4NC 6KlxCb70TN4t7X+GJNAgX7AmtkrBVLMC/p7YNWv2JEuwEVRYQWxHf42or95CxoqTzbb3 OjWiuACOTxTm24u19enRSi+PlbSdJ/IA/G4exELqQdIf/Wo35sR7vIRy8lmFITRhF6hP zAH3/6nvgYgCS/RVwKwPbUyzbXV+61qmXgP80YWSVYzOvePCYA/SgHZFOvSlVCHtunUx w10A77BFGgz+7v/2BMLe99GhwlEoYxZgArSvyum4OtRrUihV4+pUCnqFnoiLCcDM7lh7 NvKg== X-Gm-Message-State: ALoCoQkLXP/UzT4wzuo6vhP1lPWjZRXVdjoVe7xFyhmI04nFM4z3+ojaUcR6v8msx7wl/cHM9179 MIME-Version: 1.0 X-Received: by 10.153.8.137 with SMTP id dk9mr13037484lad.82.1417977044202; Sun, 07 Dec 2014 10:30:44 -0800 (PST) Received: by 10.112.157.233 with HTTP; Sun, 7 Dec 2014 10:30:44 -0800 (PST) In-Reply-To: <201412052107.sB5L7Q8s036346@idle.juniper.net> References: <201412052107.sB5L7Q8s036346@idle.juniper.net> Date: Sun, 7 Dec 2014 10:30:44 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/soN7_H-7-lAXh-LmeAPX5MNw1-w Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Sun, 07 Dec 2014 18:30:48 -0000 On Fri, Dec 5, 2014 at 1:07 PM, Phil Shafer wrote: > Kent Watsen writes: >>What if A contains more than one top-level container, but B only augments >>one of them? Does the server still have to implement all of A? > > Implementing half a module is equivalent to following half > a contract. The client wouldn't be able to know what is > and isn't there. > You are suggesting that if B augments A, then the server MUST claim conformance to A if it claims conformance to B? If the augmented object requires YANG features, then the server MUST support the required features in order to claim conformance to B? The proposal in RESTCONF/ietf-yang-library is that if the "conformance" flag is false, then the server does not need to advertise deviations for that module. It would be possible for the server to claim conformance to B and not A. There are currently no rules in NETCONF/YANG requiring a server to claim conformance to any specific modules (except maybe ietf-netconf.yang for NETCONF 1.1). > Thanks, > Phil Andy From nobody Mon Dec 8 07:36:50 2014 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 EC3341A90BA for ; Mon, 8 Dec 2014 07:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 TeBbJ6wCmWz0 for ; Mon, 8 Dec 2014 07:36:48 -0800 (PST) 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 A98741A9034 for ; Mon, 8 Dec 2014 07:36:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 79C538E4; Mon, 8 Dec 2014 16:36:45 +0100 (CET) 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 Wq8JVnsJ69YE; Mon, 8 Dec 2014 16:36:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Dec 2014 16:36:44 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93FC620017; Mon, 8 Dec 2014 16:36:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z9HyvT_Ir-bO; Mon, 8 Dec 2014 16:36:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 715B620034; Mon, 8 Dec 2014 16:36:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 711DA2FEF46D; Mon, 8 Dec 2014 16:36:41 +0100 (CET) Date: Mon, 8 Dec 2014 16:36:41 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20141208153641.GA42088@elstar.local> Mail-Followup-To: Phil Shafer , Ladislav Lhotka , netmod@ietf.org References: <201412041611.sB4GBAv4027422@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201412041611.sB4GBAv4027422@idle.juniper.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LFS_IGNHy7lujVuysFkHSCbIxqo Cc: netmod@ietf.org Subject: Re: [netmod] Y59 action 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, 08 Dec 2014 15:36:49 -0000 On Thu, Dec 04, 2014 at 11:11:10AM -0500, Phil Shafer wrote: > I'm assuming the reader's reaction to this will be the same as mine: > it sounds crazy. I understand the need, but without talking about > type conversion and rounding, it will be confusing. And talking > about those topics will also be confusing. Is there a more complete > discussion of this topic we can refer to? > Floating point numbers are a great source of fun. If you really want to know the details: http://dx.doi.org/10.1145%2F1353445.1353446 While uint64, int64 and decimal64 types obviously have issues, there can also be subtle rounding errors with numbers that look less suspicious. This one seems to work 'well' with xsltproc... http://stackoverflow.com/questions/1845998/sum-diff-problem-bug-in-xslt-1-0 As someone said: You'll want to be really careful with equality tests with floats and doubles, in whatever language you are in. Perhaps we should add a reference to this one: http://www.xkcd.com/217/ /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 Dec 8 08:15:27 2014 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 999551A909A for ; Mon, 8 Dec 2014 08:15:25 -0800 (PST) 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 ZPD_ZBBkNjka for ; Mon, 8 Dec 2014 08:15:23 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6F51A1BD1 for ; Mon, 8 Dec 2014 08:15:23 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 10132140117; Mon, 8 Dec 2014 17:15:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418055322; bh=xj4B03vyN/RYg9GwV6OzDoNGUsfWEjvoqY2jZ4NvDMk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tSRYLeEnQEt1kWpaoQVfV6tf7rILgFHiNkGDdHkVYrncWVK/w37fMnavm6+VgNUt6 lzrhGc016X/cZf7QpZUofeRbAhaKmup6PPH57VfUp1wIqhZLEbZiONCe1ZCcJJh1Ie NyhFZ5B4WZLQ0Jyc9HcHjuEPuFf9EGOskyfkNZXE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20141208153641.GA42088@elstar.local> Date: Mon, 8 Dec 2014 17:15:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412041611.sB4GBAv4027422@idle.juniper.net> <20141208153641.GA42088@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9PR6thm5zZWzhsXuvuyTGW6hOtE Cc: netmod@ietf.org Subject: Re: [netmod] Y59 action 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, 08 Dec 2014 16:15:25 -0000 > On 08 Dec 2014, at 16:36, Juergen Schoenwaelder = wrote: >=20 > On Thu, Dec 04, 2014 at 11:11:10AM -0500, Phil Shafer wrote: >> I'm assuming the reader's reaction to this will be the same as mine: >> it sounds crazy. I understand the need, but without talking about >> type conversion and rounding, it will be confusing. And talking >> about those topics will also be confusing. Is there a more complete >> discussion of this topic we can refer to? >>=20 >=20 > Floating point numbers are a great source of fun. If you really want > to know the details: >=20 > http://dx.doi.org/10.1145%2F1353445.1353446 >=20 > While uint64, int64 and decimal64 types obviously have issues, there > can also be subtle rounding errors with numbers that look less > suspicious. This one seems to work 'well' with xsltproc... >=20 > = http://stackoverflow.com/questions/1845998/sum-diff-problem-bug-in-xslt-1-= 0 >=20 > As someone said: >=20 > You'll want to be really careful with equality tests with floats and > doubles, in whatever language you are in. Right, and for YANG it=E2=80=99s perhaps twice as important because a = part of a data tree may be suddenly deleted by the server based on the = evaluation of an XPath expression in a =E2=80=9Cwhen=E2=80=9D statement. >=20 > Perhaps we should add a reference to this one: >=20 > http://www.xkcd.com/217/ :-))) 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 Mon Dec 8 13:31:18 2014 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 1392F1ACF06 for ; Mon, 8 Dec 2014 13:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wkeh4syIkbiS for ; Mon, 8 Dec 2014 13:31:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::778]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519341ACF08 for ; Mon, 8 Dec 2014 13:31:15 -0800 (PST) Received: from CO2PR05CA045.namprd05.prod.outlook.com (10.141.241.173) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 8 Dec 2014 21:30:52 +0000 Received: from BN1AFFO11FD044.protection.gbl (2a01:111:f400:7c10::121) by CO2PR05CA045.outlook.office365.com (2a01:111:e400:1429::45) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Mon, 8 Dec 2014 21:30:51 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1AFFO11FD044.mail.protection.outlook.com (10.58.52.191) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Mon, 8 Dec 2014 21:30:50 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 8 Dec 2014 13:30:49 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sB8LUTR48416; Mon, 8 Dec 2014 13:30:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sB8LUFns056882; Mon, 8 Dec 2014 16:30:16 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412082130.sB8LUFns056882@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Mon, 8 Dec 2014 16:30:15 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(47776003)(103666002)(120916001)(77156002)(64706001)(54356999)(50986999)(31966008)(561944003)(19580395003)(6806004)(53416004)(86362001)(92566001)(62966003)(87936001)(20776003)(99396003)(77096005)(110136001)(230783001)(105596002)(107046002)(69596002)(84676001)(68736005)(48376002)(76506005)(21056001)(106466001)(4396001)(81156004)(97736003)(46102003)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB446; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601002); SRVR:DM2PR05MB446; X-Forefront-PRVS: 041963B986 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/POmYMfHSgGGol-vo9tzs6V1oOJ8 Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Mon, 08 Dec 2014 21:31:17 -0000 Andy Bierman writes: >You are suggesting that if B augments A, then the server MUST >claim conformance to A if it claims conformance to B? Yes. Augmenting something a server doesn't support makes little sense. >If the augmented object requires YANG features, then the server MUST >support the required features in order to claim conformance to B? No. Features are a per-server issue; modules aren't. >The proposal in RESTCONF/ietf-yang-library is that if the >"conformance" flag is false, then the server does not need to >advertise deviations for that module. I need to go read this draft, but it doesn't really sound clear. >It would be possible for >the server to claim conformance to B and not A. This would make no sense. >There are currently no rules in NETCONF/YANG requiring a server >to claim conformance to any specific modules (except maybe >ietf-netconf.yang for NETCONF 1.1). Seems like it's time to think this thru and add some. Thanks, Phil From nobody Mon Dec 8 14:10:35 2014 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 6D5D31A8954 for ; Mon, 8 Dec 2014 14:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfwAyOfFLg1r for ; Mon, 8 Dec 2014 14:10:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B99831A1B8D for ; Mon, 8 Dec 2014 14:10:29 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 3BE491280B40; Mon, 8 Dec 2014 23:10:28 +0100 (CET) Date: Mon, 08 Dec 2014 23:11:08 +0100 (CET) Message-Id: <20141208.231108.1663136960389170988.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201412041624.sB4GOEIJ027513@idle.juniper.net> References: <201412041624.sB4GOEIJ027513@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qvE4Dv3ZF2V6ERpIyHFdP6fjvTY Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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: Mon, 08 Dec 2014 22:10:32 -0000 Phil Shafer wrote: > Andy Bierman writes: > >I think this simple set of rules might work: > > 1) Import-by-revision and include-by-revision everywhere Import-by-revision everywhere quickly leads to problems if we also say that a server only advertises one revision of a module. > > 2) imported meta-data from A is from the specified revision > > when used in B > > 3) for conformance of real objects in A, the most recent advertised > > revision must be implemented > > We should clarify that advertising module A at revision X means > that all top-level containers, lists, leafs, leaf-lists and augments > are supported. And identities. But actually, you shouldn't have to support all identities. This use case is handled by the combination of the 'conformace' leaf in ietf-yang-library and the rpc 'get-allowed-identities' in ietf-yang-conformance. > Imported modules used by module A do not need to > be advertised. Advertising imported modules mean that you are > supporting all top-level containers, lists, leafs, leaf-lists and > augments from that module, without regard to their use in A. Yes, this was the original intent in YANG 1.0. But it leads to problems. Suppose module A imports (not by-revision) module B, and uses some typedef from module B. Which version of the typedef does the server implement? One way to solve this is to mandate import-by-revision. But that leads to problems if the server only can advertise one revision of a module it implements. Another solution is to use the 'conformance' leaf in ietf-yang-library. A third solution could be to make the update rules even more stricter, and make any change to typedefs and groupings illegal. > If module A support a top-level container, and module B augments > that top-level container, advertising B without advertising A > is a logic error. Yes, again this was always the intent, and I think it works. But, it is overly restrictive in one case. Suppose I want to augment /sys:system with tacacs config. Now, a server that wants to implement tacacs also is forced to implement /system/clock. It would be nice to be able to support np-containers w/o advertising the whole module. > > 4) even if multiple revisions of A are advertised (B->A.1, C->A.2) > > any protocol accessible data must use the most recent > > advertised revision > > Only one revision of any module should ever be advertised. By advertising, > you are saying that you will be bound by the contract given in that module, > so saying you support multiple revisions would be a logic error. Agreed. /martin From nobody Tue Dec 9 01:01:14 2014 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 D018E1A7014 for ; Tue, 9 Dec 2014 01:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAuudWtc7mb0 for ; Tue, 9 Dec 2014 01:01:12 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7033F1A7005 for ; Tue, 9 Dec 2014 01:01:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UHCKoUAt9Xxce0cNYESeZPeQF/osowGpZQMyTPWCXJJUz2YW0r0lDu5JXBA3Mi4y; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XyGfP-0000bd-6z for netmod@ietf.org; Tue, 09 Dec 2014 04:01:11 -0500 Received: from 99.101.141.238 by webmail.earthlink.net with HTTP; Tue, 9 Dec 2014 04:01:10 -0500 Message-ID: <30843043.1418115671188.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Tue, 9 Dec 2014 01:01:10 -0800 (GMT-08:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591fe4bd3e1b994035633edbfdfc56db7354350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/N7IfJhdyfBQe8UPtOXjrCmq1aNc Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 09:01:14 -0000 Hi - >From: Martin Bjorklund >Sent: Dec 8, 2014 2:11 PM >To: phil@juniper.net >Cc: netmod@ietf.org >Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-04 ... >> Only one revision of any module should ever be advertised. By advertising, >> you are saying that you will be bound by the contract given in that module, >> so saying you support multiple revisions would be a logic error. > >Agreed. If a system contains multiple line cards with different firmware revision levels (and thus potentially different versions of their respective configuration models) Netconf chokes? Doesn't seem at all robust (or realistic) to me. Randy From nobody Tue Dec 9 12:54:20 2014 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 A74521A00E6 for ; Tue, 9 Dec 2014 12:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HVUfmCX0GYcn for ; Tue, 9 Dec 2014 12:54:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC5F1A00CD for ; Tue, 9 Dec 2014 12:54:16 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 9 Dec 2014 20:53:52 +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.0031.000; Tue, 9 Dec 2014 20:53:52 +0000 From: Kent Watsen To: Martin Bjorklund , Phil Shafer Thread-Topic: [netmod] review of draft-bierman-netmod-yang-conformance-04 Thread-Index: AQHQA6H9AlQpYILMKEWxoFxOqEHAjZxnrBeAgABlW4CAFm79AIABNckAgAaqPwCAASjtAA== Date: Tue, 9 Dec 2014 20:53:52 +0000 Message-ID: References: <201412041624.sB4GOEIJ027513@idle.juniper.net> <20141208.231108.1663136960389170988.mbj@tail-f.com> In-Reply-To: <20141208.231108.1663136960389170988.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-forefront-prvs: 0420213CCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(189002)(24454002)(164054003)(199003)(51704005)(107046002)(122556002)(99396003)(106116001)(97736003)(92566001)(120916001)(102836002)(68736005)(106356001)(99286002)(40100003)(46102003)(105586002)(20776003)(64706001)(31966008)(4396001)(230783001)(77156002)(101416001)(83506001)(21056001)(87936001)(54356999)(19580395003)(50986999)(1941001)(66066001)(19580405001)(76176999)(62966003)(2656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB363; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <2B96A1E6C6740F469351207091F2A741@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kTDmir_cA8Ye1PzCgNsDBfyQBhk Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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, 09 Dec 2014 20:54:18 -0000 >Phil Shafer wrote: >> Andy Bierman writes: >> >I think this simple set of rules might work: >> > 1) Import-by-revision and include-by-revision everywhere > >Import-by-revision everywhere quickly leads to problems if we also say >that a server only advertises one revision of a module. Why is this? Can you provide an example? IIUC, a server only needs to advertise (via hello or yang-library) the top-level modules it implements, not any modules imported by those top-level modules, unless a container they declare is being augmented. For instance, a device supporting ietf-system does not need to also advertise support for ietf-yang-types, ietf-inet-types, ietf-netconf-acm, or iana-crypt-hash (assuming we file errata against RFC7317 to import these modules by revision). If the above it true, then it should also be possible for the server to advertise more than one module that imports different revisions of some underlying module. For instance, in the following example, it would be valid for the server to only advertise "b@2014-06-01" and "c@2014-07-01": module a { revision 2014-04-01; } module a { revision 2014-05-01; } module b { revision 2014-06-01; import a { // not imported for purpose of augmentation revision-date 2014-04-01; } } module c { revision 2014-07-01; import a { // not imported for purpose of augmentation revision-date 2014-05-01; } } Now assume a newer version of 'a' is released and the server wants to support it explicitly as a top-level module. For instance, in the following example, what can break if the server advertises "b@2014-06-01" and "c@2014-07-01" and "a@014-08-01"? module a { revision 2014-04-01; } module a { revision 2014-05-01; } module a { revision 2014-08-01; } module b { revision 2014-06-01; import a { // not imported for purpose of augmentation revision-date 2014-04-01; } } module c { revision 2014-07-01; import a { // not imported for purpose of augmentation revision-date 2014-05-01; } } Playing devil's advocate, let's assume the next version of module 'c' decides to augment a container provided by a@2014-05-01 (see below). I'm assuming that this would not be allowed (right?), that the next version of 'c' would have to import the current version of 'a' (2014-08-01) and thus the server advertising a@2014-08-01 and c@2014-09-01 is OK. module c { revision 2014-09-01; import a { // not imported for purpose of augmentation revision-date 2014-08-01; } } Thanks, Kent From nobody Tue Dec 9 13:09:41 2014 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 1490D1A89A3 for ; Tue, 9 Dec 2014 13:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKBOQW8Sx495 for ; Tue, 9 Dec 2014 13:09:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 637DB1A896A for ; Tue, 9 Dec 2014 13:09:36 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 95FF81280098; Tue, 9 Dec 2014 22:09:34 +0100 (CET) Date: Tue, 09 Dec 2014 22:10:24 +0100 (CET) Message-Id: <20141209.221024.1089619852952038552.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <201412041624.sB4GOEIJ027513@idle.juniper.net> <20141208.231108.1663136960389170988.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LnMw9So2ySLbtnczT8_dwDmVbDI Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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, 09 Dec 2014 21:09:38 -0000 Kent Watsen wrote: > > > >Phil Shafer wrote: > >> Andy Bierman writes: > >> >I think this simple set of rules might work: > >> > 1) Import-by-revision and include-by-revision everywhere > > > >Import-by-revision everywhere quickly leads to problems if we also say > >that a server only advertises one revision of a module. > > > Why is this? Can you provide an example? module a { ... revision 2014-04-01; container x; } module a { ... revision 2014-05-01; container x; container y; } module b { ... import a { prefix a; revision-date 2014-04-01; } augment /a:x { ... } } module c { ... import a { prefix a; revision-date 2014-05-01; } augment /a:y { ... } } Now, my server wants to support both b and c. Which version of a should it implement? The only reasonable choice is 2014-05-01, but that means that for b, import-by revision really means import-by-min-revision. This may or may not work. /martin From nobody Tue Dec 9 14:00:24 2014 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 1306A1A00E2 for ; Tue, 9 Dec 2014 14:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 70PZKFc-uHGv for ; Tue, 9 Dec 2014 14:00:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74551A002B for ; Tue, 9 Dec 2014 14:00:20 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 9 Dec 2014 22:00:12 +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.0031.000; Tue, 9 Dec 2014 22:00:12 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [netmod] review of draft-bierman-netmod-yang-conformance-04 Thread-Index: AQHQA6H9AlQpYILMKEWxoFxOqEHAjZxnrBeAgABlW4CAFm79AIABNckAgAaqPwCAASjtAIAAWHAA//+6FYA= Date: Tue, 9 Dec 2014 22:00:10 +0000 Message-ID: References: <201412041624.sB4GOEIJ027513@idle.juniper.net> <20141208.231108.1663136960389170988.mbj@tail-f.com> <20141209.221024.1089619852952038552.mbj@tail-f.com> In-Reply-To: <20141209.221024.1089619852952038552.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB363; x-forefront-prvs: 0420213CCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(189002)(199003)(51704005)(107046002)(122556002)(99396003)(106116001)(97736003)(120916001)(110136001)(68736005)(106356001)(99286002)(40100003)(102836002)(46102003)(105586002)(92566001)(20776003)(64706001)(31966008)(4396001)(93886004)(230783001)(77156002)(101416001)(83506001)(21056001)(54356999)(87936001)(66066001)(50986999)(19580405001)(76176999)(62966003)(2656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB363; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <674830B9F44EA74B8EDD8E802D8E5E57@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y2r8j_HA26_HYzGlwHjD2CP8EVo Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bierman-netmod-yang-conformance-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, 09 Dec 2014 22:00:23 -0000 > module a { > ... > revision 2014-04-01; > container x; > } > > module a { > ... > revision 2014-05-01; > container x; > container y; > } > =20 > module b { > ... > import a { > prefix a; > revision-date 2014-04-01; > } > augment /a:x { > ... > } > } > > module c { > ... > import a { > prefix a; > revision-date 2014-05-01; > } > augment /a:y { > ... > } > } > >Now, my server wants to support both b and c. Which version of a >should it implement? The only reasonable choice is 2014-05-01, but >that means that for b, import-by revision really means >import-by-min-revision. This may or may not work. Yes, "import-by-min-revision" seems to resolve it, given the backwards compatibility rules defined in 6020 section 10. Also, since 'a' is having a container augmented, the server would have to explicitly advertise support for 'a' and, in this case, it would have to be a@2014-05-01. BTW, you're back the augmenting-a-container problem. My post was mostly trying to explore if there is anything else besides this. Is there? Kent From nobody Wed Dec 10 10:14:14 2014 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 439A91A1A0C for ; Wed, 10 Dec 2014 10:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6ygdCQMhG_9 for ; Wed, 10 Dec 2014 10:14:09 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011B11A6FF9 for ; Wed, 10 Dec 2014 10:14:07 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so2945685lab.15 for ; Wed, 10 Dec 2014 10:14:06 -0800 (PST) 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=SFVlsuxyaYDpdf9HJlb8AqiSsXwM4AodhW8Ev1fdZ4w=; b=EaIffLXz+5D5vXZdotoonwrd8t9Joc4vWwVLXQQ7PNoAme7cxlOBf3q2Lb3td9MqMt 7CkTFbMM9OTuGlM58aOsKcKCWmwZliMFGREsubx2RIUWSph1AgIkViTse3K604Vc5q33 LSnDDSvfSZmmBJePYwmyTUC5zPER3YE3Rnptt9qrEJLaUOCI7jPDABLrd138zfJ99/yN 6iEtUufiWGXEu0KXelra8bTqhFwsMpzIfcOQP0r1/LeGAR0eW7gFRTPplpFMmeiAOiqq tmYLrk3EmeKg28D+jlLWwW+2esWkry2iohzNc4VGJsg3OJmmKUTOEYOl607ftdsjWhJh kSHw== X-Gm-Message-State: ALoCoQnFL42VyXPQYi4M02QIjK8yjADl1xX5OvMAO8HLm+AKOq916K0FhIn0wXSJJPdp5yDmlqmp MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr319357lac.3.1418235246371; Wed, 10 Dec 2014 10:14:06 -0800 (PST) Received: by 10.112.157.233 with HTTP; Wed, 10 Dec 2014 10:14:06 -0800 (PST) Date: Wed, 10 Dec 2014 10:14:06 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dyGWwlrLJTC9X7BbB96OcdW6_bg Subject: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 10 Dec 2014 18:14:11 -0000 Hi, Sec 4 has changed the rules for module names: Names with namespace identifiers in the form shown in Figure 1 MUST be used for all top-level YANG data nodes, and also for all nodes whose parent node belongs to a different namespace. Otherwise, names with namespace identifiers MUST NOT be used. So it is a protocol error if a prefix is used twice in a row: /A:foo/A:bar --> causes a protocol error and MUST be rejected /A:foo/bar MUST be used instead IMO this is very fragile and does not follow the Postel Principle. In this example the server knows module 'A' and it is the correct module for node 'bar'. Yet it MUST reject the input according to the new rules. I prefer these rules: - The namespace for a node MUST be uses in top-level nodes and if the namespace is changing. - If no prefix is present, then the namespace associated with the parent node is used IMO it is too much work for the server to verify that a prefix is not used. Parsing a prefix is not a burden, since the code to parse the prefix must be already there. It is also more hassle on clients that are constructing URLs from multiple functions. They have to know which prefix MUST NOT be used. Andy From nobody Thu Dec 11 00:08:47 2014 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 7E0B31ACCFD for ; Thu, 11 Dec 2014 00:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8YmgGcsFQBZ for ; Thu, 11 Dec 2014 00:08:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DC3C81A90E1 for ; Thu, 11 Dec 2014 00:08:43 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9ED0C1CC0456; Thu, 11 Dec 2014 09:08:43 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 11 Dec 2014 09:08:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nnNNZQsROsSbqVjZM4Nz-toFkNA Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 11 Dec 2014 08:08:46 -0000 Andy Bierman writes: > Hi, > > Sec 4 has changed the rules for module names: > > Names with namespace identifiers in the form shown in Figure 1 MUST > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, names > with namespace identifiers MUST NOT be used. > > > So it is a protocol error if a prefix is used twice in a row: > > /A:foo/A:bar --> causes a protocol error and MUST be rejected > /A:foo/bar MUST be used instead > > IMO this is very fragile and does not follow the Postel Principle. I don't agree it is fragile. The rule for deciding about the presence or absence of a namespace ID is robust and dead simple: compare the namespaces of the current node and its parent - if they differ, add the namespace ID. > In this example the server knows module 'A' and it is the correct > module for node 'bar'. Yet it MUST reject the input according > to the new rules. > > I prefer these rules: > > - The namespace for a node MUST be uses in top-level > nodes and if the namespace is changing. > - If no prefix is present, then the namespace associated with > the parent node is used > This would be useful for senders that want to skip making the above decision a instead attach namespace IDs to all names. But this just shifts the burden to the receiving side. > IMO it is too much work for the server to verify that > a prefix is not used. Parsing a prefix is not a burden, I don't think it is difficult, see above. > since the code to parse the prefix must be already there. Parsing is one thing and comparing the namespace ID with the parent is another. With the existing rules, the namespace change is signalled in a much clearer way. > > It is also more hassle on clients that are constructing URLs > from multiple functions. They have to know which prefix > MUST NOT be used. I am not sure I understand the part about multiple functions but IMO constructing an URL could still be very simple if it is done from left to right: The namespace is on the first component and then whenever it changes. Lada > > > > 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 Dec 11 07:01:28 2014 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 9344C1ACEFF for ; Thu, 11 Dec 2014 07:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QweGcTL2bJiN for ; Thu, 11 Dec 2014 07:01:24 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D88E1A9028 for ; Thu, 11 Dec 2014 07:01:24 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so4208458lbd.6 for ; Thu, 11 Dec 2014 07:01:23 -0800 (PST) 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=ieUShtIIY0tJokEFUNj2ShOh4dtLP0RzqhcEnsJpGEU=; b=blprwM/p619uitYn1Svc5GGrrsjIPH1QOyabGvcxftpAmphdizqAf76WsGsy/pLGqt JopdaOOkUjd6qCJI0VcGwPNK/qtRW7PokIx68EFgeO7fgBRKQsoFQQLqRxRpttR6VGio 31I2Yp9oQxU0GJE44JKs8hjeqCDYliKRAJ+paDzx0aSuASioKXqsj4+8ttmIqAAPBAwA 1Udj2QH/abInMZio2AKPp2TvtFT8Nces2X6EexiG/xWf6wI1/8QOtQt72r1j9L2tVZu+ zss7Sevz//odQWQn8nFXsocKYnaCMQJoXrl3rwQz0ID32eLxnw/LY1ZDXiXQn6Z/Stra GCpQ== X-Gm-Message-State: ALoCoQnALJquhIsMvAVu7kFAvInrPsMvlt/5QDvrwR1YgywL6bi3YmuPYGjOeUcsTX/HISIKsbyW MIME-Version: 1.0 X-Received: by 10.112.101.100 with SMTP id ff4mr10233187lbb.94.1418310082928; Thu, 11 Dec 2014 07:01:22 -0800 (PST) Received: by 10.112.157.233 with HTTP; Thu, 11 Dec 2014 07:01:22 -0800 (PST) In-Reply-To: References: Date: Thu, 11 Dec 2014 07:01:22 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F5JUik11ZQ3pfwLO799bzu7EFfQ Cc: "netmod@ietf.org" Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 11 Dec 2014 15:01:26 -0000 On Thu, Dec 11, 2014 at 12:08 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> Hi, >> >> Sec 4 has changed the rules for module names: >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, names >> with namespace identifiers MUST NOT be used. >> >> >> So it is a protocol error if a prefix is used twice in a row: >> >> /A:foo/A:bar --> causes a protocol error and MUST be rejected >> /A:foo/bar MUST be used instead >> >> IMO this is very fragile and does not follow the Postel Principle. > > I don't agree it is fragile. The rule for deciding about the presence or > absence of a namespace ID is robust and dead simple: compare the > namespaces of the current node and its parent - if they differ, add the > namespace ID. > It is not robust at all. If the correct prefix is provided it should be accepted. That would be robust. Rejecting an identifier for using the correct prefix for a node is fragile, and quite counter-intuitive for anybody familiar with XPath. >> In this example the server knows module 'A' and it is the correct >> module for node 'bar'. Yet it MUST reject the input according >> to the new rules. >> >> I prefer these rules: >> >> - The namespace for a node MUST be uses in top-level >> nodes and if the namespace is changing. >> - If no prefix is present, then the namespace associated with >> the parent node is used >> > > This would be useful for senders that want to skip making the above > decision a instead attach namespace IDs to all names. But this just > shifts the burden to the receiving side. > The receiver already has to check for a prefix so I do not see any burden. It is an added burden to check the prefix and decide it is invalid just because it is redundant. >> IMO it is too much work for the server to verify that >> a prefix is not used. Parsing a prefix is not a burden, > > I don't think it is difficult, see above. > >> since the code to parse the prefix must be already there. > > Parsing is one thing and comparing the namespace ID with the parent is > another. With the existing rules, the namespace change is signalled in a > much clearer way. > That encoding is also accepted. Redundant information is not the same thing as incorrect information. The receiver must be liberal in what it accepts. Rejecting redundant but valid data does not follow the Postel Principle. >> >> It is also more hassle on clients that are constructing URLs >> from multiple functions. They have to know which prefix >> MUST NOT be used. > > I am not sure I understand the part about multiple functions but IMO > constructing an URL could still be very simple if it is done from left > to right: The namespace is on the first component and then whenever it > changes. > > Lada > >> >> >> >> Andy >> 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 Dec 11 07:24:51 2014 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 D405B1A1B6C for ; Thu, 11 Dec 2014 07:24:49 -0800 (PST) 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 Mc-v5sr_k5HQ for ; Thu, 11 Dec 2014 07:24:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416681A1AF4 for ; Thu, 11 Dec 2014 07:24:48 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id DF81013FE2E; Thu, 11 Dec 2014 16:24:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418311486; bh=LjZG3WMNrkBs02L4Mu7z4Q6S6Fw9RuFHEdO4L00TmaU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mycfTQ7a+hfHuUajyIRoWqKzGdo4FreCc338FWwihf4iuBeUuAMrj1BTxAtaWpRpr cBe5lcDXpWoqzRVrOGnvMOK1pBJAt1XHxztyy1Tj+qg1SN4+ceXAC10Rk8DxyNzui8 O46O3HjhMbfpNQINKMFY8vJCRQT4ph0rg5ZyaGXU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 11 Dec 2014 16:24:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F37594C-C5FE-4620-86F3-54E668783EB2@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7nsAwhQXomuGfKi-Xvq2sZIugWQ Cc: "netmod@ietf.org" Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 11 Dec 2014 15:24:50 -0000 > On 11 Dec 2014, at 16:01, Andy Bierman wrote: >=20 > On Thu, Dec 11, 2014 at 12:08 AM, Ladislav Lhotka = wrote: >> Andy Bierman writes: >>=20 >>> Hi, >>>=20 >>> Sec 4 has changed the rules for module names: >>>=20 >>> Names with namespace identifiers in the form shown in Figure 1 = MUST >>> be used for all top-level YANG data nodes, and also for all nodes >>> whose parent node belongs to a different namespace. Otherwise, = names >>> with namespace identifiers MUST NOT be used. >>>=20 >>>=20 >>> So it is a protocol error if a prefix is used twice in a row: >>>=20 >>> /A:foo/A:bar --> causes a protocol error and MUST be rejected >>> /A:foo/bar MUST be used instead >>>=20 >>> IMO this is very fragile and does not follow the Postel Principle. >>=20 >> I don't agree it is fragile. The rule for deciding about the presence = or >> absence of a namespace ID is robust and dead simple: compare the >> namespaces of the current node and its parent - if they differ, add = the >> namespace ID. >>=20 >=20 > It is not robust at all. > If the correct prefix is provided it should be accepted. > That would be robust. Rejecting an identifier for using > the correct prefix for a node is fragile, and quite counter-intuitive > for anybody familiar with XPath. >=20 >=20 >>> In this example the server knows module 'A' and it is the correct >>> module for node 'bar'. Yet it MUST reject the input according >>> to the new rules. >>>=20 >>> I prefer these rules: >>>=20 >>> - The namespace for a node MUST be uses in top-level >>> nodes and if the namespace is changing. >>> - If no prefix is present, then the namespace associated with >>> the parent node is used >>>=20 >>=20 >> This would be useful for senders that want to skip making the above >> decision a instead attach namespace IDs to all names. But this just >> shifts the burden to the receiving side. >>=20 >=20 >=20 > The receiver already has to check for a prefix so I do not see The receiver only needs to check whether the member name contains a = colon, and nothing else has to be done if it doesn=E2=80=99t - and this = is the most frequent case by far.=20 > any burden. It is an added burden to check the prefix > and decide it is invalid just because it is redundant. >=20 >>> IMO it is too much work for the server to verify that >>> a prefix is not used. Parsing a prefix is not a burden, >>=20 >> I don't think it is difficult, see above. >>=20 >>> since the code to parse the prefix must be already there. >>=20 >> Parsing is one thing and comparing the namespace ID with the parent = is >> another. With the existing rules, the namespace change is signalled = in a >> much clearer way. >>=20 >=20 > That encoding is also accepted. > Redundant information is not the same thing as incorrect information. > The receiver must be liberal in what it accepts. Rejecting redundant > but valid data does not follow the Postel Principle. Although I prefer to have namespace ID only where the namespace changes, = I could live with your proposal. I just want to hear others to express = their opinion. Lada >=20 >=20 >>>=20 >>> It is also more hassle on clients that are constructing URLs >>> from multiple functions. They have to know which prefix >>> MUST NOT be used. >>=20 >> I am not sure I understand the part about multiple functions but IMO >> constructing an URL could still be very simple if it is done from = left >> to right: The namespace is on the first component and then whenever = it >> changes. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >=20 >=20 > Andy >=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 11 07:41:14 2014 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 3CF9B1A212D for ; Thu, 11 Dec 2014 07:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkz7IA78aPg8 for ; Thu, 11 Dec 2014 07:41:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85E1A1AEA for ; Thu, 11 Dec 2014 07:41:10 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 041831280A90; Thu, 11 Dec 2014 16:41:09 +0100 (CET) Date: Thu, 11 Dec 2014 16:41:08 +0100 (CET) Message-Id: <20141211.164108.1819427320573439358.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <7F37594C-C5FE-4620-86F3-54E668783EB2@nic.cz> References: <7F37594C-C5FE-4620-86F3-54E668783EB2@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/n--R-LEZR7mp3i8qzwPFAtBOlp8 Cc: netmod@ietf.org Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 11 Dec 2014 15:41:12 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTEgRGVj IDIwMTQsIGF0IDE2OjAxLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gT24gVGh1LCBEZWMgMTEsIDIwMTQgYXQgMTI6MDggQU0sIExhZGlzbGF2IExo b3RrYSA8bGhvdGthQG5pYy5jej4NCj4gPiB3cm90ZToNCj4gPj4gQW5keSBCaWVybWFuIDxhbmR5 QHl1bWF3b3Jrcy5jb20+IHdyaXRlczoNCj4gPj4gDQo+ID4+PiBIaSwNCj4gPj4+IA0KPiA+Pj4g U2VjIDQgaGFzIGNoYW5nZWQgdGhlIHJ1bGVzIGZvciBtb2R1bGUgbmFtZXM6DQo+ID4+PiANCj4g Pj4+ICAgTmFtZXMgd2l0aCBuYW1lc3BhY2UgaWRlbnRpZmllcnMgaW4gdGhlIGZvcm0gc2hvd24g aW4gRmlndXJlIDEgTVVTVA0KPiA+Pj4gICBiZSB1c2VkIGZvciBhbGwgdG9wLWxldmVsIFlBTkcg ZGF0YSBub2RlcywgYW5kIGFsc28gZm9yIGFsbCBub2Rlcw0KPiA+Pj4gICB3aG9zZSBwYXJlbnQg bm9kZSBiZWxvbmdzIHRvIGEgZGlmZmVyZW50IG5hbWVzcGFjZS4gIE90aGVyd2lzZSwgbmFtZXMN Cj4gPj4+ICAgd2l0aCBuYW1lc3BhY2UgaWRlbnRpZmllcnMgTVVTVCBOT1QgYmUgdXNlZC4NCj4g Pj4+IA0KPiA+Pj4gDQo+ID4+PiBTbyBpdCBpcyBhIHByb3RvY29sIGVycm9yIGlmIGEgcHJlZml4 IGlzIHVzZWQgdHdpY2UgaW4gYSByb3c6DQo+ID4+PiANCj4gPj4+ICAgL0E6Zm9vL0E6YmFyICAg ICAtLT4gY2F1c2VzIGEgcHJvdG9jb2wgZXJyb3IgYW5kIE1VU1QgYmUgcmVqZWN0ZWQNCj4gPj4+ ICAgL0E6Zm9vL2JhciBNVVNUIGJlIHVzZWQgaW5zdGVhZA0KPiA+Pj4gDQo+ID4+PiBJTU8gdGhp cyBpcyB2ZXJ5IGZyYWdpbGUgYW5kIGRvZXMgbm90IGZvbGxvdyB0aGUgUG9zdGVsIFByaW5jaXBs ZS4NCj4gPj4gDQo+ID4+IEkgZG9uJ3QgYWdyZWUgaXQgaXMgZnJhZ2lsZS4gVGhlIHJ1bGUgZm9y IGRlY2lkaW5nIGFib3V0IHRoZSBwcmVzZW5jZQ0KPiA+PiBvcg0KPiA+PiBhYnNlbmNlIG9mIGEg bmFtZXNwYWNlIElEIGlzIHJvYnVzdCBhbmQgZGVhZCBzaW1wbGU6IGNvbXBhcmUgdGhlDQo+ID4+ IG5hbWVzcGFjZXMgb2YgdGhlIGN1cnJlbnQgbm9kZSBhbmQgaXRzIHBhcmVudCAtIGlmIHRoZXkg ZGlmZmVyLCBhZGQNCj4gPj4gdGhlDQo+ID4+IG5hbWVzcGFjZSBJRC4NCj4gPj4gDQo+ID4gDQo+ ID4gSXQgaXMgbm90IHJvYnVzdCBhdCBhbGwuDQo+ID4gSWYgdGhlIGNvcnJlY3QgcHJlZml4IGlz IHByb3ZpZGVkIGl0IHNob3VsZCBiZSBhY2NlcHRlZC4NCj4gPiBUaGF0IHdvdWxkIGJlIHJvYnVz dC4gIFJlamVjdGluZyBhbiBpZGVudGlmaWVyIGZvciB1c2luZw0KPiA+IHRoZSBjb3JyZWN0IHBy ZWZpeCBmb3IgYSBub2RlIGlzIGZyYWdpbGUsIGFuZCBxdWl0ZSBjb3VudGVyLWludHVpdGl2ZQ0K PiA+IGZvciBhbnlib2R5IGZhbWlsaWFyIHdpdGggWFBhdGguDQo+ID4gDQo+ID4gDQo+ID4+PiBJ biB0aGlzIGV4YW1wbGUgdGhlIHNlcnZlciBrbm93cyBtb2R1bGUgJ0EnIGFuZCBpdCBpcyB0aGUg Y29ycmVjdA0KPiA+Pj4gbW9kdWxlIGZvciBub2RlICdiYXInLiAgWWV0IGl0IE1VU1QgcmVqZWN0 IHRoZSBpbnB1dCBhY2NvcmRpbmcNCj4gPj4+IHRvIHRoZSBuZXcgcnVsZXMuDQo+ID4+PiANCj4g Pj4+IEkgcHJlZmVyIHRoZXNlIHJ1bGVzOg0KPiA+Pj4gDQo+ID4+PiAgIC0gVGhlIG5hbWVzcGFj ZSBmb3IgYSBub2RlIE1VU1QgYmUgdXNlcyBpbiB0b3AtbGV2ZWwNCj4gPj4+ICAgICBub2RlcyBh bmQgaWYgdGhlIG5hbWVzcGFjZSBpcyBjaGFuZ2luZy4NCj4gPj4+ICAgLSBJZiBubyBwcmVmaXgg aXMgcHJlc2VudCwgdGhlbiB0aGUgbmFtZXNwYWNlIGFzc29jaWF0ZWQgd2l0aA0KPiA+Pj4gICAg IHRoZSBwYXJlbnQgbm9kZSBpcyB1c2VkDQo+ID4+PiANCj4gPj4gDQo+ID4+IFRoaXMgd291bGQg YmUgdXNlZnVsIGZvciBzZW5kZXJzIHRoYXQgd2FudCB0byBza2lwIG1ha2luZyB0aGUgYWJvdmUN Cj4gPj4gZGVjaXNpb24gYSBpbnN0ZWFkIGF0dGFjaCBuYW1lc3BhY2UgSURzIHRvIGFsbCBuYW1l cy4gQnV0IHRoaXMganVzdA0KPiA+PiBzaGlmdHMgdGhlIGJ1cmRlbiB0byB0aGUgcmVjZWl2aW5n IHNpZGUuDQo+ID4+IA0KPiA+IA0KPiA+IA0KPiA+IFRoZSByZWNlaXZlciBhbHJlYWR5IGhhcyB0 byBjaGVjayBmb3IgYSBwcmVmaXggc28gSSBkbyBub3Qgc2VlDQo+IA0KPiBUaGUgcmVjZWl2ZXIg b25seSBuZWVkcyB0byBjaGVjayB3aGV0aGVyIHRoZSBtZW1iZXIgbmFtZSBjb250YWlucyBhDQo+ IGNvbG9uLCBhbmQgbm90aGluZyBlbHNlIGhhcyB0byBiZSBkb25lIGlmIGl0IGRvZXNu4oCZdCAt IGFuZCB0aGlzIGlzIHRoZQ0KPiBtb3N0IGZyZXF1ZW50IGNhc2UgYnkgZmFyLg0KPiANCj4gPiBh bnkgYnVyZGVuLiAgSXQgaXMgYW4gYWRkZWQgYnVyZGVuIHRvIGNoZWNrIHRoZSBwcmVmaXgNCj4g PiBhbmQgZGVjaWRlIGl0IGlzIGludmFsaWQganVzdCBiZWNhdXNlIGl0IGlzIHJlZHVuZGFudC4N Cj4gPiANCj4gPj4+IElNTyBpdCBpcyB0b28gbXVjaCB3b3JrIGZvciB0aGUgc2VydmVyIHRvIHZl cmlmeSB0aGF0DQo+ID4+PiBhIHByZWZpeCBpcyBub3QgdXNlZC4gUGFyc2luZyBhIHByZWZpeCBp cyBub3QgYSBidXJkZW4sDQo+ID4+IA0KPiA+PiBJIGRvbid0IHRoaW5rIGl0IGlzIGRpZmZpY3Vs dCwgc2VlIGFib3ZlLg0KPiA+PiANCj4gPj4+IHNpbmNlIHRoZSBjb2RlIHRvIHBhcnNlIHRoZSBw cmVmaXggbXVzdCBiZSBhbHJlYWR5IHRoZXJlLg0KPiA+PiANCj4gPj4gUGFyc2luZyBpcyBvbmUg dGhpbmcgYW5kIGNvbXBhcmluZyB0aGUgbmFtZXNwYWNlIElEIHdpdGggdGhlIHBhcmVudCBpcw0K PiA+PiBhbm90aGVyLiBXaXRoIHRoZSBleGlzdGluZyBydWxlcywgdGhlIG5hbWVzcGFjZSBjaGFu Z2UgaXMgc2lnbmFsbGVkIGluDQo+ID4+IGENCj4gPj4gbXVjaCBjbGVhcmVyIHdheS4NCg0KKzEg IEVhc2llciB0byByZWFkLCBhbmQgbGVzcyBlcnJvci1wcm9uZSwgYW5kIGNvbnNpc3RlbnQuDQoN Cj4gPiBUaGF0IGVuY29kaW5nIGlzIGFsc28gYWNjZXB0ZWQuDQo+ID4gUmVkdW5kYW50IGluZm9y bWF0aW9uIGlzIG5vdCB0aGUgc2FtZSB0aGluZyBhcyBpbmNvcnJlY3QgaW5mb3JtYXRpb24uDQo+ ID4gVGhlIHJlY2VpdmVyIG11c3QgYmUgbGliZXJhbCBpbiB3aGF0IGl0IGFjY2VwdHMuICBSZWpl Y3RpbmcgcmVkdW5kYW50DQo+ID4gYnV0IHZhbGlkIGRhdGEgZG9lcyBub3QgZm9sbG93IHRoZSBQ b3N0ZWwgUHJpbmNpcGxlLg0KPiANCj4gQWx0aG91Z2ggSSBwcmVmZXIgdG8gaGF2ZSBuYW1lc3Bh Y2UgSUQgb25seSB3aGVyZSB0aGUgbmFtZXNwYWNlDQo+IGNoYW5nZXMsIEkgY291bGQgbGl2ZSB3 aXRoIHlvdXIgcHJvcG9zYWwuIEkganVzdCB3YW50IHRvIGhlYXIgb3RoZXJzDQo+IHRvIGV4cHJl c3MgdGhlaXIgb3Bpbmlvbi4NCg0KSSBhbHNvIHByZWZlciB0byBoYXZlIHRoZSBwcmVmaXggb25s eSB3aGVuIHRoZSBuYW1lc3BhY2UgY2hhbmdlcy4NCg0KDQoNCi9tYXJ0aW4NCg== From nobody Thu Dec 11 07:50:53 2014 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 0696B1ACEFB for ; Thu, 11 Dec 2014 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvUxWdyIgAD2 for ; Thu, 11 Dec 2014 07:50:50 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DAA1ACDC8 for ; Thu, 11 Dec 2014 07:50:50 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so4456011lab.14 for ; Thu, 11 Dec 2014 07:50:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=852flFLne2ejRnb4NNk5JV4N3++6WtmGBocoGQiLaMw=; b=MLaof7++LStqIv/2YVvyxgWCDJNWKpcWYncUlDSZixpKFxRXE4z05qPxH+USN13bLf jEC9LGjM4rWpY328DK1KpM+l8MfOIqrvij/rVnO9crc+eFy1upevYa4x82qBlOggEhzu ULBdSOhAnaBAJpeCbmK0LurCP2uB+nT7rE41nbnkQj4QIjV+TTgOsq8R4FzzyMaSLbK0 HuH98xuT460Dlh7WUtF5dxO6yk6Mi9rOv3YwALWeAKXAYRITcW8whJ1PpEUD2dzr6pZT JhdmLFDrxGmLM/2O/IXgCUaV+GMumcl+dn+VtcmQpNRXtADhyLrFMeaMbTifG27Ntht0 XTqw== X-Gm-Message-State: ALoCoQkGVd6Bfr7hQluRdVw3FpFVujfDd9eMWMOLA1fnyfrYeIr9beRRRogKiRrtFLSgOWVVQkkS MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr5468517lac.3.1418313048309; Thu, 11 Dec 2014 07:50:48 -0800 (PST) Received: by 10.112.157.233 with HTTP; Thu, 11 Dec 2014 07:50:48 -0800 (PST) In-Reply-To: <20141211.164108.1819427320573439358.mbj@tail-f.com> References: <7F37594C-C5FE-4620-86F3-54E668783EB2@nic.cz> <20141211.164108.1819427320573439358.mbj@tail-f.com> Date: Thu, 11 Dec 2014 07:50:48 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j5WBfV8uC2l1GyTuysIjKK_X_Zw Cc: "netmod@ietf.org" Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 11 Dec 2014 15:50:52 -0000 On Thu, Dec 11, 2014 at 7:41 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> > On 11 Dec 2014, at 16:01, Andy Bierman wrote: >> > >> > On Thu, Dec 11, 2014 at 12:08 AM, Ladislav Lhotka >> > wrote: >> >> Andy Bierman writes: >> >> >> >>> Hi, >> >>> >> >>> Sec 4 has changed the rules for module names: >> >>> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUS= T >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >>> whose parent node belongs to a different namespace. Otherwise, na= mes >> >>> with namespace identifiers MUST NOT be used. >> >>> >> >>> >> >>> So it is a protocol error if a prefix is used twice in a row: >> >>> >> >>> /A:foo/A:bar --> causes a protocol error and MUST be rejected >> >>> /A:foo/bar MUST be used instead >> >>> >> >>> IMO this is very fragile and does not follow the Postel Principle. >> >> >> >> I don't agree it is fragile. The rule for deciding about the presence >> >> or >> >> absence of a namespace ID is robust and dead simple: compare the >> >> namespaces of the current node and its parent - if they differ, add >> >> the >> >> namespace ID. >> >> >> > >> > It is not robust at all. >> > If the correct prefix is provided it should be accepted. >> > That would be robust. Rejecting an identifier for using >> > the correct prefix for a node is fragile, and quite counter-intuitive >> > for anybody familiar with XPath. >> > >> > >> >>> In this example the server knows module 'A' and it is the correct >> >>> module for node 'bar'. Yet it MUST reject the input according >> >>> to the new rules. >> >>> >> >>> I prefer these rules: >> >>> >> >>> - The namespace for a node MUST be uses in top-level >> >>> nodes and if the namespace is changing. >> >>> - If no prefix is present, then the namespace associated with >> >>> the parent node is used >> >>> >> >> >> >> This would be useful for senders that want to skip making the above >> >> decision a instead attach namespace IDs to all names. But this just >> >> shifts the burden to the receiving side. >> >> >> > >> > >> > The receiver already has to check for a prefix so I do not see >> >> The receiver only needs to check whether the member name contains a >> colon, and nothing else has to be done if it doesn=E2=80=99t - and this = is the >> most frequent case by far. >> >> > any burden. It is an added burden to check the prefix >> > and decide it is invalid just because it is redundant. >> > >> >>> IMO it is too much work for the server to verify that >> >>> a prefix is not used. Parsing a prefix is not a burden, >> >> >> >> I don't think it is difficult, see above. >> >> >> >>> since the code to parse the prefix must be already there. >> >> >> >> Parsing is one thing and comparing the namespace ID with the parent i= s >> >> another. With the existing rules, the namespace change is signalled i= n >> >> a >> >> much clearer way. > > +1 Easier to read, and less error-prone, and consistent. > >> > That encoding is also accepted. >> > Redundant information is not the same thing as incorrect information. >> > The receiver must be liberal in what it accepts. Rejecting redundant >> > but valid data does not follow the Postel Principle. >> >> Although I prefer to have namespace ID only where the namespace >> changes, I could live with your proposal. I just want to hear others >> to express their opinion. > > I also prefer to have the prefix only when the namespace changes. > The receiver cannot just look for a ":" char since the prefix may in fact indicate a new module name. The receiver MUST be capable of parsing a module-name on any node. I can see SHOULD but not MUST for suppressing redundant prefixes. Otherwise the receiver MUST reject input it actually understands, and that is fragile. > > > /martin Andy From nobody Thu Dec 11 08:16:55 2014 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 6D0311ACF58; Thu, 11 Dec 2014 08:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, 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 YMGRDGxcaAb7; Thu, 11 Dec 2014 08:16:41 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 734661A1B91; Thu, 11 Dec 2014 08:16:41 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 25331C1BE; Thu, 11 Dec 2014 11:16:41 -0500 (EST) Date: Thu, 11 Dec 2014 11:16:41 -0500 From: Jeffrey Haas To: netmod@ietf.org, rtg-yang-coord@ietf.org Message-ID: <20141211161640.GC16279@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6G5_3A3lEN5VyQw24zc56-gOT-4 Subject: [netmod] Recursive modeling in 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, 11 Dec 2014 16:16:42 -0000 In http://tools.ietf.org/html/draft-wang-i2rs-rib-data-model-00, please consider "container tunnel-encap": container tunnel-encap { uses tunnel-encap; choice nexthop-second-encap-or-not{ case nexthop-second-encap{ container nexthop-second-encap{ description "the two encapsulating nexthop.One example is a Pseudowire - which is MPLS over some transport (MPLS or GRE for instance). Another example is VxLAN over IP. "; uses tunnel-encap; choice nexthop-third-encap-or-not{ case nexthop-third-encap { container nexthop-third-encap{ description "the three encapsulating nexthop.One exampl is Option A -L3VPN OVER MPLS tunnel and MPLS over TE tunnel"; uses tunnel-encap; [...] My question to the yang experts are whether there's been any discussion about generally recursive modeling? In the data model above, five levels are accommodated - thankfully using groupings. This precludes a sixth or later level of recursion. Please note that I'm not looking to specifically discuss the contents of this specific modeling, just its impact on the language. Such constructs may be common in certain types of routing modeling. -- Jeff From nobody Thu Dec 11 08:20:03 2014 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 41CD31A6FD9 for ; Thu, 11 Dec 2014 08:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjTx9pU0kEHA for ; Thu, 11 Dec 2014 08:19:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C9D1A1BAA for ; Thu, 11 Dec 2014 08:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3315; q=dns/txt; s=iport; t=1418314799; x=1419524399; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=JELybD6AKcuyryMOwEseACOBu8I+GVM0LAL9oBsKJfU=; b=KFfvcnP3f5Xvmt98RYTxbqEhCT0mYfB/E4iil3FlLBu97FXwUaBmPWKP WmRLH83IhWpixeMY1qCRrCSPSkHQZuVfNbZ834CO2rigTp5CeAwjIDWP+ 75j9j2FivZXXgqElKTWUNhbDbLRAik7sDZKcP6h/p281hwnakdQH4eGBj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAA3DiVStJV2R/2dsb2JhbABZgwZSWATFagyFbAKBHRYBAQEBAX2EDAEBAQQBAQE3NBcEAgEZBAEBCwIBEQkHJwsUCQgBAQQTCAGIIw3YMQEBAQEBAQEBAQEBAQEBAQEBAQEBARePQT6DEIETBY1/gz6GPTCCLY1KIoNsbgGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="104830675" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 11 Dec 2014 16:19:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBBGJwuQ015457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Dec 2014 16:19:58 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.205]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 10:19:58 -0600 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: New "-00": draft-voit-i2rs-pub-sub-requirements Thread-Index: AdAVViieql0DVYwjTDSQ2bF1EzwXyQAA7QaAAAD7Q9A= Date: Thu, 11 Dec 2014 16:19:57 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yjTiv8gi-2bqXl7JNmT0xXPEVk8 Subject: [netmod] New "-00": draft-voit-i2rs-pub-sub-requirements 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, 11 Dec 2014 16:20:01 -0000 FYI: We have published a new draft into I2RS which exposes some YANG Datast= ore subscription requirements. This should be seen as a document which is = coupled with=20 https://tools.ietf.org/html/draft-netmod-clemm-datastore-push-00 Thanks, Eric, Alex, & Alberto -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Thursday, December 11, 2014 10:22 AM To: i2rs@ietf.org Cc: Alexander Clemm (alex); Alberto Gonzalez Prieto (albertgo) Subject: [i2rs] New "-00": draft-voit-i2rs-pub-sub-requirements A number of I2RS WG documents ask for Pub/Sub capabilities. Other WG have = addressed or are looking for similar mechanisms. The document=20 http://tools.ietf.org/html/draft-voit-i2rs-pub-sub-requirements-00=20 assembles a view of requirements for a YANG Datastore from an I2RS perspect= ive, and makes comparisons with capabilities in standards in and beyond the= IETF.=20 This document is a good companion document for https://tools.ietf.org/html/draft-netmod-clemm-datastore-push-00=20 Thanks, Eric , Alex, & Alberto -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, December 11, 2014 10:03 AM To: Alberto Gonzalez Prieto (albertgo); Alberto Gonzalez Prieto (albertgo);= Alexander Clemm (alex); Eric Voit (evoit); Alexander Clemm (alex); Eric Vo= it (evoit) Subject: New Version Notification for draft-voit-i2rs-pub-sub-requirements-= 00.txt A new version of I-D, draft-voit-i2rs-pub-sub-requirements-00.txt has been successfully submitted by Eric Voit and posted to the IETF reposit= ory. Name: draft-voit-i2rs-pub-sub-requirements Revision: 00 Title: Requirements for Subscription to YANG Datastores Document date: 2014-12-10 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-voit-i2rs-pub-sub= -requirements-00.txt Status: https://datatracker.ietf.org/doc/draft-voit-i2rs-pub-sub-re= quirements/ Htmlized: http://tools.ietf.org/html/draft-voit-i2rs-pub-sub-requirem= ents-00 Abstract: This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Dec 11 08:27:03 2014 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 D4A191A1BAA; Thu, 11 Dec 2014 08:27:01 -0800 (PST) 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 HvIalwAh_qA2; Thu, 11 Dec 2014 08:27:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CA91A1AF8; Thu, 11 Dec 2014 08:27:00 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id D1FA414050B; Thu, 11 Dec 2014 17:26:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418315218; bh=06hbYHhB6ZOVYHrbLqvBO0gMu5Yh+0k+wFxHgFwBp04=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aB14xKCs9PLdxcHJGB8IiFs8zoUZO+yHOSxq1dW9Zz+oQt9GnfMeH01uv+n/CIpUH UxZ1ZjwzF+ELZTYv2edt+9ymGb5OT+szAhUGAfX93tO1bFK4o1i7FsXtuRQyNUwoTu qqjolW2JAGYcQv+Re97cHQjvpYN+jNVy5xg38k3M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20141211161640.GC16279@pfrc> Date: Thu, 11 Dec 2014 17:26:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141211161640.GC16279@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OTVETO1Bb73wUg59gbvR_j7W5Wk Cc: rtg-yang-coord@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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, 11 Dec 2014 16:27:02 -0000 Hi Jeff, > On 11 Dec 2014, at 17:16, Jeffrey Haas wrote: >=20 > In http://tools.ietf.org/html/draft-wang-i2rs-rib-data-model-00, = please > consider "container tunnel-encap": >=20 > container tunnel-encap { > uses tunnel-encap; > choice nexthop-second-encap-or-not{ > case nexthop-second-encap{ > container nexthop-second-encap{ > description > "the two encapsulating nexthop.One example is a = Pseudowire - which is MPLS over > some transport (MPLS or GRE for instance). Another = example is VxLAN > over IP. "; > uses tunnel-encap; > choice nexthop-third-encap-or-not{ > case nexthop-third-encap { > container nexthop-third-encap{ > description > "the three encapsulating nexthop.One exampl is = Option A -L3VPN OVER MPLS tunnel and MPLS over TE tunnel"; > uses tunnel-encap; > [...] >=20 > My question to the yang experts are whether there's been any = discussion > about generally recursive modeling? In the data model above, five = levels > are accommodated - thankfully using groupings. This precludes a sixth = or > later level of recursion. Yes, this has already been discussed several times. It was a deliberate = design decision to avoid recursive structures in YANG. They can be = emulated via leafrefs though. For example, recursive next-hop-list is = implemented this way in draft-ietf-netmod-routing-cfg-16. Lada=20 >=20 > Please note that I'm not looking to specifically discuss the contents = of > this specific modeling, just its impact on the language. Such = constructs > may be common in certain types of routing modeling. >=20 > -- Jeff >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 11 10:32:28 2014 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 A3A9A1A8775 for ; Thu, 11 Dec 2014 10:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfGijeSkijaI for ; Thu, 11 Dec 2014 10:32:22 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5003A1A1A64 for ; Thu, 11 Dec 2014 10:32:22 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so4699661lab.6 for ; Thu, 11 Dec 2014 10:32:20 -0800 (PST) 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=CjgxEcmkOyPy6n5f1iQuB+i99ARNllPr/JsVTf9HL1w=; b=WR9ttzUJ6M/TFe89xl/JQKS731Yyjhkpon0EEBS+yV4NfZalzOvXAIfqSJJ5KmDHbg h4cSZzDNYkmzlfv2K4XlRltuJ5hj0OOWKggioocVPQ40AA0sexKRbVAUKVV7xkHJXBfJ CIG65SSZPu7imnDwRU+CtDLoerc7C7QRJPdUe7O5oJ64epXGyhSZWLZICP7NBgCrTgID +cPJnOrcgMI+DcgjWlvw8HgWuxU/TVUKxqKOXUUIOPyZobAoadiZT5Dj85j+dvmng3pP c/dIkeUaZasoDgThIpeZE/Hux5vcuXyy5GSISi+jMLOQ2TH9Z9bGKTkr2oZNaLJvzwpf EcUQ== X-Gm-Message-State: ALoCoQlPCfBubLmkCOvDzMDxcPwbINZs+mJ6Oq/KraGAKD5f9yX1ogcbZHxVZtapBzriDsXbQArK MIME-Version: 1.0 X-Received: by 10.112.151.104 with SMTP id up8mr11130415lbb.21.1418322740810; Thu, 11 Dec 2014 10:32:20 -0800 (PST) Received: by 10.112.157.233 with HTTP; Thu, 11 Dec 2014 10:32:20 -0800 (PST) Date: Thu, 11 Dec 2014 10:32:20 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xBRVdFt9AglKaLbXpKGfLukUZlI Subject: [netmod] interim meeting start time 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, 11 Dec 2014 18:32:27 -0000 Hi, >From the IESG announcement.... The NETMOD WG will hold a series of bi-weekly virtual interim meetings. The meetings will take place on Wednesdays between 16:00 and 18:00 CEST. ..... The remaining dates for the meetings are: 2014-12-17 2015-01-07 2015-01-21 2015-02-04 2015-02-18 2015-03-04 2015-03-18 I do not think Europe is still on Central European Summer Time. This translates to a 6AM PT start time. Can we get a start time announced in UTC? For 7am PT? thanks, Andy From nobody Thu Dec 11 10:56:14 2014 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 0CA391A1A5B for ; Thu, 11 Dec 2014 10:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgEQfIK1ZG6o for ; Thu, 11 Dec 2014 10:56:11 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 96DAF1A88C7 for ; Thu, 11 Dec 2014 10:56:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KoYO+KvrIuY030hU/oS9UjXaNuLU1OcpKb97cx5r8rkzQaQIgXahcWqf+kiXhDEU; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Xz8u2-0000p9-Ay; Thu, 11 Dec 2014 13:55:54 -0500 Received: from 76.254.54.129 by webmail.earthlink.net with HTTP; Thu, 11 Dec 2014 13:55:53 -0500 Message-ID: <15998759.1418324154156.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Thu, 11 Dec 2014 10:55:53 -0800 (GMT-08:00) From: Randy Presuhn To: Andy Bierman , Martin Bjorklund Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f5245215bd7cb69d4cb5e53082f169e6c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xXS0uSKKu83qBQVCJ_CYmdsavUc Cc: "netmod@ietf.org" Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:56:13 -0000 Hi - >From: Andy Bierman >Sent: Dec 11, 2014 7:50 AM >To: Martin Bjorklund >Cc: "netmod@ietf.org" >Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 ... >I can see SHOULD but not MUST for suppressing redundant prefixes. >Otherwise the receiver MUST reject input it actually understands, >and that is fragile. I agree. RFC 2119 is instructive: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Randy From nobody Thu Dec 11 11:09:36 2014 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 35CDC1ACF80 for ; Thu, 11 Dec 2014 11:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 XFJF1MvdqIUV for ; Thu, 11 Dec 2014 11:09:18 -0800 (PST) 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 8943F1ACF7A for ; Thu, 11 Dec 2014 11:09:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 50DF8E61; Thu, 11 Dec 2014 20:09:13 +0100 (CET) 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 LjYTiTRermGh; Thu, 11 Dec 2014 20:08:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Dec 2014 20:09:12 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A1BD20017; Thu, 11 Dec 2014 20:09:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d7WOHWCuFoUQ; Thu, 11 Dec 2014 20:09:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F21520034; Thu, 11 Dec 2014 20:09:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ABF462FF3067; Thu, 11 Dec 2014 20:09:10 +0100 (CET) Date: Thu, 11 Dec 2014 20:09:10 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141211190910.GA51046@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: http://mailarchive.ietf.org/arch/msg/netmod/kjzgydRjbpGZZ524MF1Pb40Cjj8 Cc: "netmod@ietf.org" Subject: Re: [netmod] interim meeting start time 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, 11 Dec 2014 19:09:23 -0000 On Thu, Dec 11, 2014 at 10:32:20AM -0800, Andy Bierman wrote: > Hi, > > >From the IESG announcement.... > > The NETMOD WG will hold a series of bi-weekly virtual interim > meetings. The meetings will take place on Wednesdays between 16:00 and > 18:00 CEST. ..... > > The remaining dates for the meetings are: > > 2014-12-17 > 2015-01-07 > 2015-01-21 > 2015-02-04 > 2015-02-18 > 2015-03-04 > 2015-03-18 > > I do not think Europe is still on Central European Summer Time. > This translates to a 6AM PT start time. > Can we get a start time announced in UTC? > For 7am PT? > It is CET = UTC+1 like last week and I think that should be 7am in your time zone (PST = UTC-8). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Dec 12 00:34:01 2014 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 27AB81A6FDE for ; Fri, 12 Dec 2014 00:33:58 -0800 (PST) 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 DaglTHwoxNLL for ; Fri, 12 Dec 2014 00:33:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CB41A8732 for ; Fri, 12 Dec 2014 00:33:55 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id C404513FD9B; Fri, 12 Dec 2014 09:33:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418373233; bh=jCxCd8kV8TuX0SjohdEJ05CJhw1u9jpb1dmIZn3e2Vw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bNzTfpioOB0JqxosTFKbkraYSEcz3/WGdr8RyDTWC0nAkp/cXI65a0kNHasednMYs 7IkonKEqF3U4sNZanoGaplA7jdGxmc2XiRImTJjrvcU4cuKPk42pIPoIIWGGDR7LWw /zrL0VMz7n6ZQR5g9cHlN5AJaaS2mcl4p6MC60rE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <15998759.1418324154156.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Fri, 12 Dec 2014 09:33:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15998759.1418324154156.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> To: Randy Presuhn X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BYvbSmQU_kdKe68KESRsSsm5RaA Cc: "netmod@ietf.org" Subject: Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02 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, 12 Dec 2014 08:33:58 -0000 > On 11 Dec 2014, at 19:55, Randy Presuhn = wrote: >=20 > Hi - >=20 >> From: Andy Bierman >> Sent: Dec 11, 2014 7:50 AM >> To: Martin Bjorklund >> Cc: "netmod@ietf.org" >> Subject: Re: [netmod] namespace encoding in = draft-ietf-netmod-yang-json-02 > ... >> I can see SHOULD but not MUST for suppressing redundant prefixes. >> Otherwise the receiver MUST reject input it actually understands, >> and that is fragile. >=20 > I agree. RFC 2119 is instructive: > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for=20 > interoperability. I think SHOULD would be fine as it conveys the message that it is = desirable to suppress redundant prefixes where possible. Thanks, Lada >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 12 01:40:54 2014 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 485D31AC435; Fri, 12 Dec 2014 01:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 p7NYUKpsCh6C; Fri, 12 Dec 2014 01:40:49 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2121A19E5; Fri, 12 Dec 2014 01:40:47 -0800 (PST) Received: from pc6 (81.151.166.145) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 09:37:00 +0000 Message-ID: <01d401d015ef$281b7700$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas , , References: <20141211161640.GC16279@pfrc> Date: Fri, 12 Dec 2014 09:36:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.166.145] X-ClientProxiedBy: DB4PR05CA0032.eurprd05.prod.outlook.com (25.160.40.42) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:DBXPR07MB063; X-Forefront-PRVS: 04238CD941 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(51704005)(189002)(13464003)(84392001)(105586002)(14496001)(99396003)(50226001)(62236002)(1556002)(64706001)(107046002)(4396001)(230783001)(20776003)(87976001)(106356001)(19580405001)(19580395003)(66066001)(120916001)(107886001)(47776003)(97736003)(101416001)(23756003)(44716002)(68736005)(50466002)(77156002)(1456003)(77096005)(31966008)(15975445007)(122386002)(86362001)(33646002)(81816999)(2201001)(61296003)(46102003)(81686999)(40100003)(50986999)(21056001)(62966003)(92566001)(42186005)(76176999)(89996001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j-dzo2HS397D2KPeEUcOuoEWzBk Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Fri, 12 Dec 2014 09:40:51 -0000 netmod WG list 12apr2013 >> Recursive schemas are not allowed in YANG, and I believe it was a >>design feature. >> >> Lada 15sep2014 Hello Vladimir, I have been arguing to have recursive containment for quite some time. Have a good number of use-cases to support. regards Balazs etc etc Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: ; Sent: Thursday, December 11, 2014 4:16 PM > In http://tools.ietf.org/html/draft-wang-i2rs-rib-data-model-00, please > consider "container tunnel-encap": > > container tunnel-encap { > uses tunnel-encap; > choice nexthop-second-encap-or-not{ > case nexthop-second-encap{ > container nexthop-second-encap{ > description > "the two encapsulating nexthop.One example is a Pseudowire - which is MPLS over > some transport (MPLS or GRE for instance). Another example is VxLAN > over IP. "; > uses tunnel-encap; > choice nexthop-third-encap-or-not{ > case nexthop-third-encap { > container nexthop-third-encap{ > description > "the three encapsulating nexthop.One exampl is Option A -L3VPN OVER MPLS tunnel and MPLS over TE tunnel"; > uses tunnel-encap; > [...] > > My question to the yang experts are whether there's been any discussion > about generally recursive modeling? In the data model above, five levels > are accommodated - thankfully using groupings. This precludes a sixth or > later level of recursion. > > Please note that I'm not looking to specifically discuss the contents of > this specific modeling, just its impact on the language. Such constructs > may be common in certain types of routing modeling. > > -- Jeff > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Fri Dec 12 07:44:21 2014 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 4FEF11A8FD7; Fri, 12 Dec 2014 07:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3qSsDdvdhPq9; Fri, 12 Dec 2014 07:44:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C374A1A87A0; Fri, 12 Dec 2014 07:44:18 -0800 (PST) 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.31.17; Fri, 12 Dec 2014 15:43:56 +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.0031.000; Fri, 12 Dec 2014 15:43:56 +0000 From: Kent Watsen To: Ladislav Lhotka , Jeffrey Haas Thread-Topic: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? Thread-Index: AQHQFV9P9xddlsHcYUuSo/kVQJsE+ZyLxksA Date: Fri, 12 Dec 2014 15:43:55 +0000 Message-ID: References: <20141211161640.GC16279@pfrc> 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 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(230783001)(2656002)(87936001)(31966008)(4396001)(62966003)(83506001)(101416001)(50986999)(76176999)(21056001)(64706001)(20776003)(54356999)(77156002)(97736003)(99396003)(120916001)(102836002)(92566001)(105586002)(86362001)(46102003)(68736005)(107046002)(99286002)(106116001)(122556002)(66066001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <9BB0BB7A3C02EC4A8AC9B6DB87F7897B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jvKLbADIiLzsF0Tl1guN5bHgerw Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Fri, 12 Dec 2014 15:44:20 -0000 >Yes, this has already been discussed several times. It was a deliberate >design decision to avoid recursive structures in YANG. As I understand it, the decision was made was to enable parsers to be deterministic. Is that right? - how is it then that other MLs (XSD) can support recursion? My hope is that YANG can support recursion by requiring a "max-depth" or similar attribute. Most of my use-cases only need a handful number of recursions. Could something like a max-depth attribute be used to enable recursion in YANG? Thanks, Kent From nobody Fri Dec 12 10:03:54 2014 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 D10EF1ACF1D; Fri, 12 Dec 2014 10:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtc90VbUmdvz; Fri, 12 Dec 2014 10:03:41 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id BEC1B1A870B; Fri, 12 Dec 2014 10:03:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bjp/6l15Di+L9oJ8mxgW0OGcZRflvzfYexwsYmOdMctacaoeHcNBs88qLB3DGGNm; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XzUYv-0003JR-H9; Fri, 12 Dec 2014 13:03:33 -0500 Received: from 99.187.237.155 by webmail.earthlink.net with HTTP; Fri, 12 Dec 2014 13:03:32 -0500 Message-ID: <32660965.1418407413358.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Fri, 12 Dec 2014 10:03:32 -0800 (GMT-08:00) From: Randy Presuhn To: Kent Watsen , Ladislav Lhotka , Jeffrey Haas Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f129d1b29288448e67b74763b23d14c95350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NHcRBHR93_CRFIEa-b6EM9g08x0 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:03:50 -0000 Hi - >From: Kent Watsen >Sent: Dec 12, 2014 7:43 AM >To: Ladislav Lhotka , Jeffrey Haas >Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? > > > >>Yes, this has already been discussed several times. It was a deliberate >>design decision to avoid recursive structures in YANG. > > >As I understand it, the decision was made was to enable parsers to be >deterministic. Is that right? - how is it then that other MLs (XSD) can >support recursion? Ancient history note: in the CMIP / GDMO world object containment recursion was featured from the very outset. It caused no controversy. It did not complicate implementation of industrial-strength modeling language processors, protocol engines, agents, subagents, or managers. I'm not aware of it having caused any deployment troubles. With all classes being subclasses of "top", one can sensisbly argue that all containment in the CMIP world is effectively recursive. Subclass-specific containment rules ("name bindings" in that alternative universe) come for free as soon as one accepts the requirement to support extensibility without requiring reinitialization of the management infrastructure. The decision to separate name bindings (containment constraints) from class definitions was crucial, given the versioning rules and ability to define subclasses in that environment. Randy From nobody Fri Dec 12 11:14:56 2014 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 B3B301A8FD4 for ; Fri, 12 Dec 2014 11:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q37WjkaQbb1G for ; Fri, 12 Dec 2014 11:14:53 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612FF1A88CA for ; Fri, 12 Dec 2014 11:14:53 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gf13so6733003lab.35 for ; Fri, 12 Dec 2014 11:14:51 -0800 (PST) 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=TTEd44APWMqKBy1FqtLPAEB7F4GES1gD7QyGoePra3Y=; b=ecfbteYxxzlMSaH22bmneHX5Aru6ZWnGWiuPnzc9JvhTku+WOawBF7M09MMNl4Vkvo Z48pz4plp1gYjz/tgz9vm2P2k6yzDR9KDYDIFNbWBpymP4nRqsWugSS9F6EHWtLwc2aS vS17J2KU2azCHdU/JsT2kzJay56X9z4KTJ6coKlRrNvQ/dtOHQkuLfglkBU0M1o6xPrz 2PySvLbbR2xDA9dfITLE0ggEIlXHtQZZj2fDBnl7K0fRbOI1q9MGZvYX+ujGbWhJ68GV kNsWNDWkRJ2zDm45dJ+i4E1tnGVskQXqBXml0/38ip9kLGt3LvwmlYt/3I8zjTbAbd/+ CXWQ== X-Gm-Message-State: ALoCoQn0viiIr7tRtKPMn0T8PwveMVLeFbz8Xc8ZNjwACXkU4vL7QLtqViT+uPb4XNjaCR01asal MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr13530855laf.82.1418411691587; Fri, 12 Dec 2014 11:14:51 -0800 (PST) Received: by 10.112.157.233 with HTTP; Fri, 12 Dec 2014 11:14:51 -0800 (PST) In-Reply-To: References: <20141211161640.GC16279@pfrc> Date: Fri, 12 Dec 2014 11:14:51 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Mqqgch141suvS4eJdeS1VS_DQw8 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Fri, 12 Dec 2014 19:14:55 -0000 On Fri, Dec 12, 2014 at 7:43 AM, Kent Watsen wrote: > > >>Yes, this has already been discussed several times. It was a deliberate >>design decision to avoid recursive structures in YANG. > > > As I understand it, the decision was made was to enable parsers to be > deterministic. Is that right? - how is it then that other MLs (XSD) can > support recursion? > > My hope is that YANG can support recursion by requiring a "max-depth" or > similar attribute. Most of my use-cases only need a handful number of > recursions. Could something like a max-depth attribute be used to enable > recursion in YANG? > IMO the use of groupings and grouping expansion is not the right model for schema recursion. Automatic expansion to some arbitrary depth is a hack. Complex types that are not automatically expanded at all are a better fit. (YANG 2.0 discussions already?) > Thanks, > Kent Andy From nobody Sat Dec 13 20:29:17 2014 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 25DF71A1EEF for ; Sat, 13 Dec 2014 20:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 88KzHJv1oHOs for ; Sat, 13 Dec 2014 20:29:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E2F1A1EEA for ; Sat, 13 Dec 2014 20:29:12 -0800 (PST) Received: from BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sun, 14 Dec 2014 04:29:11 +0000 Received: from BLUPR05MB274.namprd05.prod.outlook.com ([10.141.22.148]) by BLUPR05MB274.namprd05.prod.outlook.com ([10.141.22.148]) with mapi id 15.01.0031.000; Sun, 14 Dec 2014 04:29:12 +0000 From: "Sachin Jain (EABU)" To: "netmod@ietf.org" Thread-Topic: Comments - [netmod] I-D Action: draft-ietf-netmod-acl-model-00.txt Thread-Index: AQHQF1aC1L+Dn1SJtkOBfG/j4YzGAA== Date: Sun, 14 Dec 2014 04:29: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 x-originating-ip: [116.197.184.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB275; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB275; x-forefront-prvs: 0425A67DEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174003)(377424004)(189002)(377454003)(199003)(51704005)(24454002)(1720100001)(77096005)(120916001)(15975445007)(106116001)(31966008)(2656002)(50986999)(92566001)(86362001)(107046002)(2351001)(107886001)(229853001)(21056001)(99396003)(110136001)(87936001)(68736005)(102836002)(40100003)(19580395003)(101416001)(83506001)(19580405001)(106356001)(66066001)(64706001)(230783001)(97736003)(2501002)(20776003)(46102003)(77156002)(99286002)(4396001)(105586002)(36756003)(62966003)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB274.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <6D452ED2D05C8048BA925C654F7E1C94@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/igJ4AlGUhvTsUL7bsH_-Rn_sDmU Subject: [netmod] Comments - I-D Action: draft-ietf-netmod-acl-model-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: Sun, 14 Dec 2014 04:29:15 -0000 Dear Authors Couple of initial comments on the draft are: 1. We to include a few more modules (or submodules) in the base draft. IMO, these should be applicable to most of the ACL implementations thats why I think they should be part of base ACL definition. At a high level, following represents what could be new sub-modules under ietf-acl. module: ietf-acl +-- access-lists | +-- policers | +-- bind-points | +-- company-proprietary-objects container policers { Description "Defines a list of policers. Each policer defines a set of policing parameters to rate limit or meter the traffic. One or more ACE can refer to a particular policer. This could be above the current way of defining policing parameters in the draft." } container bind-points { description "Defines list of bind points in the data path where the access-list is applied to take affect. Each bind point in uniquely defined by the ACL, the forwarding element that its applied to and along with its direction. For eg. an ACL could be bound to interface or a FIB in input or output direction. This should be extendible to include other company proprietary forwarding elements." } 2. Section 3.1 - Can we add a field 'operand' at ACE/ACL/match level? That will make the model very generic in terms of match expression. In the current form, its hardcoded to AND among matches for a ACE and OR among ACE for a ACL. Regards Sachin On 11/12/14 1:06 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the NETCONF Data Modeling Language Working >Group of the IETF. > > Title : Network Access Control List (ACL) YANG Data >Model > Authors : Dean Bogdanovic > Kiran Agrahara Sreenivasa > Lisa Huang > Dana Blair > Filename : draft-ietf-netmod-acl-model-00.txt > Pages : 23 > Date : 2014-11-10 > >Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netmod-acl-model-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Dec 15 20:00:01 2014 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 6F3071A0263; Mon, 15 Dec 2014 19:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-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 EP7OyqmUbaue; Mon, 15 Dec 2014 19:59:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247CD1A0371; Mon, 15 Dec 2014 19:59:57 -0800 (PST) Received: from BL2PR05CA0035.namprd05.prod.outlook.com (10.255.226.35) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 16 Dec 2014 03:59:34 +0000 Received: from BN1AFFO11FD021.protection.gbl (2a01:111:f400:7c10::100) by BL2PR05CA0035.outlook.office365.com (2a01:111:e400:c04::35) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Tue, 16 Dec 2014 03:59:33 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD021.mail.protection.outlook.com (10.58.52.81) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Tue, 16 Dec 2014 03:59:33 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 15 Dec 2014 19:59:32 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sBG3xTu29294; Mon, 15 Dec 2014 19:59:29 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sBG3x51k015809; Mon, 15 Dec 2014 22:59:08 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412160359.sBG3x51k015809@idle.juniper.net> To: Randy Presuhn In-Reply-To: <32660965.1418407413358.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 15 Dec 2014 22:59:05 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(47776003)(110136001)(81156004)(76506005)(77096005)(48376002)(20776003)(69596002)(230783001)(64706001)(120916001)(53416004)(62966003)(77156002)(106466001)(68736005)(105596002)(97736003)(50466002)(99396003)(4396001)(6806004)(107046002)(92566001)(103666002)(87936001)(21056001)(46102003)(84676001)(31966008)(54356999)(50986999)(86362001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB447; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:DM2PR05MB447; X-Forefront-PRVS: 04270EF89C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-q698QIqClbakDXQg7bi_UDY4r0 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Tue, 16 Dec 2014 03:59:59 -0000 Randy Presuhn writes: >Ancient history note: in the CMIP / GDMO world object containment >recursion was featured from the very outset. It caused no controversy. NETCONF rejected the idea of "objects". Config data is just data, nothing more magical. >It did not complicate implementation of industrial-strength modeling >language processors, protocol engines, agents, subagents, or managers. Saying that CMIP and GDMO were not complicated is, well, odd. Even the small port of the ocean that NETCONF boils turns out to be fairly complicated. Thanks, Phil From nobody Mon Dec 15 20:59:03 2014 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 74F391A0381; Mon, 15 Dec 2014 20:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfXFlGcsM8oa; Mon, 15 Dec 2014 20:59:00 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id D7A741A0371; Mon, 15 Dec 2014 20:58:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jh7+KvUihz+aKRbu6hImi2bcdUzTkpEYX0WomF/W6vahg3O7C8mWIzkCwWt2G1e9; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y0kDg-0007xw-E7; Mon, 15 Dec 2014 23:58:48 -0500 Received: from 76.254.48.105 by webmail.earthlink.net with HTTP; Mon, 15 Dec 2014 23:58:48 -0500 Message-ID: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Mon, 15 Dec 2014 20:58:48 -0800 (GMT-08:00) From: Randy Presuhn To: Phil Shafer Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f4dee0f6dcd43b74052f3135c7aedb579350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kSF-KMeQtjQnWdULHsL2jCEU398 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 04:59:02 -0000 Hi - >From: Phil Shafer >Sent: Dec 15, 2014 7:59 PM >To: Randy Presuhn >Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? > >Randy Presuhn writes: >>Ancient history note: in the CMIP / GDMO world object containment >>recursion was featured from the very outset. It caused no controversy. > >NETCONF rejected the idea of "objects". Config data is just data, >nothing more magical. I still believe that the lack of an underlying metamodel makes the netconf universe far more complicated than it needs to be, particularly when it comes to, say, managing open systems with hot- swappable components from multiple vendors or dealing with multiple versions of a kind of managed resource residing within a single system. >>It did not complicate implementation of industrial-strength modeling >>language processors, protocol engines, agents, subagents, or managers. > >Saying that CMIP and GDMO were not complicated is, well, odd. Even >the small port of the ocean that NETCONF boils turns out to be >fairly complicated. Apologies if this comes across as a rant. It's hard to hold my tongue watching NETCONF flailing on issues that were dealt with a quarter century ago. :-) There's a lot of IETF folklore about CMIP/GDMO being complicated. Much of that is, well, folklore, with roots in a highly politicized environment dominated by FUD marketing masquerading as technological insight. I've worked through the muck of the goriest details of the implementation of both CMIP/GDMO and SNMP/SMI technologies. Both sets have their strengths and weaknesses, but I still believe that CMIP/GDMO came closer to getting things right for dealing with systems complex enough to be interesting. (Rest of rant deleted, because it would just waste this group's time.) Randy From nobody Mon Dec 15 21:52:22 2014 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 989191A03A8 for ; Mon, 15 Dec 2014 21:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 VEPKoSwNx7OL for ; Mon, 15 Dec 2014 21:52:19 -0800 (PST) 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 A9AAA1A0371 for ; Mon, 15 Dec 2014 21:52:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 74636788; Tue, 16 Dec 2014 06:52:18 +0100 (CET) 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 YtjUG7I6HY3o; Tue, 16 Dec 2014 06:52:11 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 16 Dec 2014 06:52:17 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF89F2002C; Tue, 16 Dec 2014 06:52:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SR-vprKCvMdN; Tue, 16 Dec 2014 06:52:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7825020017; Tue, 16 Dec 2014 06:52:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 63B122FF7B9E; Tue, 16 Dec 2014 06:52:16 +0100 (CET) Date: Tue, 16 Dec 2014 06:52:16 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20141216055216.GA64351@elstar.local> Mail-Followup-To: Randy Presuhn , Phil Shafer , "netmod@ietf.org" References: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9cT0w6yGlyMpRy4_3DXKghxGQMk Cc: "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Tue, 16 Dec 2014 05:52:20 -0000 On Mon, Dec 15, 2014 at 08:58:48PM -0800, Randy Presuhn wrote: > > I still believe that the lack of an underlying metamodel makes > the netconf universe far more complicated than it needs to be, > particularly when it comes to, say, managing open systems with hot- > swappable components from multiple vendors or dealing with multiple > versions of a kind of managed resource residing within a single system. > Randy, what about writing a draft so we can review it and see how such a metamodel looks like and solves our problems? /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 Dec 16 01:31:50 2014 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 190151ACD59; Tue, 16 Dec 2014 01:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWD8hEbawuK7; Tue, 16 Dec 2014 01:31:48 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D706E1A90DC; Tue, 16 Dec 2014 01:31:47 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2628F1CC0238; Tue, 16 Dec 2014 10:31:45 +0100 (CET) From: Ladislav Lhotka To: Randy Presuhn , Phil Shafer In-Reply-To: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> References: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 16 Dec 2014 10:31:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YfwRG3E7-f16pXXvnqbnCb3xkzs Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Tue, 16 Dec 2014 09:31:50 -0000 Randy Presuhn writes: > Hi - > >>From: Phil Shafer >>Sent: Dec 15, 2014 7:59 PM >>To: Randy Presuhn >>Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >>Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? >> >>Randy Presuhn writes: >>>Ancient history note: in the CMIP / GDMO world object containment >>>recursion was featured from the very outset. It caused no controversy. >> >>NETCONF rejected the idea of "objects". Config data is just data, >>nothing more magical. > > I still believe that the lack of an underlying metamodel makes > the netconf universe far more complicated than it needs to be, > particularly when it comes to, say, managing open systems with hot- > swappable components from multiple vendors or dealing with multiple > versions of a kind of managed resource residing within a single > system. I now tend to agree with this, due to all the troubles we have with concurrent access through different management interfaces, ephemeral datastores, etc. Are there any documents left from those ancient times where I could read about the CMIP metamodel? Thanks, Lada > >>>It did not complicate implementation of industrial-strength modeling >>>language processors, protocol engines, agents, subagents, or managers. >> >>Saying that CMIP and GDMO were not complicated is, well, odd. Even >>the small port of the ocean that NETCONF boils turns out to be >>fairly complicated. > > Apologies if this comes across as a rant. It's hard to hold my > tongue watching NETCONF flailing on issues that were dealt with > a quarter century ago. :-) > > There's a lot of IETF folklore about CMIP/GDMO being complicated. > Much of that is, well, folklore, with roots in a highly politicized > environment dominated by FUD marketing masquerading as technological > insight. I've worked through the muck of the goriest details of the > implementation of both CMIP/GDMO and SNMP/SMI technologies. > Both sets have their strengths and weaknesses, but I still believe > that CMIP/GDMO came closer to getting things right for dealing with > systems complex enough to be interesting. > > (Rest of rant deleted, because it would just waste this group's > time.) > > Randy > > _______________________________________________ > 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 Dec 16 05:13:53 2014 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 46A821A1AFE for ; Tue, 16 Dec 2014 05:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzFW0yGOIdOf for ; Tue, 16 Dec 2014 05:13:50 -0800 (PST) Received: from epost.nunatak.no (epost.nunatak.no [193.200.93.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3F91A1AEA for ; Tue, 16 Dec 2014 05:13:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by epost.nunatak.no (Postfix) with ESMTP id CD2293EC800B for ; Tue, 16 Dec 2014 14:34:59 +0100 (CET) X-Virus-Scanned: amavisd-new at nunatak.no Received: from epost.nunatak.no ([127.0.0.1]) by localhost (epost.nunatak.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI4SirTF9MSi for ; Tue, 16 Dec 2014 14:34:51 +0100 (CET) Received: from [192.168.209.127] (unknown [192.168.209.127]) by epost.nunatak.no (Postfix) with ESMTPSA id 2BB733EC800F for ; Tue, 16 Dec 2014 14:34:51 +0100 (CET) Message-ID: <54902FFF.4030209@transpacket.com> Date: Tue, 16 Dec 2014 14:13:35 +0100 From: Vladimir Vassilev User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "netmod@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nVbf4HYLoace5g0PvEeO9Tubjpc Subject: [netmod] Schema node identifier MUST or MAY include schema nodes not part of the data tree (choice and case) 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, 16 Dec 2014 13:13:52 -0000 Hi, I am wondering if the choice and case schema nodes MUST or MAY be part of a schema node identifier. Example A schema node identifier without choice and case: augment "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:trunk-interface" {...} Example B schema node identifier with choice and case: augment "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:port-mode-choice/ethernet-switching:trunk/ethernet-switching:trunk-interface" {...} There is no requirement explicitly specified in the schema node identifier definition text 6.5 (RFC6020). Logically the absence of choice and case nodes is not introducing ambiguity. The only practical use of having them is when the node identifier identifies choice or case node. There are some YANG parser implementations that complain and at least one known to me that does not when choice and case are omitted. Vladimir From nobody Tue Dec 16 05:35:41 2014 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 8D8781A1B1E for ; Tue, 16 Dec 2014 05:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxdhvA43d1LN for ; Tue, 16 Dec 2014 05:35:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 15D951A1B0C for ; Tue, 16 Dec 2014 05:35:37 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id C52A31280098; Tue, 16 Dec 2014 14:35:35 +0100 (CET) Date: Tue, 16 Dec 2014 14:35:35 +0100 (CET) Message-Id: <20141216.143535.1080774695428450109.mbj@tail-f.com> To: vladimir@transpacket.com From: Martin Bjorklund In-Reply-To: <54902FFF.4030209@transpacket.com> References: <54902FFF.4030209@transpacket.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0NJSUY4Fl_c-6Wxljfq9nbv3h9o Cc: netmod@ietf.org Subject: Re: [netmod] Schema node identifier MUST or MAY include schema nodes not part of the data tree (choice and case) 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, 16 Dec 2014 13:35:38 -0000 Hi, Vladimir Vassilev wrote: > Hi, > > I am wondering if the choice and case schema nodes MUST or MAY be part > of a schema node identifier. The intention is MUST. > Example A schema node identifier without choice and case: > > augment > "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:trunk-interface" > {...} > > Example B schema node identifier with choice and case: > > augment > "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:port-mode-choice/ethernet-switching:trunk/ethernet-switching:trunk-interface" > {...} > > There is no requirement explicitly specified in the schema node > identifier definition text 6.5 (RFC6020). > > Logically the absence of choice and case nodes is not introducing > ambiguity. This is not correct. Suppose you have: container x { choice a { case b; } } augment /x { leaf y; } Does leaf y end up as /x/y or /x/a/b/y or /x/y/y? So then you can say that you don't have to specify choice and case nodes only if you have other nodes in there as well. And in this particular case do not treat the single leaf as a shorthand case. Clearly there are no such rules in 6020. /martin From nobody Tue Dec 16 06:14:09 2014 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 2007C1A1AB3 for ; Tue, 16 Dec 2014 06:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6ASBVTMN9iu for ; Tue, 16 Dec 2014 06:14:01 -0800 (PST) Received: from epost.nunatak.no (epost.nunatak.no [193.200.93.202]) by ietfa.amsl.com (Postfix) with ESMTP id 27E8A1A1AA9 for ; Tue, 16 Dec 2014 06:14:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by epost.nunatak.no (Postfix) with ESMTP id 5A29C3EC800F; Tue, 16 Dec 2014 15:35:11 +0100 (CET) X-Virus-Scanned: amavisd-new at nunatak.no Received: from epost.nunatak.no ([127.0.0.1]) by localhost (epost.nunatak.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDGkf7GysIvg; Tue, 16 Dec 2014 15:35:06 +0100 (CET) Received: from [192.168.209.127] (unknown [192.168.209.127]) by epost.nunatak.no (Postfix) with ESMTPSA id 7AC9E3EC800B; Tue, 16 Dec 2014 15:35:06 +0100 (CET) Message-ID: <54903E23.1060906@transpacket.com> Date: Tue, 16 Dec 2014 15:13:55 +0100 From: Vladimir Vassilev User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Martin Bjorklund References: <54902FFF.4030209@transpacket.com> <20141216.143535.1080774695428450109.mbj@tail-f.com> In-Reply-To: <20141216.143535.1080774695428450109.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fE0m_K-1whXZ7XIfFnm0aJ28aFs Cc: netmod@ietf.org Subject: Re: [netmod] Schema node identifier MUST or MAY include schema nodes not part of the data tree (choice and case) 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, 16 Dec 2014 14:14:06 -0000 Hi Martin, On 12/16/2014 02:35 PM, Martin Bjorklund wrote: > Hi, > > Vladimir Vassilev wrote: >> Hi, >> >> I am wondering if the choice and case schema nodes MUST or MAY be part >> of a schema node identifier. > > The intention is MUST. Then you agree there is place for improvement in the 6.5 section? > >> Example A schema node identifier without choice and case: >> >> augment >> "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:trunk-interface" >> {...} >> >> Example B schema node identifier with choice and case: >> >> augment >> "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:port-mode-choice/ethernet-switching:trunk/ethernet-switching:trunk-interface" >> {...} >> >> There is no requirement explicitly specified in the schema node >> identifier definition text 6.5 (RFC6020). >> >> Logically the absence of choice and case nodes is not introducing >> ambiguity. > > This is not correct. Suppose you have: It was more correct with the sentence that followed it: "Logically the absence of choice and case nodes is not introducing ambiguity. The only practical use of having them is when the node identifier identifies choice or case node." > > container x { > choice a { > case b; > } > } > > augment /x { > leaf y; > } > > Does leaf y end up as /x/y or /x/a/b/y or /x/y/y? > > So then you can say that you don't have to specify choice and case > nodes only if you have other nodes in there as well. And in this > particular case do not treat the single leaf as a shorthand case. > I do agree. Your example presents the case of schema node identifier targeting a choice (or not). But in the cases where the case and choice are not the target nodes their notion is just an information overhead. I am not saying the point of keeping schema node identifiers shorter is better then making life of parser developers easier. All I am saying is there is no clear definition in 6020 which can disambiguate the issue. And that is a problem that can be fixed. > Clearly there are no such rules in 6020. > > > /martin > Vladimir From nobody Tue Dec 16 07:24:09 2014 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 8027E1A1B3A for ; Tue, 16 Dec 2014 07:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sig4xtPuReI for ; Tue, 16 Dec 2014 07:24:05 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5933C1A1B30 for ; Tue, 16 Dec 2014 07:24:05 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so11421208lab.0 for ; Tue, 16 Dec 2014 07:24:03 -0800 (PST) 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=2Qw9iCm4m7Iq/Uhk1vc3Ds2AijyaMUIrpCmNLSJ0UTM=; b=XgfLWQAwkbI2zepjpCk/1oFK0T5PunqTHa3panVAl0YlVyq6t9c7hQBVW2nCtR1WcX VTxtbJ4g7mjaRyWjVsyPAXynw6Gir1AjR+QG/fN4zocP2yB/2DichLRVca30YuCmCFOv 7+zMn2bIKzdalJEnxtWhsC2U609tq4djV2Zc++jlJKnEHJojY3jpMAh14M8YQeLaqqJ+ ANgKv0KGcQaL9C5z/WA2yuoyujR9VlIExhGyE/aeOgzjXO/fLZksuPxW/Km8opi04WO8 FzSWieiSVY+PqydOecLM0tSh+4rPtum5Ni14/FUZLrkKHjtOQFPV/oSJAdiw3pZ83OEZ a/7g== X-Gm-Message-State: ALoCoQmzGVZKYWo+Pq2FCelD0c34ENnCWVdpiVVft8YKyJXtu6yQEmHtdjWKp2OSN/14Wd0qEFv+ MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr31079166lac.3.1418743443725; Tue, 16 Dec 2014 07:24:03 -0800 (PST) Received: by 10.112.157.233 with HTTP; Tue, 16 Dec 2014 07:24:03 -0800 (PST) In-Reply-To: <54903E23.1060906@transpacket.com> References: <54902FFF.4030209@transpacket.com> <20141216.143535.1080774695428450109.mbj@tail-f.com> <54903E23.1060906@transpacket.com> Date: Tue, 16 Dec 2014 07:24:03 -0800 Message-ID: From: Andy Bierman To: Vladimir Vassilev Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Rup24DyiVlFnqL-GDbYsbjat-l4 Cc: "netmod@ietf.org" Subject: Re: [netmod] Schema node identifier MUST or MAY include schema nodes not part of the data tree (choice and case) 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, 16 Dec 2014 15:24:07 -0000 On Tue, Dec 16, 2014 at 6:13 AM, Vladimir Vassilev wrote: > Hi Martin, > > On 12/16/2014 02:35 PM, Martin Bjorklund wrote: >> >> Hi, >> >> Vladimir Vassilev wrote: >>> >>> Hi, >>> >>> I am wondering if the choice and case schema nodes MUST or MAY be part >>> of a schema node identifier. >> >> >> The intention is MUST. > > > Then you agree there is place for improvement in the 6.5 section? > The schema nodes include choice and case. This is specified somewhere else, but sec. 6.5 does not define a schema node. >> >>> Example A schema node identifier without choice and case: >>> >>> augment >>> >>> "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:trunk-interface" >>> {...} >>> >>> Example B schema node identifier with choice and case: >>> >>> augment >>> >>> "/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:port-mode-choice/ethernet-switching:trunk/ethernet-switching:trunk-interface" >>> {...} >>> >>> There is no requirement explicitly specified in the schema node >>> identifier definition text 6.5 (RFC6020). >>> >>> Logically the absence of choice and case nodes is not introducing >>> ambiguity. >> >> >> This is not correct. Suppose you have: > > > It was more correct with the sentence that followed it: "Logically the > absence of choice and case nodes is not introducing ambiguity. The only > practical use of having them is when the node identifier identifies choice > or case node." > >> >> container x { >> choice a { >> case b; >> } >> } >> >> augment /x { >> leaf y; >> } >> >> Does leaf y end up as /x/y or /x/a/b/y or /x/y/y? >> >> So then you can say that you don't have to specify choice and case >> nodes only if you have other nodes in there as well. And in this >> particular case do not treat the single leaf as a shorthand case. >> > I do agree. Your example presents the case of schema node identifier > targeting a choice (or not). But in the cases where the case and choice are > not the target nodes their notion is just an information overhead. > > I am not saying the point of keeping schema node identifiers shorter is > better then making life of parser developers easier. All I am saying is > there is no clear definition in 6020 which can disambiguate the issue. And > that is a problem that can be fixed. > >> Clearly there are no such rules in 6020. The choice and case nodes are always specified in a schema node identifier. They are not the only schema nodes that do not have any corresponding instance document nodes. The rpc 'input' and 'output' nodes also appear in a schema-node identifier but never in an instance document, IMO the rules are clear. >> >> >> /martin >> > > Vladimir > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 16 09:13:49 2014 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 447161A7004; Tue, 16 Dec 2014 09:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFzlEOWhTHDS; Tue, 16 Dec 2014 09:13:36 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79A901A7002; Tue, 16 Dec 2014 09:11:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RzkiT4MsJJaDy9pXU726kWHo2JTRbwZKc0jxjm05eVoms3FRTGg/3xtbWm0H9nkW; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y0vev-0002Ju-MC; Tue, 16 Dec 2014 12:11:41 -0500 Received: from 99.187.238.7 by webmail.earthlink.net with HTTP; Tue, 16 Dec 2014 12:11:40 -0500 Message-ID: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 16 Dec 2014 09:11:41 -0800 (GMT-08:00) From: Randy Presuhn To: Ladislav Lhotka , Phil Shafer Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591fe963882b7e3ff01580a5205e93f6bfd5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lW3slvwxVaPl1yjsrTRMuFEhuH8 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:13:40 -0000 Hi - >From: Ladislav Lhotka >Sent: Dec 16, 2014 1:31 AM >To: Randy Presuhn , Phil Shafer >Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? ... >Are there any documents left from those ancient times where I could read >about the CMIP metamodel? Yes. To avoid further pollution of this email list, I'll send you some links directly. I have a busy day before me, so I probably won't get to it until late tonight, California time. Randy From nobody Tue Dec 16 10:31:33 2014 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 7E45B1ACDA1 for ; Tue, 16 Dec 2014 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BQgISc0ihNqg for ; Tue, 16 Dec 2014 10:31:30 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65321ACD9B for ; Tue, 16 Dec 2014 10:31:29 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so13247730wiw.2 for ; Tue, 16 Dec 2014 10:31:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=pfH19+d+CmE4DdABvAGRLB9WTQZxcwIZhGxdwoA8AMo=; b=MjLMbAp0Bt0TKmE7TRZzyQpzJUhs0xUDqyRDEQo/wjAzUkty1T7xeJmucChtvu8bgC a2xwXxZJOusamcdEuC7cArdbkq//WXNecscMxP5kyJ2bN7aEz6zogoEYp33+Ah8YTYTw BYjNb18UmX9zHdSFfGzMb8q2iTJv6bXdsU6Zg5M/QDOORC5E7Gozz0byHxo1JM6gXGcg bj+RXc7ejLNkgE8fJZuA+nuK7zCjUgSkbdNHuXH3Ifqzs1xTpV89KdHacotngjJAmn7K MJF0yrTRXbiZg3lNH38aw+WR/0iVCr0ubZO76GeHwKnl4wdILD89rmGhM0NSB9O5hbgN 6bJg== X-Gm-Message-State: ALoCoQloiix7wQdDEux+3gBH/KfFLyUB00xePf8I6xTHFpz36x9FWQtyg/SasFVBTWjQLIt9YhNb X-Received: by 10.194.62.19 with SMTP id u19mr54919901wjr.0.1418754688482; Tue, 16 Dec 2014 10:31:28 -0800 (PST) Received: from [192.168.1.4] (c-71-227-97-41.hsd1.mi.comcast.net. [71.227.97.41]) by mx.google.com with ESMTPSA id be2sm405675wjb.38.2014.12.16.10.31.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 10:31:26 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Christian Hopps In-Reply-To: Date: Tue, 16 Dec 2014 13:31:14 -0500 Message-Id: References: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> To: Jeff Tantsura X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/A9VgjzZp9z28VWMjZd4aI0tw8t8 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" , Randy Presuhn Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Tue, 16 Dec 2014 18:31:31 -0000 --Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822" --Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, there=E2=80=99s another option available to add the email address = to always accept. Once you do this it stops going into your holding = queue. I use this anytime someone sends non-spam mail. Chris. > On Dec 16, 2014, at 12:30 PM, Jeff Tantsura = wrote: >=20 > Randy/others who are non-members - please do subscribe, otherwise any = time > you post it goes to list administrators and we have to explicitly > allow/disallow your postings. > Subscription page - = https://www.ietf.org/mailman/listinfo/rtg-yang-coord = >=20 > Thanks! >=20 > Cheers, > Jeff --Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW, there=E2=80=99s another option available to add the = email address to always accept. Once you do this it stops going into = your holding queue. I use this anytime someone sends non-spam mail.

Chris.

On Dec 16, 2014, at 12:30 PM, Jeff Tantsura = <jeff.tantsura@ericsson.com> wrote:

Randy/others who are non-members = - please do subscribe, otherwise any time
you post it goes to list = administrators and we have to explicitly
allow/disallow your = postings.
Subscription page - https://www.ietf.org/mailman/listinfo/rtg-yang-coord

Thanks!

Cheers,
Jeff
= --Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822-- --Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37 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 iQIcBAEBCgAGBQJUkHp6AAoJEC4dgw7XuDAlZXEP/jHr+10+LPI1VWA9kwenM/6J TgZ8qsJzbID1ebdn+cmN/9l5voLkEdryAyqJTsWpD9ML9QGLXjgibV9AwKJjax/n RgkcysnBlcfuN3uf99XUjiYwd2ZQje4TQlgaIaGot2x7aC8Ka42gexD7Wt/NRYzV kNVBAVbyTJMmvH2FZNlpWUrQd7Ssp3u5dxp3er8DA36BA3r0mLskQeou2krY7iq1 ghUomVf2BBia/Lvb5zQVZkthdP1hbUkKvYwEOdR+9X+uuKFKDBOIpukQWcCG97L1 WoF/53wzJUGkMbiPIjecjzcVublwAgvO4r1XGuDjB3gGYyGMBYCHvqEsJs7tOmi/ g+D/Un9t8f6gnKxvy9ktT6wVmi0iW3zq2Z4hd5SvVNgJCtStFfjWBDoSHadJFNbu NFhLqQr9GVjtyKSvar6c0d5XxxaEnOGVAihwZ+cnmcmGT9Z4TCmFYP2usaSyb/zZ eBUxzTf7lxx4FK4Bmku/hvhiP4T+bG9rvsEbFOuMYM/B4tDAi635XpnPPh0rdVIT RDE8Sj1KP3m+U6V3d8y/V/oEUGnOaovzb6Cnxf/xYQC0JnU9nZD5Vz7vVfuGz/r7 /sOGuDEn+chvFo6+8KHlMBUtefJD61x2YSN+auhzZFjvb3ffoyFpZSXhOpOCh8og 1afNwQOTyYW5scPTeAur =fMXn -----END PGP SIGNATURE----- --Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37-- From nobody Tue Dec 16 12:18:22 2014 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 490761A1B9B; Tue, 16 Dec 2014 09:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uLl1rJGvWaXD; Tue, 16 Dec 2014 09:30:19 -0800 (PST) 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 6179C1A1BE0; Tue, 16 Dec 2014 09:30:19 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-f1-54900f486a9d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7B.E3.25146.84F00945; Tue, 16 Dec 2014 11:54:01 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 12:30:17 -0500 From: Jeff Tantsura To: Randy Presuhn , Ladislav Lhotka , Phil Shafer Thread-Topic: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? Thread-Index: AQHQGVNbQ5H2Mdw/80ekNKxb5DlrZZySRvUA Date: Tue, 16 Dec 2014 17:30:16 +0000 Message-ID: References: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> In-Reply-To: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <37406E5B8FA82F46936A7C53B69F8F11@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPuK4n/4QQg8832C0urJrLZjH/YiOr xZIz69kt7i88wm7x+/ltZgdWjyVLfjJ5XG+6yu7xY0MPu8emy3cYA1iiuGxSUnMyy1KL9O0S uDKm/rnAWvCNu+L3n+IGxilcXYycHBICJhLzP91kgbDFJC7cW8/WxcjFISRwhFFi4fztTBDO ckaJRdM2sIFUsQkYSPz/dhysQ0SgWOLTqweMIDazQJzE/+UnmUBsYQEXiQmHNrBC1LhK7Fz/ kxHCNpKYfmoWM4jNIqAqsen2GXYQm1fAXOLC2T9gM4UEwiQevd4FFucUCJc4++AN2F5GoOu+ n1rDBLFLXOLWk/lMEFcLSCzZc54ZwhaVePn4H9heUQE9iWcbNrNDxJUkPv6ezw7RqyOxYPcn NgjbWuLn2WVQM7Ulli18zQxxj6DEyZlPWCYwSsxCsm4WkvZZSNpnIWmfhaR9ASPrKkaO0uLU stx0I8NNjMD4PCbB5riDccEny0OMAhyMSjy8G/T7Q4RYE8uKK3MPMUpzsCiJ82pWzwsWEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwNhYHSS/3+OJ5VHjiH3SgUn+ZUGz1q469OuP4jnr808z /q960G/8/YrTp8ssMi/sVDp/cFyonl6QsPLy3QVyWhPWPY6eVVZXv2lbXW7RM9vWg1rCS07d OVkZfHOJxP1c1m/ndbe4S1aJNK6VMCpeeFuqYkdkiMUi006P8KLHKjP2HL3jMmXrjCQlluKM REMt5qLiRACCDbOfsAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0MHpEeCQSkR2xtSZp98KwVM1nh4 X-Mailman-Approved-At: Tue, 16 Dec 2014 12:18:19 -0800 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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: Tue, 16 Dec 2014 17:30:21 -0000 Randy/others who are non-members - please do subscribe, otherwise any time you post it goes to list administrators and we have to explicitly allow/disallow your postings. Subscription page - https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 Thanks! Cheers, Jeff -----Original Message----- From: Randy Presuhn Reply-To: Randy Presuhn Date: Tuesday, December 16, 2014 at 9:11 AM To: Ladislav Lhotka , Phil Shafer Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? >Hi - > >>From: Ladislav Lhotka >>Sent: Dec 16, 2014 1:31 AM >>To: Randy Presuhn , Phil Shafer >> >>Cc: "rtg-yang-coord@ietf.org" , >>"netmod@ietf.org" >>Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? >... >>Are there any documents left from those ancient times where I could read >>about the CMIP metamodel? > >Yes. To avoid further pollution of this email list, I'll >send you some links directly. I have a busy day before me, >so I probably won't get to it until late tonight, California >time. > >Randy > >_______________________________________________ >Rtg-yang-coord mailing list >Rtg-yang-coord@ietf.org >https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Dec 16 12:35:37 2014 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 5852B1A8793; Tue, 16 Dec 2014 12:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.054 X-Spam-Level: X-Spam-Status: No, score=-98.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_SUMOF=1, 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 vK2wDET8mTZ7; Tue, 16 Dec 2014 12:35:33 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 27B011A8786; Tue, 16 Dec 2014 12:35:33 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "NETCONF" , Date: Tue, 16 Dec 2014 15:35:28 -0500 Message-ID: <024901d0196f$d4901120$7db03360$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_024A_01D01945.EBBB41A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAZboapbH/TgJXUSQGTcosv2HJVOQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vzf9T-NUd5e1x0WAEGZCZr63hmk Cc: rtg-yang-coord@ietf.org, i2rs-chairs@tools.ietf.org Subject: [netmod] minutes and slides for the I2RS interim 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, 16 Dec 2014 20:35:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024A_01D01945.EBBB41A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_024B_01D01945.EBBB41A0" ------=_NextPart_001_024B_01D01945.EBBB41A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS has held two interims during December to discuss use cases, yang models for RIB and topology, and the I2RS requirements on protocol. These minutes of these meetings are attached. You can find slides and minutes for the December 11th, 2014 meeting at: http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedings.html You can find slides and minutes for the December 11th, 2014 meeting at: http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedings.html Please let us know if you have any questions we can answer regarding the I2RS current status. Sue Hares ------=_NextPart_001_024B_01D01945.EBBB41A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = has held two interims during December to discuss use cases, yang models = for RIB and topology, and the I2RS requirements on protocol.  These = minutes of these meetings are attached.

 

You can find = slides and minutes for the December 11th, 2014 meeting at: =

http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedi= ngs.html

 

You can find slides and minutes for the December = 11th, 2014 meeting at:

http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedi= ngs.html

 

Please let us know if you have any questions we can = answer regarding the I2RS current status.

 

Sue Hares =  

------=_NextPart_001_024B_01D01945.EBBB41A0-- ------=_NextPart_000_024A_01D01945.EBBB41A0 Content-Type: text/plain; name="i2rs-interim-minutes-2014-12-16.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i2rs-interim-minutes-2014-12-16.txt" I2RS interim, December 16, 2014. 10:00-11:40 ET Attendees: Hariharan Ananthakrishnan Alia Atlas Ignas Bagdonas Nitin Bahadur Lou Berger Andy Bierman Deborah Brungard Alexander Clemm Amit Dass Dhruv Dhody Jie Dong=20 Jan Medved Jie Dong Don Fedyk Cary FitzGarald Jeff Haas=20 Joel Halpern Susan Hares=20 Ace Linden Xufeng Liu Jan Medved=20 Dan Romascanu Ju=C3=ABrgen Sch=C3=B6nw=C3=A4lder Himanshu Shah Robert Varga Lixing Wang =20 Michael Wang Kent Watsen Qin (Bill) Wu=20 Agenda Discussion on I2RS RIB Info Drafts [10:00 - 10:30 (zctual)] discussing: = 1) Interaction between RIB Yang Model and draft-ietf-netmod-routing-cfg 2) Nexthop structures proposed in RIB Info Model = [draft-ietf-i2rs-rib-info-model-04]=20 Discussion of I2RS topology drafts [10:30 - 11:15] =20 Overview and PBR {Sue Hares] [10:30 - 10:35] Yang Model for Network Topologies: [Alexander Clemm] [10:35-10:45]=20 draft-clemm-i2rs-yang-network-topo-01.txt draft-clemm-i2rs-yang-l3-topo =20 Yang Model for L2 Topologies [Jie Dong] [10:45 - 10:50] =20 draft-dong-i2rs-yang-l2-network-topology=20 =20 Yang Model for Service Topologies [Qin Wu/Sue Hares] [10:50 - 11:00]=20 = http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/= Discussion on topology drafts [10:35 - 10:45]=20 =09 Protocol Discussion: [11:05 - 11:30] =20 1) Simple protocol option - [Dean Bogdanovic]=20 2) Complex Protocol option - [Sue Hares]=20 3) pub-sub option [Alexander Clemm, Eric Voit]=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I2RS Adoption calls in December-January=20 I2RS will make an adoption call for RIB Yang/IM model after 12/16/2014 = meeting. =20 Topics for 1/8/2015 and 1/23/2015 I2RS interim: =20 1) Protocol Requirements for I2RS=20 2) Topology drafts =20 3) RIB Info drafts.=20 =20 1) Document status:=20 Traceability draft has been adopted. We dovetail our Yang modules with netconf and netmod.=20 =3D=3D=3D=3D 2) Rib Info Yang model - Amit [slides] High level differences.=20 What are unique for i2rs? I2RS is not covering the default rib model, compared to the netmod-cfg = they do. Using capabilities for tunnel encap types. Propose add RPC from agent to client for route changes Q: Juergen - why do we need rpc vs. notification?=20 Lixing: Example from BGP use case. =E2=80=A6 Sue: This is for pub-sub, for retrieving history. From BGP use cases. Jan: Do we need both info and data model now? Sue: Alia says one draft. Alia: That=E2=80=99s up to WG. IM could proceed separately from DM = since we=E2=80=99re not yet rechartered for DM. Jeff: Notification in I2RS. Does it also belong in netmod-cfg? Amit: They should align. Sooner or later, we should come back and = revisit it. Alia: Amit and Lixing, very useful comparison vs. netmod rtg-cfg model. = Thanks for doing it. =20 There=E2=80=99s a recent draft by Eric et al. and motivations for = pub-sub.=20 Does it describe the rib model requirements? Useful for i2rs to discuss = and netconf to review. Sue: See end presentation. Nitin: Lots of questions raised. Is there a design team to resolve this? Sue: Yes. We are taking volunteers for that team. Nitin: Feel free to add me to it. =3D=3D=3D=3D=3D 3) Protocol Independent (Topology) Data Models - Sue [slides] 3.1 Contrast topology dependent vs. independent. PBR - Sits underneath the rib list, above the BNP. Default RIB? PBR needs a default RIB for failover. We are only proposing groups, rules. ------ 3.2 Network topology Models - Alex Clemm [slides] Represents both horizontal and vertical layering Lou B: Will you be in Thursday=E2=80=99s TEAS interim? Alex: Yes. Lou: Will defer. Grappling with issue of control plane topo vs. data = plane topology. L3 IGPs they=E2=80=99re the same. SDN, TE - = they=E2=80=99re not necessarily the same. Sue: PBR is a forwarding data plane focus. Qin will cover service = topology and Jie will cover Layer 2. Many people will join you on = Thursday. ------- 3.3 Yang data model for L2 topology - Jie Dong [slides] Jeff: Your model includes layer 2 physical info (vlan etc.) Does this = belong in our I2RS stuff? Alex=E2=80=99s draft lets you look between = layers. Do we want this level of detail in our model? Jie: Topo use case draft suggests we want to gather the sum of the info = from across the network. What about layer 3/2/1? Agree it needs = discussion. Alex: Reasonable to do this. Fine line between abstraction model vs. = other info, but not specific to topology. Discuss on case by case = basis. If not tied to topology properties, should go to inventory. Jie: Agreed. Sue: As Lou put it we have forwarding layer at l2 and control plane at = l2. Alex, when you speak at abstract, which do you mean? Alex: Both. Even with service. Jeff: If we allow write, then the l2 config details matter. Sue: Need active discussions on mail list. Tie into use case. 3.4 Service Topology Info Model - Qin Wu and Sue Hares=20 [slides] Joel: *Who* knows the info needed to populate this model? Service = topology needs to be more than just tunnels. Sue: Abstract topology to lay on top of network topology. We=E2=80=99re = describing this using UML. Joel: Starting to cover my questions. Let=E2=80=99s keep going. Lou: I think you made an important clarification. You mean TEAS requests = to I2RS. Juergen: Concerned with restconf extensions and netconf extensions being = called out in UML. They should work in both. Sue: Thanks for correction, will fix in next rev. [slides] Sue: Note how this ties back to Alex=E2=80=99s model. Additional = questions? Lou: Document has TE data. This doesn=E2=80=99t get covered in these = slides. Is that still there? Sue: We had removed it. Expect to harmonize with Alex. Lou: Usage of TE is not the normal use of it. Perhaps better term, like = NAT load balancer, etc.=20 TED is different than normal usage of TED. =20 Sue: I think you=E2=80=99re correct. We=E2=80=99ll update it, happy to = take further feedback. Don Fedyk: There is a lot more commonality in models in layer 3 models = and others.=20 They could be harmonize a bit more. Jeff: What is the additional harmonization=20 My point was the Yang Model for L3 (as presented) seemed to outline L3, = Service and Optical and missed L2 totally. (Not saying this is one document but one = architecture as presented). Then the L2 Presentation had some L2 but missed several L2 capabilities. = (VPLS, EVPN, VXLAN, PBB etc.)=20 If you look at this more generically each layer (l3,l2,l1) has:=20 Data path, Tunneling/Multiplexor/Virtual network, Topology, Topology = data base, TE extensions,=20 Control Plane. Each layer can and may use IS-IS or OSPF (and even BGP) = for some address distribution VPN information, connection coordination, TE information, = within the context of an Instance/VPN. Each layer can and may offer a service, p2p, p2mp, = mp2mp,(some type of persistent connection or set of connections that may have their own = resiliency mechanisms) at the layer or up to a higher layer.=20 Layers can be skipped and upper layers may be unaware of lower layers.=20 Lou Berger (from email response): My comment on control plane vs data = plane is very much in line with this comment. And Don has begun some of the discussion I was = hoping to talk a bit more about in Thursday's TEAS interim. (At least the TE aspects, as well = as the possible formal representation of control plane separately from data plane.) =E2=80=94=E2=80=94 Subscribing to datastore push updates - Alex Clemm [slides] XXX - transport and subscription decoupling =E2=80=94 Simple vs. Complex I2RS - Dean Bogdanovich and Sue (via mailing list) [slides] Joel: This was discussed in WG. Defining granularity at which we = conflict=20 should be in model. Not sure what we=E2=80=99re discussing here. Sue: Trying to come to some conclusion about ephemeral database from = ietf-91. Dean Bogdanovic thought there might be a different way to look at it. Joel: I don=E2=80=99t think these things are really primitives. = We=E2=80=99re only interacting with some properties of the interface. Same for route - only changing = some property. Jeff: Example of route, ownership is internal. Joel: Correct myself from route vs. route-table. Route-table handles = that arbitration. Jeff: Russ White basically says just interact with routing table, it is = much simpler. Joel: Have discussed with Russ - who does not believe we have covered = the scope properly. Sue: Agree that things are complex, like next hops, recursive nexthops. = Let us have more of this discussion on the mail list. =20 RFC 6095 may help here, per netconf folk. Don: Distinction is based on ability override something in config vs. = the ownership of that=20 thing. Objects that are simple can be easily made to override some = properties. Ownership is still in config. Only need this relationship if config is involved. Jeff: Had presented this override picture at last ietf. Covered by = option 4 =E2=80=9Cpanes of glass model=E2=80=9D. Sue: need to continue this on mailing list. Put more questions out on = list. Need to pick=20 this up for Jan 8 meeting. We had hoped this discussin would clarify = things, but=20 we need to go a few more rounds. ------=_NextPart_000_024A_01D01945.EBBB41A0 Content-Type: text/plain; name="i2rs-interim-minutes-2014-12-11-final-v2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i2rs-interim-minutes-2014-12-11-final-v2.txt" I2RS interim meeting December 11, 2014. Chairs Sue Hares, Jeffrey Haas. 10:00-11:00 ET Attendees: Jeff, Sue, Alia Amit Dass Dhruv Dhoty Hariharan Anathakakrishnan Igneous Bagdonas Lixing Wang Juergen Schoenwaelder Alexander Clemm Cary FitzGerald Dean Bogdanovich Don Fedyk Yael Frank Zafar Ali Status =3D=3D=3D=3D=3D=3D=3D RIB model looking for design team members. Currently, Amit and Lixing. Use case summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dean: The main issue with the protocol selection was does I2rs want to = talk directly to daemons or via configuration? Do we want to focus on managing = primitives such as routes, interfaces, etc. or do we want to manage more complex objects such as = VPNs (l3vpn, l2vpn, etc.) =20 If we can figure out what we want to do, it will make selecting protocol = behaviors a bit easier. Maybe even outside of the IETF since there already exist some solutions. = =20 What do we want to enable through the agent? E.g. Apache Thrift is an = interesting protocol=20 if we are dealing with primitives. Sue: Use cases have both. E.g. virtual topology. Can these be done = with just primitives? =20 One option is we can take a protocol selection that works for just the = primitives, but we know that BGP is something that people want to do and BGP cannot be solved = with just primitives. [slide Virtual topology cases] 25 reqs. that are in-charter. =20 [slide Discussion questions] Is it okay to just use primitives or do we need complex objects? Dean: If we do not want to support bgp vpns, only need primitives. =20 Ignas: One of the important thing is transactions. If we have both, = there is a lot of flexibility. =20 If transactions are not in protocol level but are in client agent = interaction or some other entity,=20 then we have to worry about deterministic issues. Jeff: Speed may require two distinct mechanisms. Ignas: Speed? Possible. Depends on use case. Maybe makes sense. Alia: In architecture, we do not have the idea of transactions. You may = have multiple operations in single exchange with agent. Trying to add transaction = complexity will rat-hole us. The concept of going to two mechanisms if the more complex use cases = sounds much better than trying to push more complexity into the simpler use cases. =20 Jeff: Getting state out of the system is also important. Dean: This might push us into duplicating cases already elsewhere? If = you can already do complex stuff via configuration - e.g. l3vpn - many components, each particular daemon = has work to do.=20 If we can do it using primitives as well, but exposing those interfaces = adds complexity. =20 Know from two vendors that we have different approaches; this would lead = to vendor specific issues. =20 Sue: Your suggestion is we go through config process for everything or = complex? Dean: Primitives should go through daemons - [it is] faster. But then = you limit flexibility. Complex always should go through config; already a solved problem. What = is open? Do we want to have two different ways to do this? Jeff: Simple, complex, issues may have protocol impacts. See discussion = about netconf vs. restconf. Sue: Dean, you know about this in thrift? Dean: Yes, have done some implementation. Sue: We should split this into simple or complex. Next week, let = discuss having the protocol split-up between complex and simple.=20 Dean: I=E2=80=99ve already done that split up, can send to list. Sue: Want to focus on protocol independent items and topology. = Alexander, could you do the analysis on your topology items? Alexander: Ok I can present that. Jeff: IETF session broke things down into interactions with config state = vs. i2rs injected state. This discussion clarified we need to further break this down to simple = vs. complex. Rib Info Models=E2=80=A6 [slides] Nitin and Sriganesh are in Asia and don=E2=80=99t think they can = present. They=E2=80=99ll talk info model next week. RIB yang model [technical issues with Amit and Lixing presenting=E2=80=A6] Jeff: How to do the multiple encaps. Is this a good idea? Amit: Good idea, best idea to date? =20 Jeff: Overlap with rtg-cfg? Amit: Not yet.=20 Hari: I did some of this. Collaborating with Lada. Will work with = Amit. There is some confusion about who is the derived model of whom.=20 Dean: Many discussions about rtg-cfg model. When we started modeling = other protocols such as ospf, we realized we could not do that work yet due to inconsistencies in = rtg-cfg. IMO, should be used as base for all rtg-cfg models. Jeff: Motivation for asking is overlap with regard to complex config vs. = primitives. Hari: Should be complementing? Sue: For next week, figure out how this relates to rtg-cfg. Amit will come back with that information to the next interim.=20 Sue: let=E2=80=99s talk about this on list. Can you drive it Dean, Amit, = Lixing? Alex, for your model? Jeff: Juergen general recursion for 1.1, 2.0? Juergen: 1.1, no. 2.0 no clue. Jeff: Raise on netmod mailing list? Juergen: yes.=20 Jeff: Will raise on netmod. EOF. ------=_NextPart_000_024A_01D01945.EBBB41A0-- From nobody Wed Dec 17 06:25:26 2014 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 0A72D1A871B for ; Wed, 17 Dec 2014 06:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUA3Y6QB1bIQ for ; Wed, 17 Dec 2014 06:25:21 -0800 (PST) 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 047121A8A68 for ; Wed, 17 Dec 2014 06:25:21 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id DF2C6A988A8CE; Wed, 17 Dec 2014 14:25:15 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sBHEP1Af019673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 09:25:17 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 09:25:16 -0500 From: "Sterne, Jason (Jason)" To: Ladislav Lhotka , Johnson Zhu Thread-Topic: [netmod] Any tool to test NETCONF/YANG RFC compliance? Thread-Index: AdAKEnGCUJOVdINjRM+8AtM0roPHsQALr8wAA/D3qwA= Date: Wed, 17 Dec 2014 14:25:15 +0000 Message-ID: References: <31BFEF67CF6AC44BBEDE1890158D73773851C120@ESGSCMB103.ericsson.se> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zm6kIADdyw3Vgww6z7s7aj06SyA Cc: "netmod@ietf.org" Subject: Re: [netmod] Any tool to test NETCONF/YANG RFC compliance? 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, 17 Dec 2014 14:25:24 -0000 I haven't done it directly myself but some of our dev folks are using pyang= to generate a schema from our yang files and then validating an response using xmllint. Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Thursday, November 27, 2014 2:54 AM To: Johnson Zhu Cc: netmod@ietf.org Subject: Re: [netmod] Any tool to test NETCONF/YANG RFC compliance? On 27 Nov 2014, at 08:20, Johnson Zhu wrote: > Hi, > =20 > We are looking some third party tool to test NETCONF/YANG RFC compliance. You can test data model compliance by saving protocol messages, such as rep= lies to or , in a file and then use pyang for validating = them. Here is a tutorial: https://code.google.com/p/pyang/wiki/InstanceValidation Lada > =20 > Any recommendation? > =20 > /Johnson > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Dec 17 06:28:09 2014 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 BFA161A1AA4 for ; Wed, 17 Dec 2014 06:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 vDorE_aKlBhp for ; Wed, 17 Dec 2014 06:28:03 -0800 (PST) Received: from sjmda16.webex.com (sjmda16.webex.com [64.68.124.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BF71A871B for ; Wed, 17 Dec 2014 06:28:03 -0800 (PST) Received: from jva2tc111.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-5.webex.com [64.68.121.240]) by sjmda16.webex.com (Postfix) with ESMTP id F052BA038D for ; Wed, 17 Dec 2014 14:28:02 +0000 (GMT) Received: from jva2tc111.webex.com (localhost [127.0.0.1]) by jva2tc111.webex.com (Postfix) with ESMTP id 9DDA71BF23D for ; Wed, 17 Dec 2014 14:28:02 +0000 (GMT) Date: Wed, 17 Dec 2014 14:28:02 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <541829245.15224.1418826482644.JavaMail.nobody@jva2tc111.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_15222_1495308702.1418826482643" X-Priority: 3 Importance: normal Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ONnSH2rVvpHzwOfXNEIc1CcWom4 Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:28:04 -0000 ------=_Part_15222_1495308702.1418826482643 Content-Type: multipart/Alternative; boundary="----=_Part_15223_1799717320.1418826482643" ------=_Part_15223_1799717320.1418826482643 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCldlZG5lc2RheSwgRGVjZW1iZXIgMTcsIDIw MTQKNDowMCBwbSAgfCAgRXVyb3BlIFRpbWUgKEJlcmxpbiwgR01UKzAxOjAwKSAgfCAgMiBocgoK CkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tOWQwZDlmOTNhZjdkMGZkMmI2YjUwMDdlMDRjMDhlNmQKTWVldGluZyBudW1iZXI6IDY0NyAw MDEgODc2Ck1lZXRpbmcgcGFzc3dvcmQ6IGRpbmdlbGRpbmcKCg0KSk9JTiBCWSBQSE9ORQ0KMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDcg MDAxIDg3NgoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcg dG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWZkY2FmZTMzMWE2ZjFlMjZmMmJiMTU3OTAwNjhiN2FhDQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21j CgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2Ug YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLgo= ------=_Part_15223_1799717320.1418826482643 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+V2Vk bmVzZGF5LCBEZWNlbWJlciAxNywgMjAxNAoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+NDowMCBwbSZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDtFdXJvcGUgVGltZSAoQmVybGluLCBHTVQrMDE6MDApJm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwOzIgaHIKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJs ZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWln aHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lk dGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBz dHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+CgkJCQkJCQkJCTxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05ZDBkOWY5M2FmN2QwZmQyYjZi NTAwN2UwNGMwOGU2ZCIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250 LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVldGlu ZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3Rh YmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50 Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRk aW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90ZD4K CQkJCQkJCQk8dGQ+NjQ3IDAwMSA4NzYKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJ CTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPk1lZXRpbmcgcGFz c3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+ZGluZ2VsZGluZzwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRk IHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48 dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxs LWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJn aW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3Mg Y29kZTombmJzcDs2NDcgMDAxIDg3NjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25z LnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMw MEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFi bGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0i aGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxl PSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bWZkY2FmZTMzMWE2ZjFlMjZmMmJiMTU3OTAwNjhiN2FhIiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1l ZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7 PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9u dC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAg IENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAg ICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0 YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJ CQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJ CUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwv dHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_15223_1799717320.1418826482643-- ------=_Part_15222_1495308702.1418826482643 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTIxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEyMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE0MTIxN1QxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTQxMjE3VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxClVJRDpXRUJFWC1NRUVUSU5HIENFTlRF Ui02LjA0NTY2ODAtMzE1MjQ0NjkyLVNVPWlldGYKRFRTVEFNUDoyMDE0MTIxN1QxNTAwMDBaCkRF U0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTlkMGQ5ZjkzYWY3ZDBmZDJiNmI1MDA3ZTA0YzA4ZTZkXG5NZWV0 aW5nIG51bWJlcjogNjQ3IDAwMSA4NzZcbk1lZXRpbmcgcGFzc3dvcmQ6IGRpbmdlbGRpbmdcblxu XG5KT0lOIEJZIFBIT05FXG4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSkgXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5h ZGEpXG5BY2Nlc3MgY29kZTogNjQ3IDAwMSA4NzZcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJp Y3Rpb25zOiBcbmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMu cGRmXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpc bmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbgpYLUFMVC1ERVND O0ZNVFRZUEU9dGV4dC9odG1sOgk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJS PiA8Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTlkMGQ5ZjkzYWY3ZDBmZDJiNmI1MDA3ZTA0YzA4 ZTZkIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2Vi RXggbWVldGluZzwvRk9OVD48L2E+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlcjo8 L0ZPTlQ+CQkJCQk8L3RkPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+NjQ3IDAwMSA4NzY8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJ CTwvdGFibGU+CQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpF PSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5kaW5nZWxkaW5nPC9GT05UPjwvdGQ+ PC90cj48L3RhYmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8 QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZu YnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ry b25nPjEtODc3LTY2OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVy IChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0NyAwMDEgODc2 PC9GT05UPiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxm cmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNF PSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7 IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09M T1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5i c3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJp YWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNl IGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBt YXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50 IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29y ZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0 aGUgc2Vzc2lvbi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOk5FVE1PRCBZQU5HIDEuMQpQUklPUklU WTo1CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExB WQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRB Ugo= ------=_Part_15222_1495308702.1418826482643-- From nobody Wed Dec 17 06:31:11 2014 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 CB3991A8976 for ; Wed, 17 Dec 2014 06:31:10 -0800 (PST) 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 6j4InqLBNTuX for ; Wed, 17 Dec 2014 06:31:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FAA1A8984 for ; Wed, 17 Dec 2014 06:31:06 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id D6AE913FB0D; Wed, 17 Dec 2014 15:31:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418826663; bh=V16kY7qTbBwLwYot4bV1KS4hig8k6JmHaoEY8m8THhc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=u2LcZTpaF6lrCcLiiWiHoYM9QpZ0eQ5EOYI85UvWITnODBPediky3fdJ48ZHDCmSu RHho4iLe+LELkMjKg4/S4ms/FiuuIi3f9plUZ0AaxDoHPjhhvVKzXL8D8hk/QCHssT Ai7As1Eb6tAZCZoaxu50kWndts4qxvnicyke2zBM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 17 Dec 2014 15:31:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31BFEF67CF6AC44BBEDE1890158D73773851C120@ESGSCMB103.ericsson.se> To: "Sterne, Jason (Jason)" X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nvv9qCdobdGInQyhSOduJr4KxJc Cc: "netmod@ietf.org" Subject: Re: [netmod] Any tool to test NETCONF/YANG RFC compliance? 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, 17 Dec 2014 14:31:11 -0000 > On 17 Dec 2014, at 15:25, Sterne, Jason (Jason) = wrote: >=20 > I haven't done it directly myself but some of our dev folks are using = pyang to generate a schema from our yang files and then validating an = response using xmllint. Yes, that=E2=80=99s exactly what I meant - unless your dev folks = generate W3C XML Schema. The =E2=80=98xsd=E2=80=99 plugin in pyang is = deprecated, DSDL schemas should be used instead. Lada >=20 > Jason >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav = Lhotka > Sent: Thursday, November 27, 2014 2:54 AM > To: Johnson Zhu > Cc: netmod@ietf.org > Subject: Re: [netmod] Any tool to test NETCONF/YANG RFC compliance? >=20 >=20 > On 27 Nov 2014, at 08:20, Johnson Zhu = wrote: >=20 >> Hi, >>=20 >> We are looking some third party tool to test NETCONF/YANG RFC = compliance. >=20 > You can test data model compliance by saving protocol messages, such = as replies to or , in a file and then use pyang for = validating them. Here is a tutorial: >=20 > https://code.google.com/p/pyang/wiki/InstanceValidation >=20 > Lada >=20 >>=20 >> Any recommendation? >>=20 >> /Johnson >> _______________________________________________ >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 17 06:33:18 2014 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 3379D1A8A87 for ; Wed, 17 Dec 2014 06:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 YiIskHYXUZDO for ; Wed, 17 Dec 2014 06:33:06 -0800 (PST) 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 CC1771A1B57 for ; Wed, 17 Dec 2014 06:33:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9712574D for ; Wed, 17 Dec 2014 15:33:04 +0100 (CET) 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 x1pzXoS_IM9V for ; Wed, 17 Dec 2014 15:32:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 17 Dec 2014 15:33:03 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0F7820034 for ; Wed, 17 Dec 2014 15:33:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XzELcCSW0xpt; Wed, 17 Dec 2014 15:33:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9ACA20035; Wed, 17 Dec 2014 15:33:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BCA0C2FF934D; Wed, 17 Dec 2014 15:33:01 +0100 (CET) Date: Wed, 17 Dec 2014 15:33:01 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141217143301.GB67974@elstar.local> Mail-Followup-To: netmod@ietf.org References: <541829245.15224.1418826482644.JavaMail.nobody@jva2tc111.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541829245.15224.1418826482644.JavaMail.nobody@jva2tc111.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rGEm1wyr65gts81P4Dt3QUsPLQA Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 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, 17 Dec 2014 14:33:15 -0000 Hi, the etherpad page is going to be this one: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2014-12-17?useMonospaceFont=true /js On Wed, Dec 17, 2014 at 02:28:02PM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Wednesday, December 17, 2014 > 4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m9d0d9f93af7d0fd2b6b5007e04c08e6d > Meeting number: 647 001 876 > Meeting password: dingelding > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 647 001 876 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=mfdcafe331a6f1e26f2bb15790068b7aa > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 17 06:56:36 2014 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 2C3B91A88EF for ; Wed, 17 Dec 2014 06:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG_rHLaeftWi for ; Wed, 17 Dec 2014 06:56:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id A5BCA1A88E9 for ; Wed, 17 Dec 2014 06:56:32 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 66C0812800C1; Wed, 17 Dec 2014 15:56:31 +0100 (CET) Date: Wed, 17 Dec 2014 15:57:37 +0100 (CET) Message-Id: <20141217.155737.1077411542593491564.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: 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: http://mailarchive.ietf.org/arch/msg/netmod/YX2G7ByXuY0pHR6r-zJgkAnObsg Cc: netmod@ietf.org Subject: Re: [netmod] Any tool to test NETCONF/YANG RFC compliance? 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, 17 Dec 2014 14:56:34 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTcgRGVj IDIwMTQsIGF0IDE1OjI1LCBTdGVybmUsIEphc29uIChKYXNvbikNCj4gPiA8amFzb24uc3Rlcm5l QGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4gSSBoYXZlbid0IGRvbmUgaXQg ZGlyZWN0bHkgbXlzZWxmIGJ1dCBzb21lIG9mIG91ciBkZXYgZm9sa3MgYXJlIHVzaW5nDQo+ID4g cHlhbmcgdG8gZ2VuZXJhdGUgYSBzY2hlbWEgZnJvbSBvdXIgeWFuZyBmaWxlcyBhbmQgdGhlbiB2 YWxpZGF0aW5nIGFuDQo+ID4gPGVkaXQtY29uZmlnPiByZXNwb25zZSB1c2luZyB4bWxsaW50Lg0K PiANCj4gWWVzLCB0aGF04oCZcyBleGFjdGx5IHdoYXQgSSBtZWFudCAtIHVubGVzcyB5b3VyIGRl diBmb2xrcyBnZW5lcmF0ZSBXM0MNCj4gWE1MIFNjaGVtYS4gVGhlIOKAmHhzZOKAmSBwbHVnaW4g aW4gcHlhbmcgaXMgZGVwcmVjYXRlZCwgRFNETCBzY2hlbWFzDQo+IHNob3VsZCBiZSB1c2VkIGlu c3RlYWQuDQoNClRoZSB4c2QgcGx1Z2luIGlzIG5vdCBvbmx5IGRlcHJlY2F0ZWQsIGl0IGlzIGJy b2tlbi4gIEFsbCBlZmZvcnRzIGhhdmUNCmdvbmUgaW50byB0aGUgZHNkbCBwbHVnaW4uICBVc2Ug dGhhdCBvbmUgZm9yIHZhbGlkYXRpb24uICBXZSBzaG91bGQNCnJlbW92ZSB0aGUgeHNkIHBsdWdp biBpbiB0aGUgbmV4dCBweWFuZyByZWxlYXNlLCBpbiBvcmRlciB0byBhdm9pZA0KY29uZnVzaW9u Lg0KDQoNCi9tYXJ0aW4NCg== From nobody Wed Dec 17 20:00:21 2014 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 5464C1A0195; Wed, 17 Dec 2014 20:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 xL6YzUL-k2mE; Wed, 17 Dec 2014 20:00:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D374E1A0030; Wed, 17 Dec 2014 20:00:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 50836181C67; Wed, 17 Dec 2014 19:59:48 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141218035948.50836181C67@rfc-editor.org> Date: Wed, 17 Dec 2014 19:59:48 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/POvxnE5nKmkJ63aTNC21pdtTZm0 Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] RFC 7407 on A YANG Data Model for SNMP Configuration 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, 18 Dec 2014 04:00:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7407 Title: A YANG Data Model for SNMP Configuration Author: M. Bjorklund, J. Schoenwaelder Status: Standards Track Stream: IETF Date: December 2014 Mailbox: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de Pages: 88 Characters: 155373 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-snmp-cfg-08.txt URL: https://www.rfc-editor.org/rfc/rfc7407.txt This document defines a collection of YANG definitions for configuring SNMP engines. This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 18 04:20:01 2014 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 CC0051A6FB9; Thu, 18 Dec 2014 04:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tanfmVWewCaq; Thu, 18 Dec 2014 04:19:58 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF801A6FA3; Thu, 18 Dec 2014 04:19:57 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-ed-5492c66b43e4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.E3.29772.B66C2945; Thu, 18 Dec 2014 13:19:55 +0100 (CET) Received: from [159.107.197.172] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.195.1; Thu, 18 Dec 2014 13:19:54 +0100 Message-ID: <5492C66A.3070807@ericsson.com> Date: Thu, 18 Dec 2014 13:19:54 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kent Watsen , Ladislav Lhotka , Jeffrey Haas References: <20141211161640.GC16279@pfrc> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW72sUkhBk/3ilvsP/iW1eLAHHaL C6vmslnMv9jIavH7+W1mB1aPJUt+Mnlcb7rK7rHp8h1Gj8u9W1kDWKK4bFJSczLLUov07RK4 MnqOr2crmMtb8X3rNdYGxkVcXYycHBICJhIdr2ewQdhiEhfurQeyuTiEBI4wSmzaO4URwlnL KDH9xQ1mkCpeAW2J/e9usYLYLAKqEr13V7KA2GwCRhJT+8+D2aICURJ3LvWzQtQLSpyc+QQs LiKQLtHUfRbMZhaIk/i//CQTiC0s4CSx4slGsPlCAjUSu06tAKrh4OAUMJR49IMHotxW4sKc 61Ct8hLb386BKteQeHjhL+sERsFZSLbNQtIyC0nLAkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiB4X1wy2+DHYwvnzseYhTgYFTi4TVwnhQixJpYVlyZe4hRmoNFSZx34bl5wUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYlWLvrZi3bMHHW93te7QORx6KX2RxtG2Zxtq8N48vtlQu /aFQ/J5ZMH1X7onm19fk/tnWJH54vzJqirKMgaVLzucpiyapsL048NKTo8TxSMrSpeYXXkau qvi9vZ11hUPZ+xvf8rqbV3WsmTwnzfnYVYaTblc7dDlZ9j6fNHvJ70Wi+6anrVCNbFRiKc5I NNRiLipOBAD9eY4JUAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3XaTnCJBHzWXfTGDhOeBxUbdG6M Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in 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, 18 Dec 2014 12:20:00 -0000 Hello, I would still love to have recursive containment in YANG. I have a number of use cases where recursion is the natural, the" easy to understand" way to model. E.g. we model HW parts as replaceable units (chassis, shelves, cabinets, cards, daughter cards, interfaces, etc). There can be such a variety of containments, relationships, that the easiest way is to use some global holding structure "replaceable unit" and let it contain itself. And yes all this can be done by a simple list with references, but that has a number of disadvantages. Just by allowing a grouping to contain itself, most of my use cases would be solved. And maxdepth is a good idea. Balazs On 2014-12-12 16:43, Kent Watsen wrote: > >> Yes, this has already been discussed several times. It was a deliberate >> design decision to avoid recursive structures in YANG. > > As I understand it, the decision was made was to enable parsers to be > deterministic. Is that right? - how is it then that other MLs (XSD) can > support recursion? > > My hope is that YANG can support recursion by requiring a "max-depth" or > similar attribute. Most of my use-cases only need a handful number of > recursions. Could something like a max-depth attribute be used to enable > recursion in YANG? > > Thanks, > Kent > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From joanna.wang@ericsson.com Thu Dec 18 22:25:39 2014 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 5EA7C1ACC8D for ; Thu, 18 Dec 2014 22:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zjgBF6yhYHMd for ; Thu, 18 Dec 2014 22:25:38 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DA11A912C for ; Thu, 18 Dec 2014 22:25:37 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-71-5493c4dee1b5 Received: from ESGSCHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.42.24955.ED4C3945; Fri, 19 Dec 2014 07:25:35 +0100 (CET) Received: from ESGSCMB109.ericsson.se ([169.254.9.179]) by ESGSCHC002.ericsson.se ([146.11.116.71]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:25:14 +0800 From: Joanna Wang To: "netmod@ietf.org" Thread-Topic: Any open source netconf client tools supporting RFC6022/RFC5717 Thread-Index: AdAbVITggJq5DwQmR9+oD57D0tTAJA== Date: Fri, 19 Dec 2014 06:25:14 +0000 Message-ID: <2F1BC1E8B96DBA4C881181EF050C4C846F267CE5@ESGSCMB109.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.6] Content-Type: multipart/alternative; boundary="_000_2F1BC1E8B96DBA4C881181EF050C4C846F267CE5ESGSCMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje79I5NDDJoOKlrMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEnfXrMVzNKpuHfwEEsD4yn1LkZODgkBE4nPtzqZIGwxiQv3 1rOB2EICRxglOp9LdzFyAdlLGCXWveoDK2IT0JE4smshO4gtIqAuMXMnRIOwgIfEi88vWCDi vhIrVt5khrD1JE7M2ALWyyKgKnG5aQUjiM0LVPPn1xWwOYwCshLTHt0Hq2EWEJe49WQ+1EEC Ekv2nGeGsEUlXj7+xwphK0hM33CPEaI+X2LP6UlMEDMFJU7OfMIygVFoFpJRs5CUzUJSBhHX kViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMbE wS2/VXcwXn7jeIhRgINRiYd3w5TJIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgbHySz1Db9abs9W2n0I/flZ7JfDZQuBEn3aF6Z0bE/5FqLnWbDq9TvsQ 11qRgBPMzvKJ/71PLJmeeqRe3sti+rnUrX+7OfsNpy5I2rcmnt9WOlziTJX/xBNzIvncRMxF VY+UnJXXvPnX+z9j/lJJvvqTFuwxLx7MaPJjdWrKXCo08UiWY1TIJSWW4oxEQy3mouJEAEMb ZjpqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OlcE1orIpdYvC-_QXvWxLgGwBoU Subject: [netmod] Any open source netconf client tools supporting RFC6022/RFC5717 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, 19 Dec 2014 06:28:28 -0000 --_000_2F1BC1E8B96DBA4C881181EF050C4C846F267CE5ESGSCMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI greetings, Is there any open-source NETCONF client tools support RFC6022/RFC5717 6022 Oct 2010 YANG Module for NETCONF Monitoring 5717 Dec 2009 Partial Lock Remote Procedure Call (RPC) for NETCONF Joanna Wang --_000_2F1BC1E8B96DBA4C881181EF050C4C846F267CE5ESGSCMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

HI greetings,

 

Is there any open-source NETCONF client tools suppor= t RFC6022/RFC5717

 

6022

Oct 2010

YANG Module for NETC= ONF Monitoring

5717

Dec 2009

Partial Lock Remote = Procedure Call (RPC) for NETCONF

 

 

Joanna Wang

 

--_000_2F1BC1E8B96DBA4C881181EF050C4C846F267CE5ESGSCMB109erics_-- From nobody Sat Dec 20 09:55:30 2014 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 0EA671A8937 for ; Sat, 20 Dec 2014 09:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlPR1dx-qsdf for ; Sat, 20 Dec 2014 09:55:27 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86A21A88C8 for ; Sat, 20 Dec 2014 09:55:26 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so2255686lab.20 for ; Sat, 20 Dec 2014 09:55:25 -0800 (PST) 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=P8UOPRlol5Crzo0na2s0ExbiZSpe1knVNlxKVN7WHX4=; b=Y1yTvZezZ6v46a9xBzSsNak3lZgoHshKX9ENrd6NexbeNr0XD5+MWiUaLqn0GdW34r Y+F94U63Rkv2Lts8MHstI9MTex5RactXm7o/+4JNGt8EcSPMX0roZ1U/vSljS50udFaJ q07aQMbi+f4ZGncr65UZ2zn3ud9Q/5SN7L21NIpG88V2TxK8wUtL5XM1+7WuvuUycNDI I7DMDBH4bgyxyveINokneWE7fRzCjFCOs+MzoEzgMPMY+qOgaIPhilEq06JT8FZUkmxJ GO5plh7TXtboR9MUXgouGu5tqpApwk2WoN64gb0YxYv85xjmJw9qKWGny8VlneHZ5VoH JnbA== X-Gm-Message-State: ALoCoQlNiXlpvlf0uNPH5xy2eD2LPwkrkFMOzhWXAFXDbh2tp5hpPpy5okl53BkX6V9jzdWqldLU MIME-Version: 1.0 X-Received: by 10.112.185.99 with SMTP id fb3mr13466690lbc.21.1419098125199; Sat, 20 Dec 2014 09:55:25 -0800 (PST) Received: by 10.112.157.233 with HTTP; Sat, 20 Dec 2014 09:55:25 -0800 (PST) Date: Sat, 20 Dec 2014 09:55:25 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RzoH7VRAnuuGv1S1A9X_rTiboaU Subject: [netmod] Y59: what about decimal56 data type? 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, 20 Dec 2014 17:55:28 -0000 Hi, Should we be doing something in YANG 1.1 to make large number math safer? IMO a guideline that warns "it won't work" it not doing very much. Would a decimal56 data type be safe to convert to float64? If so, should YANG have a new data type for "safe math"? Andy From nobody Tue Dec 23 23:36:53 2014 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 B9A4B1ACD4E for ; Tue, 23 Dec 2014 23:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 vez79_IWCfV9 for ; Tue, 23 Dec 2014 23:36:49 -0800 (PST) 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 A8E071ACD4D for ; Tue, 23 Dec 2014 23:36:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F008DE57 for ; Wed, 24 Dec 2014 08:36:46 +0100 (CET) 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 asedwCOGrXWJ for ; Wed, 24 Dec 2014 08:36:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 24 Dec 2014 08:36:45 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A1652002C for ; Wed, 24 Dec 2014 08:36:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id I8GqN_v7Tc3s; Wed, 24 Dec 2014 08:36:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3796D20017; Wed, 24 Dec 2014 08:36:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 92AE53012738; Wed, 24 Dec 2014 08:36:43 +0100 (CET) Date: Wed, 24 Dec 2014 08:36:43 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141224073643.GA39117@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OrlKFdcUfgHFtI0GMdnYJKSgpvY Subject: [netmod] [FWD] RFC 7405 on Case-Sensitive String Support in ABNF 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, 24 Dec 2014 07:36:50 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, this might be relevant for the YANG 1.1 specification (no idea whether someone updates abnfgen and friends to support the new syntax). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --mYCpIKhGyMATD0i+ 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.224.2; Wed, 24 Dec 2014 06:00:33 +0100 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 1CAA820017 for ; Wed, 24 Dec 2014 06:00:33 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by atlas1.jacobs-university.de (Postfix) with ESMTP id C5AA266F for ; Wed, 24 Dec 2014 06:00:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.5, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Authentication-Results: demetrius2.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas1b.jacobs-university.de ([212.201.44.13]) by localhost (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030) with ESMTP id 902XORlzJGPR for ; Wed, 24 Dec 2014 06:00:31 +0100 (CET) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate: -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 atlas1b.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 24 Dec 2014 06:00:31 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 923201ACC7F; Tue, 23 Dec 2014 20:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1419397179; bh=gadzUWKRsrJaSiR7ht7Mozj23LB53mBpDCRwVp7n49s=; h=To:Subject:From:Message-Id:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=jTwmeOI7vEmYn8EQv1nophrSQp2kDmVmItWHA2IeXStxPo7xNhy1d5JU05W3liesk XDv16THkkR3F8WFkjU6WG7KmT06ZvW8EwhDhc9LRgf4D6wgEjBylxU30UWmyZhG5zK DGLBx9y4m+VHzY2H5OSRr9vkbmrnHRYscZQcAeTM= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3944D1AC44B for ; Tue, 23 Dec 2014 20:59:33 -0800 (PST) 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 nyLp-lMRjNZc for ; Tue, 23 Dec 2014 20:59:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA2F1AC44A for ; Tue, 23 Dec 2014 20:59:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4F85918123F; Tue, 23 Dec 2014 20:58:51 -0800 (PST) To: , Subject: RFC 7405 on Case-Sensitive String Support in ABNF X-PHP-Originating-Script: 6000:ams_util_lib.php From: Message-ID: <20141224045851.4F85918123F@rfc-editor.org> Date: Tue, 23 Dec 2014 20:58:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/-LppyKz3oTB25iX7WPU16VWZYdc CC: X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Sender: IETF-Announce Content-Type: text/plain Return-Path: ietf-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 Request for Comments is now available in online RFC libraries. RFC 7405 Title: Case-Sensitive String Support in ABNF Author: P. Kyzivat Status: Standards Track Stream: IETF Date: December 2014 Mailbox: pkyzivat@alum.mit.edu Pages: 4 Characters: 6668 Updates: RFC5234 I-D Tag: draft-kyzivat-case-sensitive-abnf-02.txt URL: https://www.rfc-editor.org/rfc/rfc7405.txt This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --mYCpIKhGyMATD0i+-- From nobody Mon Dec 29 07:59:30 2014 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 8E0641A87C2 for ; Mon, 29 Dec 2014 07:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrV3hbiBxxRf for ; Mon, 29 Dec 2014 07:59:23 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAFC1A87B2 for ; Mon, 29 Dec 2014 07:59:23 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E819A1CC086E; Mon, 29 Dec 2014 16:59:23 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 29 Dec 2014 16:59:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HXOfkmDJ9Klr_Xot0_OuEsFyRVg Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 29 Dec 2014 15:59:28 -0000 Andy Bierman writes: > Hi, > > Should we be doing something in YANG 1.1 to make large number math safer? > IMO a guideline that warns "it won't work" it not doing very much. I agree, but I don't know how to make it safer, except for removing decimal64, uint64 and int64 types, which is clearly unacceptable. > > Would a decimal56 data type be safe to convert to float64? > If so, should YANG have a new data type for "safe math"? The same problem affects int64 and uint64 as well: for the leaf definition leaf foo { type int64; must ". <= 1000000000000000000"; } the following value is accepted as valid: 1000000000000000001 (both long numbers have 19 digits). Lada > > > 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 Mon Dec 29 08:17:09 2014 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 EDDC51A8851 for ; Mon, 29 Dec 2014 08:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHKvKZJsWzTW for ; Mon, 29 Dec 2014 08:17:06 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A381A884B for ; Mon, 29 Dec 2014 08:17:06 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so11163471lbg.19 for ; Mon, 29 Dec 2014 08:17:04 -0800 (PST) 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=/n6I74cES4BUDWk4FwaJZ+5Sqx1KcORyni4okuQBBFk=; b=BBWov0Tq56YfM5B2qWClVAW2FkWHUSedZfa/PtVsjS7G7ihMfqlxFmAINuvTH3KKsQ pJ1WOwlgAJoAyL6Z59AT5fsQ9GOpK1iGirQgSGlN+luY9x0eET0SvYjw7giWvIwJedF1 A8UetCW0+H8jPXhLx5v92gIGPSp4J0AK/7WiDtQVr5Klci99RcqCTQubcHDvfAOjFL11 QoePKJBadvjW0hDFVg6MlPzoa5+bZIo1oSZvwQo2N2CIN23QsgPP1lUU9nM6y48zbPSL OLLhn3HfgXQ3dOLw3Z8S8vRCsASw+r7zbybyZdJ+I0kt21X3IhTHSur3TPEJCjuddy1O ZJcg== X-Gm-Message-State: ALoCoQmi34vVJJr+1QasDn4hg69EI5RXxgW8YSWb3MpE9ZUAqnR/MTk9m7mmiurbWiJ6hvI2C/lT MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr58473123lau.42.1419869824365; Mon, 29 Dec 2014 08:17:04 -0800 (PST) Received: by 10.112.77.231 with HTTP; Mon, 29 Dec 2014 08:17:04 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Dec 2014 08:17:04 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a747kDPJxrUwY9LoWsqq1Wuk3Oo Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 29 Dec 2014 16:17:08 -0000 On Mon, Dec 29, 2014 at 7:59 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> Hi, >> >> Should we be doing something in YANG 1.1 to make large number math safer? >> IMO a guideline that warns "it won't work" it not doing very much. > > I agree, but I don't know how to make it safer, except for removing > decimal64, uint64 and int64 types, which is clearly unacceptable. > >> >> Would a decimal56 data type be safe to convert to float64? >> If so, should YANG have a new data type for "safe math"? > > The same problem affects int64 and uint64 as well: for the leaf definition > > leaf foo { > type int64; > must ". <= 1000000000000000000"; > } > > the following value is accepted as valid: > > 1000000000000000001 > > (both long numbers have 19 digits). > But this is int64. If the designer picked decimal56 instead then this would be an illegal value right? The must-expr would not even matter, right? Why would a real data model have a must-stmt that was not safe for plain XPath (regardless of YANG usage)? What are some real use-cases? The point of the data type is to provide the designer with a number that is safe to use in XPath. The designer would obviously have to choose this new data type instead of one of the 64 bit data types (because an unsafe XPath must/when expression was needed for this leaf). I am not convinced anybody wants to write "large number XPath" in must/when expressions. This may not be an operational problem. I agree that the code will do the wrong thing if this issue occurs. That much is clear. > Lada > Andy >> >> >> 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 Mon Dec 29 09:04:07 2014 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 74D491A89D3 for ; Mon, 29 Dec 2014 09:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Qnz6Y1pJ_Xya for ; Mon, 29 Dec 2014 09:04:03 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CF1A89B9 for ; Mon, 29 Dec 2014 09:03:58 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA17218; Mon, 29 Dec 2014 12:03:52 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sBTH3qUO065738; Mon, 29 Dec 2014 12:03:52 -0500 (EST) (envelope-from spakes@snmp.com) Received: from localhost (spakes@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) with ESMTP id sBTH3q6w065735; Mon, 29 Dec 2014 12:03:52 -0500 (EST) (envelope-from spakes@snmp.com) X-Authentication-Warning: mainfs.snmp.com: spakes owned process doing -bs Date: Mon, 29 Dec 2014 12:03:51 -0500 (EST) From: David Spakes To: Andy Bierman , "netmod@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AE6CjEXzjjr2wUN7sAg3GkVRyUU Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 29 Dec 2014 17:04:05 -0000 Andy, When I read your post about "safe math" this morning, it reminded me of the original discussion about decimal64 way back in 2009. I had similar concerns at that time, so I propsed a derived type called "real". My last mention of it was in a post on October 26, 2009. I would like to resubmit it for the working group's consideration now. typedef real { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } type decimal64 { fraction-digits 17; range "-9.99999999999999999 .. 9.99999999999999999"; } type decimal64 { fraction-digits 16; range "-99.9999999999999999 .. 99.9999999999999999"; } type decimal64 { fraction-digits 15; range "-999.999999999999999 .. 999.999999999999999"; } type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The real type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type real is able to express configuration and state data as any of the real numbers in the set. The real type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. Positive numbers larger than 99999999999999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -99999999999999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -99999999999999999.9 and 99999999999999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the real type through rounding or truncation. For example, pi could be rounded (up) to 3.14159265358979324 or truncated to 3.14159265358979323 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } David Spakes On Mon, 29 Dec 2014, Ladislav Lhotka wrote: > Andy Bierman writes: > >> Hi, >> >> Should we be doing something in YANG 1.1 to make large number math safer? >> IMO a guideline that warns "it won't work" it not doing very much. > > I agree, but I don't know how to make it safer, except for removing > decimal64, uint64 and int64 types, which is clearly unacceptable. > >> >> Would a decimal56 data type be safe to convert to float64? >> If so, should YANG have a new data type for "safe math"? > > The same problem affects int64 and uint64 as well: for the leaf definition > > leaf foo { > type int64; > must ". <= 1000000000000000000"; > } > > the following value is accepted as valid: > > 1000000000000000001 > > (both long numbers have 19 digits). > > Lada > >> >> >> Andy ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From nobody Mon Dec 29 09:11:26 2014 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 41B881A89B5 for ; Mon, 29 Dec 2014 09:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbG6mnHULzwh for ; Mon, 29 Dec 2014 09:11:12 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D691A8A3A for ; Mon, 29 Dec 2014 09:11:10 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so12389428lbj.23 for ; Mon, 29 Dec 2014 09:11:08 -0800 (PST) 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=zXQ5Vr5CzdCzB9o4McUNkxLeSHtgxmLdfDYbFk6NHvU=; b=LwCv4KzD4Beb/9lh3ktXfnwpVHB7mf7UlQaHkBQ+hnWBUUsUl2FbIU6QFjKutGVsZX a7j7eYxYRFZ7OpWlS9DWXcCHXy29L8CCJGGtawAO6AfpikdJ98dsa7JDnlBE0SLkHHEb Zs7kfiHTxsS2roaT0tzV+5VD/cQXounz7vLVYDNOUZ3IjFKfgtd6EkdbUbhTVAScwfGT 6HiPWdn1ns+kzpSJWWAUdtVQkAoc8uKwgHKQFJpot3VxtFZwpbyAxArSM5jhkB8hX9DT 1j1fhjy8egDldlz2Mpv49+q+Qj8+RvPcQowcdbyoKmt4WoJEmAPAqFPdOJkH9mei/3i9 rzRQ== X-Gm-Message-State: ALoCoQlt7pfqcoYB9YTq9YdpNmWvdEh5i8oEeAVOrM5IdfHlytCHiKaTFIfPC6ANdlJ3BC8CoAcv MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr58783984lau.42.1419873068787; Mon, 29 Dec 2014 09:11:08 -0800 (PST) Received: by 10.112.77.231 with HTTP; Mon, 29 Dec 2014 09:11:08 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Dec 2014 09:11:08 -0800 Message-ID: From: Andy Bierman To: David Spakes Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4Rvx2j2oLlcWWZ4k5eAlsHue7mw Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 29 Dec 2014 17:11:17 -0000 Hi, I remember this thread. I agree we should use your typedef for "float64". I think another typedef for "float32" would also be needed. Andy On Mon, Dec 29, 2014 at 9:03 AM, David Spakes wrote: > Andy, > > When I read your post about "safe math" this morning, it reminded me of the > original discussion about decimal64 way back in 2009. I had similar > concerns at that time, so I propsed a derived type called "real". My > last mention of it was in a post on October 26, 2009. I would like to > resubmit it for the working group's consideration now. > > typedef real { > type union { > type decimal64 { > fraction-digits 18; > range "-0.999999999999999999 .. 0.999999999999999999"; > } > type decimal64 { > fraction-digits 17; > range "-9.99999999999999999 .. 9.99999999999999999"; > } > type decimal64 { > fraction-digits 16; > range "-99.9999999999999999 .. 99.9999999999999999"; > } > type decimal64 { > fraction-digits 15; > range "-999.999999999999999 .. 999.999999999999999"; > } > type decimal64 { > fraction-digits 14; > range "-9999.99999999999999 .. 9999.99999999999999"; > } > type decimal64 { > fraction-digits 13; > range "-99999.9999999999999 .. 99999.9999999999999"; > } > type decimal64 { > fraction-digits 12; > range "-999999.999999999999 .. 999999.999999999999"; > } > type decimal64 { > fraction-digits 11; > range "-9999999.99999999999 .. 9999999.99999999999"; > } > type decimal64 { > fraction-digits 10; > range "-99999999.9999999999 .. 99999999.9999999999"; > } > type decimal64 { > fraction-digits 9; > range "-999999999.999999999 .. 999999999.999999999"; > } > type decimal64 { > fraction-digits 8; > range "-9999999999.99999999 .. 9999999999.99999999"; > } > type decimal64 { > fraction-digits 7; > range "-99999999999.9999999 .. 99999999999.9999999"; > } > type decimal64 { > fraction-digits 6; > range "-999999999999.999999 .. 999999999999.999999"; > } > type decimal64 { > fraction-digits 5; > range "-9999999999999.99999 .. 9999999999999.99999"; > } > type decimal64 { > fraction-digits 4; > range "-99999999999999.9999 .. 99999999999999.9999"; > } > type decimal64 { > fraction-digits 3; > range "-999999999999999.999 .. 999999999999999.999"; > } > type decimal64 { > fraction-digits 2; > range "-9999999999999999.99 .. 9999999999999999.99"; > } > type decimal64 { > fraction-digits 1; > range "-99999999999999999.9 .. 99999999999999999.9"; > } > type enumeration { > enum overflow; > enum underflow; > } > } > description > "The real type defines a large, finite set of real numbers with > varying degrees of magnitude and precision. An object of type > real is able to express configuration and state data as any of > the real numbers in the set. The real type is suitable for > applications that deal with ratios in which the decimal point is > not fixed to a single position. > > Positive numbers larger than 99999999999999999.9 in state data > SHALL be represented as an overflow. The enumerated value > overflow is not valid for an operation. > > Negative numbers larger than -99999999999999999.9 in state data > SHALL be represented as an underflow. The enumerated value > underflow is not valid for an operation. > > Real numbers between -99999999999999999.9 and 99999999999999999.9 > (inclusive) having a combination of magnitude and precision that > falls outside of one of the range substatements in the union-- > including irrational numbers such as 'pi'--may only be > represented by the real type through rounding or truncation. > For example, pi could be rounded (up) to 3.14159265358979324 or > truncated to 3.14159265358979323 to preserve as much of the > precision information as possible. Note that an application > could choose to round (down) the value of pi to 3.14 or truncate > the value of pi to 3.14. This specification does not define > rules for the rounding or truncating of such values, considering > these decisions to be application-specific."; > } > > > David Spakes > > > > On Mon, 29 Dec 2014, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >>> Hi, >>> >>> Should we be doing something in YANG 1.1 to make large number math safer? >>> IMO a guideline that warns "it won't work" it not doing very much. >> >> >> I agree, but I don't know how to make it safer, except for removing >> decimal64, uint64 and int64 types, which is clearly unacceptable. >> >>> >>> Would a decimal56 data type be safe to convert to float64? >>> If so, should YANG have a new data type for "safe math"? >> >> >> The same problem affects int64 and uint64 as well: for the leaf definition >> >> leaf foo { >> type int64; >> must ". <= 1000000000000000000"; >> } >> >> the following value is accepted as valid: >> >> 1000000000000000001 >> >> (both long numbers have 19 digits). >> >> Lada >> >>> >>> >>> Andy > > > > ------------------------------------------------------------- > David Spakes email: spakes@snmp.com > SNMP Research voice: +1 865 573 1434 > 3001 Kimberlin Heights Road fax: +1 865 573 9197 > Knoxville, TN 37920-9716 USA http://www.snmp.com > ------------------------------------------------------------- > From nobody Mon Dec 29 10:35:32 2014 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 8C54A1A8AE6 for ; Mon, 29 Dec 2014 10:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, 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 OSXoJMcUaHtL for ; Mon, 29 Dec 2014 10:35:29 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 50BC21A87EA for ; Mon, 29 Dec 2014 10:35:19 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA22834; Mon, 29 Dec 2014 13:34:58 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sBTIYxYf066319; Mon, 29 Dec 2014 13:34:59 -0500 (EST) (envelope-from spakes@snmp.com) Received: from localhost (spakes@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) with ESMTP id sBTIYuR3066316; Mon, 29 Dec 2014 13:34:57 -0500 (EST) (envelope-from spakes@snmp.com) X-Authentication-Warning: mainfs.snmp.com: spakes owned process doing -bs Date: Mon, 29 Dec 2014 13:34:56 -0500 (EST) From: David Spakes To: Andy Bierman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ObUa8kvoKG1oztTEm8TFismOovM Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 29 Dec 2014 18:35:31 -0000 Andy, I changed typedef real to typedef float64, and I created a typedef float32, per your suggestions. They are included below at the end of the message. David On Mon, 29 Dec 2014, Andy Bierman wrote: > Hi, > > I remember this thread. > I agree we should use your typedef for "float64". > I think another typedef for "float32" would also be needed. > > > Andy > > > On Mon, Dec 29, 2014 at 9:03 AM, David Spakes wrote: >> Andy, >> >> When I read your post about "safe math" this morning, it reminded me of the >> original discussion about decimal64 way back in 2009. I had similar >> concerns at that time, so I propsed a derived type called "real". My >> last mention of it was in a post on October 26, 2009. I would like to >> resubmit it for the working group's consideration now. typedef float64 { type union { type decimal64 { fraction-digits 18; range "-0.999999999999999999 .. 0.999999999999999999"; } type decimal64 { fraction-digits 17; range "-9.99999999999999999 .. 9.99999999999999999"; } type decimal64 { fraction-digits 16; range "-99.9999999999999999 .. 99.9999999999999999"; } type decimal64 { fraction-digits 15; range "-999.999999999999999 .. 999.999999999999999"; } type decimal64 { fraction-digits 14; range "-9999.99999999999999 .. 9999.99999999999999"; } type decimal64 { fraction-digits 13; range "-99999.9999999999999 .. 99999.9999999999999"; } type decimal64 { fraction-digits 12; range "-999999.999999999999 .. 999999.999999999999"; } type decimal64 { fraction-digits 11; range "-9999999.99999999999 .. 9999999.99999999999"; } type decimal64 { fraction-digits 10; range "-99999999.9999999999 .. 99999999.9999999999"; } type decimal64 { fraction-digits 9; range "-999999999.999999999 .. 999999999.999999999"; } type decimal64 { fraction-digits 8; range "-9999999999.99999999 .. 9999999999.99999999"; } type decimal64 { fraction-digits 7; range "-99999999999.9999999 .. 99999999999.9999999"; } type decimal64 { fraction-digits 6; range "-999999999999.999999 .. 999999999999.999999"; } type decimal64 { fraction-digits 5; range "-9999999999999.99999 .. 9999999999999.99999"; } type decimal64 { fraction-digits 4; range "-99999999999999.9999 .. 99999999999999.9999"; } type decimal64 { fraction-digits 3; range "-999999999999999.999 .. 999999999999999.999"; } type decimal64 { fraction-digits 2; range "-9999999999999999.99 .. 9999999999999999.99"; } type decimal64 { fraction-digits 1; range "-99999999999999999.9 .. 99999999999999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The float64 type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type float64 is able to express configuration and state data as any of the real numbers in the set. The float64 type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. Positive numbers larger than 99999999999999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -99999999999999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -99999999999999999.9 and 99999999999999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the real type through rounding or truncation. For example, pi could be rounded (up) to 3.14159265358979324 or truncated to 3.14159265358979323 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } typedef float32 { type union { type decimal64 { fraction-digits 9; range "-0.999999999 .. 0.999999999"; } type decimal64 { fraction-digits 8; range "-9.99999999 .. 9.99999999"; } type decimal64 { fraction-digits 7; range "-99.9999999 .. 99.9999999"; } type decimal64 { fraction-digits 6; range "-999.999999 .. 999.999999"; } type decimal64 { fraction-digits 5; range "-9999.99999 .. 9999.99999"; } type decimal64 { fraction-digits 4; range "-99999.9999 .. 99999.9999"; } type decimal64 { fraction-digits 3; range "-999999.999 .. 999999.999"; } type decimal64 { fraction-digits 2; range "-9999999.99 .. 9999999.99"; } type decimal64 { fraction-digits 1; range "-99999999.9 .. 99999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The float32 type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type float32 is able to express configuration and state data as any of the real numbers in the set. The float32 type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. Positive numbers larger than 99999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -99999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -99999999.9 and 99999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the real type through rounding or truncation. For example, pi could be rounded (down) to 3.14159265 or truncated to 3.14159265 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From nobody Mon Dec 29 13:16:19 2014 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 A88821ACD1D for ; Mon, 29 Dec 2014 13:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xR6k2fJu5OI for ; Mon, 29 Dec 2014 13:16:17 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3310B1ACD1E for ; Mon, 29 Dec 2014 13:16:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jk1+21V5EJF8oRely0lPKkBU1jMKX0QwsVLtzrt6f52h7J0jNdNetfhbvzuoZ3+A; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y5hfk-0008Gh-6Y for netmod@ietf.org; Mon, 29 Dec 2014 16:16:16 -0500 Received: from 76.254.49.235 by webmail.earthlink.net with HTTP; Mon, 29 Dec 2014 16:16:15 -0500 Message-ID: <6640706.1419887775957.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Mon, 29 Dec 2014 13:16:15 -0800 (GMT-08:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f17b648c43070e937fe33577bec4a03ed350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.39 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TV5t7vTHfg74VIEJDaWCph3BNVs Subject: Re: [netmod] Y59: what about decimal56 data type? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 21:16:18 -0000 Hi - These types have greater precision and smaller ranges than their IEEE 754 floating-point counterparts. That seems to me to be a bug-factory in the making. Having greater precision than their IEEE 754 counterparts means they'll have all the problems this group has encountered in the handling of int64. There's a quick summary at http://en.wikipedia.org/wiki/IEEE_floating_point Randy From nobody Mon Dec 29 14:04:08 2014 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 4DCAA1ACDF0 for ; Mon, 29 Dec 2014 14:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, 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 KaNWn3ok93vJ for ; Mon, 29 Dec 2014 14:03:54 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 030BC1ACDCE for ; Mon, 29 Dec 2014 14:03:53 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA03096; Mon, 29 Dec 2014 17:03:35 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sBTM3ajt067974; Mon, 29 Dec 2014 17:03:36 -0500 (EST) (envelope-from spakes@snmp.com) Received: from localhost (spakes@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) with ESMTP id sBTM3W8A067971; Mon, 29 Dec 2014 17:03:35 -0500 (EST) (envelope-from spakes@snmp.com) X-Authentication-Warning: mainfs.snmp.com: spakes owned process doing -bs Date: Mon, 29 Dec 2014 17:03:32 -0500 (EST) From: David Spakes To: Randy Presuhn In-Reply-To: <6640706.1419887775957.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Message-ID: References: <6640706.1419887775957.JavaMail.root@elwamui-little.atl.sa.earthlink.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cvihrcJJgFwvldoB1nx2lB6-gns Cc: netmod@ietf.org Subject: Re: [netmod] Y59: float64 and float32 typedefs 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, 29 Dec 2014 22:03:56 -0000 On Mon, 29 Dec 2014, Randy Presuhn wrote: > Hi - > > These types have greater precision and smaller ranges > than their IEEE 754 floating-point counterparts. > That seems to me to be a bug-factory in the making. > > Having greater precision than their IEEE 754 counterparts > means they'll have all the problems this group has > encountered in the handling of int64. > > There's a quick summary at > http://en.wikipedia.org/wiki/IEEE_floating_point > > Randy Hi Randy, On http://en.wikipedia.org/wiki/IEEE_floating_point, the section near the bottom called "Character representation" says, "When using a decimal floating point format the decimal representation will be preserved using...16 decimal digits for decimal64...7 decimal digits for decimal32" If I understand correctly, for my typedef to be fully compatible with IEEE 754, we would need to reduce the number of digits in each range substatement so that the combined total of magnitude and precision would add up to 16 digits for float64 and 7 digits for float32. Does everyone agree that I grasp the implication correctly? Below, I have adjusted the typedefs based on my understanding of what it would take to achieve complete compatibility with IEEE 754. There are fewer decimal64 members in each union (fewer values of fraction-digits are represented). Let's continue the discussion from this point. Is this a step in the right direction? Why or why not? typedef float64 { type union { type decimal64 { fraction-digits 16; range "-0.9999999999999999 .. 0.9999999999999999"; } type decimal64 { fraction-digits 15; range "-9.999999999999999 .. 9.999999999999999"; } type decimal64 { fraction-digits 14; range "-99.99999999999999 .. 99.99999999999999"; } type decimal64 { fraction-digits 13; range "-999.9999999999999 .. 999.9999999999999"; } type decimal64 { fraction-digits 12; range "-9999.999999999999 .. 9999.999999999999"; } type decimal64 { fraction-digits 11; range "-99999.99999999999 .. 99999.99999999999"; } type decimal64 { fraction-digits 10; range "-999999.9999999999 .. 999999.9999999999"; } type decimal64 { fraction-digits 9; range "-9999999.999999999 .. 9999999.999999999"; } type decimal64 { fraction-digits 8; range "-99999999.99999999 .. 99999999.99999999"; } type decimal64 { fraction-digits 7; range "-999999999.9999999 .. 999999999.9999999"; } type decimal64 { fraction-digits 6; range "-9999999999.999999 .. 9999999999.999999"; } type decimal64 { fraction-digits 5; range "-99999999999.99999 .. 99999999999.99999"; } type decimal64 { fraction-digits 4; range "-999999999999.9999 .. 999999999999.9999"; } type decimal64 { fraction-digits 3; range "-9999999999999.999 .. 9999999999999.999"; } type decimal64 { fraction-digits 2; range "-99999999999999.99 .. 99999999999999.99"; } type decimal64 { fraction-digits 1; range "-999999999999999.9 .. 999999999999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The float64 type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type float64 is able to express configuration and state data as any of the real numbers in the set. The float64 type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. The following restrictions ensure that the float64 type can be correctly implemented on all systems that support a double precision floating point types and comply with IEEE 754. Positive numbers larger than 999999999999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -999999999999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -999999999999999.9 and 999999999999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the float64 type through rounding or truncation. For example, pi could be rounded (down) to 3.141592653589793 or truncated to 3.141592653589793 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } typedef float32 { type union { type decimal64 { fraction-digits 7; range "-0.9999999 .. 0.9999999"; } type decimal64 { fraction-digits 6; range "-9.999999 .. 9.999999"; } type decimal64 { fraction-digits 5; range "-99.99999 .. 99.99999"; } type decimal64 { fraction-digits 4; range "-999.9999 .. 999.9999"; } type decimal64 { fraction-digits 3; range "-9999.999 .. 9999.999"; } type decimal64 { fraction-digits 2; range "-99999.99 .. 99999.99"; } type decimal64 { fraction-digits 1; range "-999999.9 .. 999999.9"; } type enumeration { enum overflow; enum underflow; } } description "The float32 type defines a large, finite set of real numbers with varying degrees of magnitude and precision. An object of type float32 is able to express configuration and state data as any of the real numbers in the set. The float32 type is suitable for applications that deal with ratios in which the decimal point is not fixed to a single position. The following restrictions ensure that the float32 type can be correctly implemented on all systems that support a single precision floating point types and comply with IEEE 754. Positive numbers larger than 999999.9 in state data SHALL be represented as an overflow. The enumerated value overflow is not valid for an operation. Negative numbers larger than -999999.9 in state data SHALL be represented as an underflow. The enumerated value underflow is not valid for an operation. Real numbers between -999999.9 and 999999.9 (inclusive) having a combination of magnitude and precision that falls outside of one of the range substatements in the union-- including irrational numbers such as 'pi'--may only be represented by the float32 type through rounding or truncation. For example, pi could be rounded (up) to 3.141593 or truncated to 3.141592 to preserve as much of the precision information as possible. Note that an application could choose to round (down) the value of pi to 3.14 or truncate the value of pi to 3.14. This specification does not define rules for the rounding or truncating of such values, considering these decisions to be application-specific."; } -David ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From nobody Mon Dec 29 17:50:24 2014 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 500721ACEC1 for ; Mon, 29 Dec 2014 17:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, 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 PXThKQAEq3VY for ; Mon, 29 Dec 2014 17:50:22 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B71ACEBA for ; Mon, 29 Dec 2014 17:50:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=t9k7QnEoZAl851KiQRPca+FnM3nvAf4fvuOCJ4JWQ60XQazMS3u+VvQgSAyJww1a; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y5lwz-0003uh-78 for netmod@ietf.org; Mon, 29 Dec 2014 20:50:21 -0500 Received: from 76.254.49.235 by webmail.earthlink.net with HTTP; Mon, 29 Dec 2014 20:50:20 -0500 Message-ID: <4919451.1419904221094.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 29 Dec 2014 17:50:20 -0800 (GMT-08:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f1f930f67171d164ed662efa816c7a2cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uiI1YVsta-WYX5MancbNokzDnVk Subject: Re: [netmod] Y59: float64 and float32 typedefs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 01:50:23 -0000 Hi - >From: David Spakes >Sent: Dec 29, 2014 2:03 PM >To: Randy Presuhn >Cc: netmod@ietf.org, David Spakes >Subject: Re: [netmod] Y59: float64 and float32 typedefs ... >If I understand correctly, for my typedef to be fully compatible with >IEEE 754, we would need to reduce the number of digits in each range >substatement so that the combined total of magnitude and precision >would add up to 16 digits for float64 and 7 digits for float32. >Does everyone agree that I grasp the implication correctly? There is another implication which comes into play when values can be set via other management interfaces or computed within an implementation: if an implementation's internal representation is, for example, IEEE 754 64-bit float, there will be a set of possible IEEE 754 values which would not survive the round trip through the string representation. The big caveat for implementors to consider with a type like this is that they cannot rely on their floating point hardware (or emulation package) to produce values (as results of arithmetic operations) that will be within the set of string values supported by this type definition, so if they're using the IEEE types internally, they'd need to wrap logic that updates netconf-accessible values with "de-fuzzing" logic. I think typical floating point epsilon logic for equality comparisons probably wouldn't work correctly in all cases, but someone needs to do the math to see what happens on the corner cases. Randy From nobody Tue Dec 30 01:50:30 2014 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 6A78E1B29A6 for ; Tue, 30 Dec 2014 01:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.306 X-Spam-Level: *** X-Spam-Status: No, score=3.306 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ush6IkC7JFLJ for ; Tue, 30 Dec 2014 01:50:22 -0800 (PST) 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 9F7551B29A4 for ; Tue, 30 Dec 2014 01:50:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D998F72D for ; Tue, 30 Dec 2014 10:50:20 +0100 (CET) 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 uJWv_xuNUnKP for ; Tue, 30 Dec 2014 10:50:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 30 Dec 2014 10:50:20 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 347022002C for ; Tue, 30 Dec 2014 10:50:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XSbnhdejquo9; Tue, 30 Dec 2014 10:50:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 417B420017; Tue, 30 Dec 2014 10:50:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 68775303BAEE; Tue, 30 Dec 2014 10:50:19 +0100 (CET) Date: Tue, 30 Dec 2014 10:50:18 +0100 From: Juergen Schoenwaelder To: "netmod@ietf.org" Message-ID: <20141230095018.GA92835@elstar.local> Mail-Followup-To: "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: http://mailarchive.ietf.org/arch/msg/netmod/XjC6pdSmzP1CIBpuS9X2767neNc Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 09:50:26 -0000 On Mon, Dec 29, 2014 at 09:11:08AM -0800, Andy Bierman wrote: > Hi, > > I remember this thread. > I agree we should use your typedef for "float64". > I think another typedef for "float32" would also be needed. > Two observations/comments: - Sometimes people use floating point numbers when there really is no need to use them. There really is no need to represent a drop probability using IEEE floating point numbers. There is no need to represent bandwidth using IEEE floating point numbers. This is primarily an educational problem and perhaps it deserves adding text to RFC 6087bis. - Introducing a typedef that sounds and smells like an IEEE float/double but in fact is different will cause confusion. If there really is a demonstrated need for floating point numbers, we better use something that maps easily to other programming languages and things like xpath. It would help a lot seeing a use case that convinces me that the full range of floating point numbers are needed for network management. The argument 'protocol X uses IEEE floating point numbers => YANG has to support IEEE floating point' with X in { RSVP, ... } is not by itself convincing - I think it matters how IEEE floating point numbers are used and whether the whole precision needs to be available at a network management interface. /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 Dec 30 07:15:29 2014 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 6BD461A0173 for ; Tue, 30 Dec 2014 07:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVgJFt4X37uO for ; Tue, 30 Dec 2014 07:15:24 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC41A0194 for ; Tue, 30 Dec 2014 07:15:23 -0800 (PST) Received: from localhost (unknown [195.113.220.113]) by trail.lhotka.name (Postfix) with ESMTPSA id 5399E1CC01E4; Tue, 30 Dec 2014 16:15:24 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 30 Dec 2014 16:15:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qfXDnTFiUbqOmGQmZGIR_4C7FO0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 15:15:26 -0000 Andy Bierman writes: > On Mon, Dec 29, 2014 at 7:59 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >> >>> Hi, >>> >>> Should we be doing something in YANG 1.1 to make large number math safer? >>> IMO a guideline that warns "it won't work" it not doing very much. >> >> I agree, but I don't know how to make it safer, except for removing >> decimal64, uint64 and int64 types, which is clearly unacceptable. >> >>> >>> Would a decimal56 data type be safe to convert to float64? >>> If so, should YANG have a new data type for "safe math"? >> >> The same problem affects int64 and uint64 as well: for the leaf definition >> >> leaf foo { >> type int64; >> must ". <= 1000000000000000000"; >> } >> >> the following value is accepted as valid: >> >> 1000000000000000001 >> >> (both long numbers have 19 digits). >> > > But this is int64. > If the designer picked decimal56 instead then this would > be an illegal value right? The must-expr would not even matter, > right? Well, yes, but int64 and uint64 need to be supported. > > Why would a real data model have a must-stmt that was not safe > for plain XPath (regardless of YANG usage)? What are some real > use-cases? My example may not be realistic but there are certainly use cases where such leafs could appear in equality comparisons, e.g. in some kind of uniqueness check. > > The point of the data type is to provide the designer with a number that > is safe to use in XPath. The designer would obviously have to choose this new > data type instead of one of the 64 bit data types (because an unsafe XPath > must/when expression was needed for this leaf). I think it is important the designer is aware of the issue, and chooses whatever is appropriate, e.g. uint32 or a range. IMO decimal56 looks weird. > > I am not convinced anybody wants to write "large number XPath" in must/when > expressions. This may not be an operational problem. I agree that the code > will do the wrong thing if this issue occurs. That much is clear. > It is a shortcoming of XPath 1.0 and as such it should be mentioned in the YANG spec. I don't think we can do much more. XPath 2.0 would solve this problem but it is not an option for YANG 1.1. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 30 07:46:44 2014 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 528D01A01D5 for ; Tue, 30 Dec 2014 07:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq52d16TARAP for ; Tue, 30 Dec 2014 07:46:41 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DAC1A01BA for ; Tue, 30 Dec 2014 07:46:40 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so12731827lab.0 for ; Tue, 30 Dec 2014 07:46:39 -0800 (PST) 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=5M5+zeHwBvY1+Ws2seoNPezwWASjhxxE362YtnuP3zA=; b=Fv27bChWnt8kABg7qMN649APHe8DZ0+c5s4dNzwfSKWqFXW2j/ujmn95rHE3rYCAC3 PY45VKHyLeQN6D0oG1Y98/27NqXqrQBBCTNB3N4pHZTeOf4Aas/18ED+B/fTr2kcCjAa ePK/OFbj3fAJ2ws1/+TbNcUJpK2qHgK0Y3RLRe7qSW5ksU9B5Dzi7I0dBDghCIcf10rF O+AMiksI855SYZQK6Bhn4Z33DccozXLy7ZLWhVYjHETxooRWNrPZN0/DXu7ng55RjgsG xxVf+3sM0quuvL6rFRFUkNnG4KejGpB5aVkNMTQq1WeB5EHm2UzVCTFWdzZBBGY1R17E ElwA== X-Gm-Message-State: ALoCoQl/8jqc30oFmiEFeCweVuQYgho9anq7GJYGQmoUv6bKz1JtUoHWrodbP1+82+48nzaMus08 MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr62418381lac.3.1419954399131; Tue, 30 Dec 2014 07:46:39 -0800 (PST) Received: by 10.112.77.231 with HTTP; Tue, 30 Dec 2014 07:46:39 -0800 (PST) In-Reply-To: References: Date: Tue, 30 Dec 2014 07:46:39 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U5sfy9epr539yGdzIxyzbCvqqGo Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 15:46:42 -0000 On Tue, Dec 30, 2014 at 7:15 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Mon, Dec 29, 2014 at 7:59 AM, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>> Hi, >>>> >>>> Should we be doing something in YANG 1.1 to make large number math safer? >>>> IMO a guideline that warns "it won't work" it not doing very much. >>> >>> I agree, but I don't know how to make it safer, except for removing >>> decimal64, uint64 and int64 types, which is clearly unacceptable. >>> >>>> >>>> Would a decimal56 data type be safe to convert to float64? >>>> If so, should YANG have a new data type for "safe math"? >>> >>> The same problem affects int64 and uint64 as well: for the leaf definition >>> >>> leaf foo { >>> type int64; >>> must ". <= 1000000000000000000"; >>> } >>> >>> the following value is accepted as valid: >>> >>> 1000000000000000001 >>> >>> (both long numbers have 19 digits). >>> >> >> But this is int64. >> If the designer picked decimal56 instead then this would >> be an illegal value right? The must-expr would not even matter, >> right? > > Well, yes, but int64 and uint64 need to be supported. > But they cannot be supported. That is the point of this issue. >> >> Why would a real data model have a must-stmt that was not safe >> for plain XPath (regardless of YANG usage)? What are some real >> use-cases? > > My example may not be realistic but there are certainly use cases where such > leafs could appear in equality comparisons, e.g. in some kind of uniqueness check. > >> >> The point of the data type is to provide the designer with a number that >> is safe to use in XPath. The designer would obviously have to choose this new >> data type instead of one of the 64 bit data types (because an unsafe XPath >> must/when expression was needed for this leaf). > > I think it is important the designer is aware of the issue, and chooses > whatever is appropriate, e.g. uint32 or a range. IMO decimal56 looks weird. > Forget that type. What about the float32 and float64 typedefs from David? >> >> I am not convinced anybody wants to write "large number XPath" in must/when >> expressions. This may not be an operational problem. I agree that the code >> will do the wrong thing if this issue occurs. That much is clear. >> > > It is a shortcoming of XPath 1.0 and as such it should be mentioned in > the YANG spec. I don't think we can do much more. XPath 2.0 would solve > this problem but it is not an option for YANG 1.1. > It should be mentioned, but a 1 line warning buried in 130 pages doesn't help that much. What do you say in the text? "Make sure no 64 bit leaf ever uses the most significant 8 bits". "Make sure any loss of precision results in an 'operation-failed' error". Neither seems very implementable or enforceable. > Lada > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Tue Dec 30 07:50:57 2014 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 2969E1A01D6 for ; Tue, 30 Dec 2014 07:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 2RGU2bdlN0ns for ; Tue, 30 Dec 2014 07:50:49 -0800 (PST) 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 513181A01E1 for ; Tue, 30 Dec 2014 07:50:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9EB2D740; Tue, 30 Dec 2014 16:50:47 +0100 (CET) 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 dTSwsZ9RrBZk; Tue, 30 Dec 2014 16:50:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Dec 2014 16:50:47 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0070220036; Tue, 30 Dec 2014 16:50:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Vz7X6q6eH9eu; Tue, 30 Dec 2014 16:50:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13DCB2002C; Tue, 30 Dec 2014 16:50:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5661D303BC95; Tue, 30 Dec 2014 16:50:46 +0100 (CET) Date: Tue, 30 Dec 2014 16:50:45 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141230155045.GA93386@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "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: http://mailarchive.ietf.org/arch/msg/netmod/ieCFM67b_jnPNcbl7lkSjjPj330 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 15:50:51 -0000 On Tue, Dec 30, 2014 at 07:46:39AM -0800, Andy Bierman wrote: > > It should be mentioned, but a 1 line warning buried in 130 pages doesn't > help that much. What do you say in the text? "Make sure no 64 bit leaf > ever uses the most significant 8 bits". "Make sure any loss of precision > results in an 'operation-failed' error". > > Neither seems very implementable or enforceable. > A YANG compiler that is able to parse xpath expressions can generate warnings if 64-bit leafs are used in expressions where the precision may produce unexpected results. /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 Dec 30 08:07:05 2014 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 A9BF71A0204 for ; Tue, 30 Dec 2014 08:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, 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 9pzYF4RLLS1F for ; Tue, 30 Dec 2014 08:06:59 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665021A01E1 for ; Tue, 30 Dec 2014 08:06:59 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so12688450lab.4 for ; Tue, 30 Dec 2014 08:06:54 -0800 (PST) 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=1/vgRgvpcluHbVmcK80PUT6nJd1Vplea1rBimbw4JR0=; b=U82SIYuJ0nBC1ccs0Dv0wNJv2nC72TWvaAa0go9PTXW7n7/4ecdgfn+7m2Gi7JmC27 1H3nZgETtHJ1bZfMnMjAlrCHA7IbiSYCSbQB0UOnW+yoT2JFDJnoTovjJ+E3maR/AbSs F+Nj3YwKVr4+X+YlbTkvBG38pZdtj02DYGy+4b0ef2WJLK6bUacdfhoRNXIVeMi2FtlE k588aJdAd8am3ogMpZGzF7yI9FbCHqKb4joSXcwbeOsFnjcmeF2ZRacJML9MU/0qGXop IZmG2r0J38u/aZqxTm2mBlD847/YsKx1dzb8bx46evWDvaBbKN2hVsO3Y+qMAWoLYRjs 8AUQ== X-Gm-Message-State: ALoCoQkhGxaujkm3ZruyeZ6NlpiOhxiGp56zmBmJUKqohDejEFxs7f5K0AjnMkSsEAFCgXUibg8E MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr38155445lbb.59.1419955614494; Tue, 30 Dec 2014 08:06:54 -0800 (PST) Received: by 10.112.77.231 with HTTP; Tue, 30 Dec 2014 08:06:54 -0800 (PST) In-Reply-To: <20141230095018.GA92835@elstar.local> References: <20141230095018.GA92835@elstar.local> Date: Tue, 30 Dec 2014 08:06:54 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vEkWgR4biaxOEPg0VOhW_mQaJQU Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 16:07:04 -0000 On Tue, Dec 30, 2014 at 1:50 AM, Juergen Schoenwaelder wrote: > On Mon, Dec 29, 2014 at 09:11:08AM -0800, Andy Bierman wrote: >> Hi, >> >> I remember this thread. >> I agree we should use your typedef for "float64". >> I think another typedef for "float32" would also be needed. >> > > Two observations/comments: > > - Sometimes people use floating point numbers when there really is no > need to use them. There really is no need to represent a drop > probability using IEEE floating point numbers. There is no need to > represent bandwidth using IEEE floating point numbers. This is > primarily an educational problem and perhaps it deserves adding text > to RFC 6087bis. > > - Introducing a typedef that sounds and smells like an IEEE > float/double but in fact is different will cause confusion. If there > really is a demonstrated need for floating point numbers, we better > use something that maps easily to other programming languages and > things like xpath. > I agree that we are ignoring a very important fact -- NETCONF and RESTCONF do not use binary message encoding, so it is impossible to send an IEEE float/double. It has to be re-encoded as something else. The NETMOD WG (correctly) decided that requiring the server to parse complex text expressions representing floating point numbers was a bad idea. Decimal64 strings are much easier to parse. > It would help a lot seeing a use case that convinces me that the full > range of floating point numbers are needed for network management. The > argument 'protocol X uses IEEE floating point numbers => YANG has to > support IEEE floating point' with X in { RSVP, ... } is not by itself > convincing - I think it matters how IEEE floating point numbers are > used and whether the whole precision needs to be available at a > network management interface. > I agree, except this doesn't help legacy data models that have float32 leafs. Designers need to understand the difference between the on-the-wire text encoding and internal binary representation. If somebody wants to design a typedef for a textual representation of a number that is really hard to parse, then they can do that. It would be better to design a typedef like float32 or float64 that is easy to parse and properly constrains the value set. > /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 From nobody Tue Dec 30 09:04:33 2014 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 E057D1A0373 for ; Tue, 30 Dec 2014 09:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.866 X-Spam-Level: ** X-Spam-Status: No, score=2.866 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, 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 f4BGAegCpAmU for ; Tue, 30 Dec 2014 09:04:26 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id ED7E71A0371 for ; Tue, 30 Dec 2014 09:04:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rYTtu1xQLI+n5fyaYVCh86bT8GEPiFdNQ5MaNTJ7Juxs6i/YYKEm97z5CgAOuDYX; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y60DY-00022w-MZ for netmod@ietf.org; Tue, 30 Dec 2014 12:04:24 -0500 Received: from 76.254.49.235 by webmail.earthlink.net with HTTP; Tue, 30 Dec 2014 12:04:24 -0500 Message-ID: <32586885.1419959064708.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 30 Dec 2014 09:04:24 -0800 (GMT-08:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f80a6292664af9dfd2bb70a33898c4c3c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/huIaqc6n3rK4e2JqbDQZdLkJMzk Subject: Re: [netmod] Y59: what about decimal56 data type? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 17:04:31 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Dec 30, 2014 1:50 AM >To: "netmod@ietf.org" >Subject: Re: [netmod] Y59: what about decimal56 data type? ... >- Sometimes people use floating point numbers when there really is no > need to use them. There really is no need to represent a drop > probability using IEEE floating point numbers. There is no need to > represent bandwidth using IEEE floating point numbers. This is > primarily an educational problem and perhaps it deserves adding text > to RFC 6087bis. Yes. This is part of the motivation for all the "applicability" language in RFC 6340. >- Introducing a typedef that sounds and smells like an IEEE > float/double but in fact is different will cause confusion. If there > really is a demonstrated need for floating point numbers, we better > use something that maps easily to other programming languages and > things like xpath. Yes. Also, it would be good to be clear on precisely which IEEE 754 type(s) were to be supported; the (relatively new) decimal64 and decimal128 types have the advantage of being easily mappable to string representations without a lot of worry about fuzz, but probably enjoy far less hardware and software support than, say, binary64. >It would help a lot seeing a use case that convinces me that the full >range of floating point numbers are needed for network management. The >argument 'protocol X uses IEEE floating point numbers => YANG has to >support IEEE floating point' with X in { RSVP, ... } is not by itself >convincing - I think it matters how IEEE floating point numbers are >used and whether the whole precision needs to be available at a >network management interface. I think one might encounter them in performance statistics, where they'd typically end up being configured only for setting thresholds defined in terms of those statistics. Experience with RFC 6340 suggests that while the use cases may exist, the situations where floating point is the best solution are relatively rare. To me that suggests that if this group is going to add floating support, the less divergence from IEEE 754 (pick a flavor) the better. Reinventing the wheel for corner cases makes little sense. Randy From nobody Tue Dec 30 10:04:14 2014 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 250841A0273 for ; Tue, 30 Dec 2014 10:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 gxXkzELGb3-H for ; Tue, 30 Dec 2014 10:04:11 -0800 (PST) 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 760D91A1A14 for ; Tue, 30 Dec 2014 10:04:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 40D1B8E4; Tue, 30 Dec 2014 19:04:09 +0100 (CET) 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 uGq23dOfWf9d; Tue, 30 Dec 2014 19:03:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Dec 2014 19:04:08 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B11322002C; Tue, 30 Dec 2014 19:04:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v4PqErESwquN; Tue, 30 Dec 2014 19:04:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4D1820017; Tue, 30 Dec 2014 19:04:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 44287303BD1A; Tue, 30 Dec 2014 19:04:08 +0100 (CET) Date: Tue, 30 Dec 2014 19:04:07 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141230180407.GA93527@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20141230095018.GA92835@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: http://mailarchive.ietf.org/arch/msg/netmod/8DPWPZ-VyYdlkMwdgLSlEXaepQI Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 18:04:12 -0000 On Tue, Dec 30, 2014 at 08:06:54AM -0800, Andy Bierman wrote: > > The NETMOD WG (correctly) decided that requiring the server to parse > complex text expressions representing floating point numbers was a bad idea. > Decimal64 strings are much easier to parse. > I do not think parsing complexity is really an issue since strtod() and friends solve that problem if you code is fine with using floating point numbers. /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 Dec 30 10:12:02 2014 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 946B81A1A17 for ; Tue, 30 Dec 2014 10:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 wxVV01zeLrwA for ; Tue, 30 Dec 2014 10:11:50 -0800 (PST) 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 B86CC1A00FD for ; Tue, 30 Dec 2014 10:11:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7455F903; Tue, 30 Dec 2014 19:11:49 +0100 (CET) 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 Typmw-zfi9zV; Tue, 30 Dec 2014 19:11:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Dec 2014 19:11:48 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C13FA2002C; Tue, 30 Dec 2014 19:11:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YBWFFIV7vB-1; Tue, 30 Dec 2014 19:11:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DD0E20017; Tue, 30 Dec 2014 19:11:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 632C1303BD66; Tue, 30 Dec 2014 19:11:47 +0100 (CET) Date: Tue, 30 Dec 2014 19:11:46 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20141230181145.GB93527@elstar.local> Mail-Followup-To: Randy Presuhn , "netmod@ietf.org" References: <32586885.1419959064708.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32586885.1419959064708.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6NrgboDB5593BS5levlIVG8305Q Cc: "netmod@ietf.org" Subject: Re: [netmod] Y59: what about decimal56 data type? 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, 30 Dec 2014 18:11:58 -0000 On Tue, Dec 30, 2014 at 09:04:24AM -0800, Randy Presuhn wrote: > > I think one might encounter them in performance statistics, where they'd > typically end up being configured only for setting thresholds defined in > terms of those statistics. Experience with RFC 6340 suggests that while > the use cases may exist, the situations where floating point is the best > solution are relatively rare. > The RFC 6340 definintions are used by the following IETF MIB modules: - TED-MIB Used to model bandwidth in bytes per second (tedMaxBandwidth, tedMaxReservableBandwidth, tedUnreservedBandwidthPri0, ..., tedUnreservedBandwidthPri7). - PSAMP-MIB Use for a probability (psampSampUniProbProbability). - NHDP-MIB Used for a quality value between 0 and 1 (nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality). I argue that none of them needs floating point numbers. Perhaps we do better if we define a 'bandwidth' typedef, a 'probability' typedef and a 'quality' typedef using the native types we have. Any MIB modules I am missing? /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 Dec 30 11:44:25 2014 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 DA1CF1A1B48 for ; Tue, 30 Dec 2014 11:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, 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 fAW96619wXbN for ; Tue, 30 Dec 2014 11:44:12 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 700911A1B37 for ; Tue, 30 Dec 2014 11:44:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=j+/7lZaCn3F/5Bt8Q0d+8JPtKkHh/ohFBOgArHLTUhUhG/rfwD2yhsuw+PVIgn9S; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y62iB-0006cH-HQ for netmod@ietf.org; Tue, 30 Dec 2014 14:44:11 -0500 Received: from 76.254.49.235 by webmail.earthlink.net with HTTP; Tue, 30 Dec 2014 14:44:10 -0500 Message-ID: <18435394.1419968651395.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Tue, 30 Dec 2014 11:44:10 -0800 (GMT-08:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591fd307f3200963921963958c9a673dfc2d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yeu9_66iBKkFkmWzQD2Rcgxcuj0 Subject: Re: [netmod] Y59: what about decimal56 data type? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 19:44:14 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Dec 30, 2014 10:11 AM >To: Randy Presuhn >Cc: "netmod@ietf.org" >Subject: Re: [netmod] Y59: what about decimal56 data type? > >On Tue, Dec 30, 2014 at 09:04:24AM -0800, Randy Presuhn wrote: >> >> I think one might encounter them in performance statistics, where they'd >> typically end up being configured only for setting thresholds defined in >> terms of those statistics. Experience with RFC 6340 suggests that while >> the use cases may exist, the situations where floating point is the best >> solution are relatively rare. >> > >The RFC 6340 definintions are used by the following IETF MIB modules: > >- TED-MIB > > Used to model bandwidth in bytes per second (tedMaxBandwidth, > tedMaxReservableBandwidth, tedUnreservedBandwidthPri0, ..., > tedUnreservedBandwidthPri7). Definitely a questionable use. Unsigned32 doesn't have quite enough dynamic range, so some sort of hack would be needed, but float just seems wrong to me. >- PSAMP-MIB > > Use for a probability (psampSampUniProbProbability). This seems fairly legitimate, but my choice would have been a scaled integer rather than float, unless the near-universal underlying implementation technology is IEEE float. >- NHDP-MIB > > Used for a quality value between 0 and 1 (nhdpHystAcceptQuality, > nhdpHystRejectQuality, nhdpInitialQuality). Although my intuition would again be to go with a scaled integer for this, I'd be willing to be persuaded if the implementations consistently used float internally. >I argue that none of them needs floating point numbers. Agreed, none of these specific cases seems to meet the requirements for *both* dynamic range and precision that would justify using float. Randy