From mbj@tail-f.com Mon Jan 4 14:11:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443553A679C for ; Mon, 4 Jan 2010 14:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvm1Pxq7JGo6 for ; Mon, 4 Jan 2010 14:11:11 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 701723A681F for ; Mon, 4 Jan 2010 14:11:08 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id DEE8276C676; Mon, 4 Jan 2010 23:11:05 +0100 (CET) Date: Mon, 04 Jan 2010 23:10:28 +0100 (CET) Message-Id: <20100104.231028.60916811.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: glen@amsl.com Subject: [netmod] test 3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 22:11:12 -0000 Another test of ML... /martin From mbj@tail-f.com Mon Jan 4 14:23:47 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100F63A69F2 for ; Mon, 4 Jan 2010 14:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ9Wv8rEDbAk for ; Mon, 4 Jan 2010 14:23:46 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1C1963A683C for ; Mon, 4 Jan 2010 14:23:45 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9381176C676 for ; Mon, 4 Jan 2010 23:23:44 +0100 (CET) Date: Mon, 04 Jan 2010 23:23:07 +0100 (CET) Message-Id: <20100104.232307.111773010.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20100104.231028.60916811.mbj@tail-f.com> References: <20100104.231028.60916811.mbj@tail-f.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] test 3 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 22:23:47 -0000 Hi, It seems the list is working again. If you sent any messages to the list this year, you need to resend them. /martin Martin Bjorklund wrote: > Another test of ML... > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Tue Jan 5 01:07:50 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42633A67E7 for ; Tue, 5 Jan 2010 01:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkOBRNG8mwcd for ; Tue, 5 Jan 2010 01:07:49 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 017AD3A6848 for ; Tue, 5 Jan 2010 01:07:48 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 86D50D800C0 for ; Tue, 5 Jan 2010 10:07:45 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 05 Jan 2010 10:07:44 +0100 Message-ID: <1262682464.5559.0.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 09:07:50 -0000 Hi, here is my review of draft-ietf-netmod-yang-09: Overall, despite its length and complexity, the draft remains quite readable and comprehensible. Fixed typos and suggestions for (hopefully uncontroversial) formulation improvements are in this diff file: http://staff.cesnet.cz/~lhotka/NETMOD/draft-ietf-netmod-yang-09.diff Other comments follow: 1. My main remaining concern is the possible impact of the "when" statement. This was discussed in a separate thread and some changes may already be pending, but I think it is necessary to make sure that the rules governing whether a given data node is mandatory or not are unaffected by "when" (or "must"). Also, the first bullet in sec. 7.19.5 says: o If the "when" statement is a child of an "augment" statement, then the context node is the augment's target node in the data tree, if the target node is a data node. Otherwise, the context node is the closest ancestor node to the target node which is also a data node. and then later in the same section: The XPath expression MUST NOT include any references to the context node or any descendants of the context node. However, these rules are violated by the example in sec. 4.2.8: The context node is "user" (the target node of "augment") but the XPath expression refers to "class" which is a descendant of "user". The same problem will probably also happen for "when" under "uses" but this case is not mentioned in any of the bullets of sec. 7.19.5. 2. In several places, the text about (XML) namespaces and prefixes should be put more in line with the W3C recommendation (its 3rd edition became available recently). In particular: - sec. 5.3 OLD All YANG definitions are specified within a module that is bound to a particular XML Namespace [XML-NAMES], which is a globally unique URI [RFC3986]. A NETCONF client or server uses the namespace during XML encoding of data. NEW Names of most objects that are defined by a YANG module belong to an XML namespace [XML-NAMES] defined by the module's "namespace" statement (see Section 7.1.3). - sec. 5.3.1: OLD This namespace is "urn:ietf:params:xml:ns:yang:1". NEW The name of this namespace is "urn:ietf:params:xml:ns:yang:1". - sec. 7.1.4 OLD The "prefix" statement is used to define the prefix associated with the module and its namespace. The "prefix" statement's argument is the prefix string which is used as a prefix to access a module. The prefix string MAY be used to refer to definitions contained in the module, e.g., "if:ifName". A prefix follows the same rules as an identifier (see Section 6.2). When used inside the "module" statement, the "prefix" statement defines the prefix to be used when this module is imported. To improve readability of the NETCONF XML, a NETCONF client or server which generates XML or XPath that use prefixes, the prefix defined by a module SHOULD be used, unless there is a conflict. NEW The "prefix" statement is used to define the namespace prefix [XML-NAMES] that is bound to the namespace URI of a module. A prefix follows the same rules as an identifier (see Section 6.2). When used inside the "module" statement, the "prefix" statement defines the prefix to be used when this module is imported. To improve readability of the NETCONF XML, a NETCONF client or server which generates XML or XPath that use prefixes, SHOULD use the prefix defined by a module, unless there is a conflict. The prefix MAY be used to refer to definitions contained in the module, e.g., "if:ifName". - sec. 7.5.7, and similarly in sec. 7.6.6, 7.7.6, 7.8.5 and 7.10.2 OLD A container node is encoded as an XML element. The element's name is the container's identifier, and its XML namespace is the module's XML namespace. NEW A container node is encoded as an XML element. The element's local name is the container's identifier, and its namespace name is the module's XML namespace defined by the "namespace" statement. - sec. 7.2.2 OLD The mandatory "prefix" substatement assigns a prefix for the module to which the submodule belongs. All definitions in the local submodule and any included submodules can be accessed by using the prefix. NEW The mandatory "prefix" substatement binds a prefix to the namespace name of the module to which the submodule belongs. The binding is scoped to the submodule where it appears. All names defined in the local submodule and any included submodules MAY be qualified by using the prefix. 3. The normalization of XML attributes may affect not only arguments in YIN but also the values of the "value" attribute in sec. 7.7.7. For example, a leaf-list item containing a tab character ("\t") cannot be addressed using the "value" attribute. 4. Sec. 7.5.3 says: Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Section 7.6 and Section 7.7), any XPath comparisons are done on the canonical value. Does it mean that in the following model the "must" constraint can never be true? must "foo=bar"; leaf foo { type uint8; } leaf bar { type decimal64 { fraction-digits 1; } } This would be a deviation from XPath which compares all numbers as floats. 5. The term "complex type" is used in sec. 4.1 and 4.2.6. I think this term should be explained in the Terminology section or avoided. 6. The term "list key" should be included in Terminology. 7. Sec. 5.1.2 should also say that the order of top-level data nodes is arbitrary (as it is in containers). 8. Sec. 4.1 should explicitly mention the deliberate limitations of YANG - inability to model XML attributes and recursive structures. 9. Sec. 5.1 says that the names of standard modules and submodules MUST be unique. It should also mention there is an IANA registry for these. 10. Maybe the server should also explicitly advertize that it uses YANG? For one thing, this would inform the client that the other capabilities are to be interpreted according to sec. 5.6.4. 11. Sec. 7.1.6 says: "When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule." Does this mean the same rules as for "import" (the bullet list in sec. 7.1.5)? 12. Sec. 7.8.5: if list key(s) inside "rpc" are defined after a non-key sibling, which rule takes precedence? Do the keys still have to come before all other siblings? 13. Sec. 7.12: OLD The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module. NEW The identifiers defined or unqualified names used in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module. 14. Sec 8.1: OLD o If the constraint is defined on state data, it MUST be true in a reply to the command. NEW o If the constraint is defined on state data, it MUST be true in a reply to the command with no filter. 15. Sec. 4.2.9: OLD YANG allows the definition of NETCONF RPCs. NEW YANG allows to define the schema (signature) of NETCONF RPCs. Happy New Year! Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Jan 5 04:27:47 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC05C3A68BF for ; Tue, 5 Jan 2010 04:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr05eDOjb0mn for ; Tue, 5 Jan 2010 04:27:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D83D33A6850 for ; Tue, 5 Jan 2010 04:27:45 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8611EC001A for ; Tue, 5 Jan 2010 13:27:44 +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 wcCq+pbDyn+r; Tue, 5 Jan 2010 13:27:41 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 656F1C0004; Tue, 5 Jan 2010 13:27:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3C7BAFADBE1; Tue, 5 Jan 2010 13:27:38 +0100 (CET) Date: Tue, 5 Jan 2010 13:27:37 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20100105122737.GA34963@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.5.20 (2009-06-14) Subject: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2010 12:27:48 -0000 Hi, here is my WG last call review of draft-ietf-netmod-yang-09.txt. I am a few hours past the deadline - I apologize and hope the chairs and the WG find my review still useful. Overall, I found the document to be in a pretty good shape. Martin has done an excellent job in editing this memo. I have read the whole document, skipping the ABNF section though. Below are my comments, some are more substantial than others, some are probably just nice to have edits and I leave it to the discretion of the editor to address them or not. The comments come in no particular order. * JS-01: In the terminology section, I think it would help if the text would spell out 'data node' or 'schema node' where it currently just says 'node' since data node and schema node are defined terms and node is not defined and also more ambiguous. This affects multiple * JS-02: OLD: o conformance: A measure of how accurately a device follows the model. NEW o conformance: A measure of how accurately a device implements a data model. * JS-03: RPC vs. method vs. RPC method vs. operation: All these terms seem to mean the same and I would prefer to have less of these terms around. My preference would be to eliminate the usage of "method" or "RPC method" in favour of "operation" throughout the YANG spec. Personally, I would even go as far as eliminating RPC in most cases in the text. * JS-04: The third sentence of the following text is ambiguous: A list defines a sequence of list entries. Each entry is like a structure or a record instance, and is uniquely identified by the values of its key leafs. A list can define multiple keys and may contain any number of child nodes of any type (including leafs, lists, containers etc.). I think it should be "A list can define multiple key leafs ...". There is only one key but the key may be made up of multiple key leafs. Perhaps we need a definition of the terms "key" and "key leaf". * JS-05: I do not understand the column "Type" in the table on page 20 nor do I see that it is needed since the "Description" column is sufficient. I suggest to get rid of the "Type" column. * JS-06: OLD using the "grouping" statement. "grouping" defines a set of nodes NEW using the "grouping" statement. A "grouping" defines a set of nodes * JS-07: The separator of the revision-data in the file name (section 5.2) should change, see also the mailing list discussion. * JS-08: OLD reasons. Many errors and warnings that cannot be detected during NEW reasons. Errors and warnings that cannot be detected during * JS-09: There are multiple places where the ID talks about RFC streams. Shall we add a reference to RFC 4844 in those places? * JS-10: OLD and semantics behind the modeled data. The strength of YANG lies in the strength of this contract and the mindless devotion with which implementers follow it. NEW and semantics behind the modeled data. The strength of YANG lies in the strength of this contract. * JS-11: OLD: In many models, the modeler will allow sections of the model to be conditional, based on the device. NEW In many models, the modeler will allow sections of the model to be conditional. * JS-12: I fail to understand the purpose of section 5.7. This either needs to be rewritten or it should be removed. Here is the section: 5.7. Data Store Modification Data models may allow the server to alter the configuration data store. A formal mechanism for specifying the circumstances where these changes are allowed is out of scope for this specification. * JS-13: Quoting: The following sections describe all of the YANG core statements. This raises the question what are core statements and what are non-core statements. And given the organization of the document, type restrictions (defined in section 9) suddenly are not YANG core statements anymore. I believe the wording "core statements" creates more trouble than it is adding value and I thus prefer to avoid using this term. If the term, however, is considered essential, define it properly in the terminology section. * JS-14: Quoting: Note that even a statement which does not have any substatements defined in core YANG can have vendor-specific extensions as substatements. For example, the "description" statement does not have any substatements defined in core YANG, but the following is legal: This now talks about core YANG. Similar to JS-13, I believe we are better served to avoid this terminology. * JS-15: OLD the module, including the initial revision. A series of revisions NEW the module, including the initial revision. A series of revision * JS-16: OLD The "container" statement is used to define an interior node in the schema tree. NEW The "container" statement is used to define an interior data node in the schema tree. * JS-17: It seems the examples are pretty much chosen randomly. We have examples related to DNS resolvers, interfaces, ssh services, users, sonet, gps, and rock-the-house (perhaps even stuff I do not recall). Perhaps we can replace some of the more esoteric examples with more down to earth stuff easily understood by most readers. * JS-18: The examples come with varying level of completeness. I would prefer to make several examples more complete. A good example is section 9.2.5 and 9.4.5. * JS-19: This text is somewhat unclear: When a datastore is validated, all "must" constraints are conceptually evaluated once for each corresponding instance in the data tree What is a 'corresponding instance'? I guess I know what the intent is behind the text but I see why someone new might get confused. Perhaps this is what was intended: When a datastore is validated, all "must" constraints are conceptually evaluated for each data node in the data tree matching a schema node holding a "must" statement. * JS-20: There are some "elements of procedure" for the NETCONF operation and it seems they over simplify things. An example is 7.6.7: If the operation is "merge", the node is created if it does not exist, and its value is set to the value found in the XML RPC data. If the operation is "replace", the node is created if it does not exist, and its value is set to the value found in the XML RPC data. If the operation is "create" the node is created if it does not exist. I assume the value is assigned in a create as well. This means, the text for all three (merge, replace, create) then is the same but the NETCONF processing is not since the create fails if the node exists. I think we serve the reader by spelling out this in more detail. And is it really true that "merge" and "replace" are interchangeable or does "replace" require that the data mode exists? Note that this comment affects multiple places in the document. * JS-21: A usage examples that "creates a leaf" by using a "merge" may be confusing since a "merge" is not the same as a "create". (This affects section 7.6.8. and 7.7.8, perhaps other examples as well.) * JS-22: OLD Where the "leaf" statement is used to define a simple scalar variable of a particular type, the "leaf-list" statement is used to define an array of a particular type. NEW Where the "leaf" statement is used to define a simple scalar variable of a particular type, the "leaf-list" statement is used to define an ordered set of values of a particular type. The word "array" may be potentially confusing and is never used elsewhere in the document. * JS-23: The ordered-by statement takes as argument "user" or "system". The text in section 7.7.1 talks about user and the device. NETCONF itself has clients and servers. There might be meaning behind the decision of using all these different terms. But then the terminology section does not help with understanding the differences. Perhaps this really should have been 'ordered-by device'? Or declare that device and system are the same? * JS-24: This text perhaps needs some revision: A leaf-list node is encoded as a series of XML elements. Each element's name is the leaf-list's identifier, and its XML namespace is the module's XML namespace. The value of the leaf-list node is encoded to XML according to the type, and sent as character data in the element. The point here is that the schema tree leaf-list node leads to multiple data tree nodes. If we only talk about "node", the text becomes somewhat confusing I think. * JS-25: The insert behaviour is not clear to me. Suppose I have this slight variation of what is in 7.7.8: blowfish-cbc aaa Where does aaa go? Do the yang:insert and yang:value attributes have impact of the subsequent create? * JS-26: The move feature defined by way of example in section 7.8.7. probably requires some mentioning in the section 7.8.6. as well. It came to me as a surprise after having read 7.8.6. * JS-27: OLD the subelements are be encoded in any order. NEW the subelements are encoded in any order. * JS-28: This might be wrong: The grouping statement is not a data definition statement and, as such, does not define any nodes in the schema tree. Perhaps you meant the data tree and not the schema tree. * JS-29: OLD with the "refine" statement. The argument is a a string which NEW with the "refine" statement. The argument is a string which * JS-30: If a "config" statement is present for any node in the output tree, it is ignored. What is being ignored, the config statement of the node? * JS-31: What is the rationale behind this: If a container in the notification tree has a "presence" statement, the container need not be present in a NETCONF notification. * JS-32: If a "config" statement is present for any node in the notification tree, it is ignored. Again, it is unclear what is ignored (the config statement of the node). * JS-33: I suggest to replace the very abstract even notification with something more down to earth. This is pretty much the high-level opaque stuff we prefer not to see in YANG data models. (At least this is my opinion. ;-) * JS-34: OLD name is created by combining the the prefix of the module in which NEW name is created by combining the prefix of the module in which * JS-35: OLD The deviation statement defines a hierarchy of the module which the NEW The deviation statement defines a hierarchy of a module which the * JS-36: OLD identifies the node in the schema tree where a deviation from the NEW identifies the node in the schema tree where a deviation from a * JS-37: OLD the standard. This means that deviations MUST never be part of a NEW a standard. This means that deviations MUST never be part of a * JS-38: OLD Instead, YANG allows devices to document portions of the base module NEW Instead, YANG allows devices to document portions of a base module * JS-39: OLD properties to delete are identified by substatement to "delete". The NEW properties to delete are identified by a substatement of the "delete" statement. The * JS-40: Section 9.4 contains this: // any Unicode character, excluding the surrogate blocks, // FFFE, and FFFF. string = *char char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / %x10000-10FFFF It is unclear what this is. Looks like ABNF but then the comment character would be wrong. * JS-41: as defined in [XSD-TYPES]. It is used to restrict the built-in type "string", or types derived from "string", to values that completely matches the pattern. Not sure what "completely" adds here. The pattern matches or it does not - I think there is no notion of a partial match. * JS-42: OLD restricted, based on the rules defined in Section 9 chapter. NEW restricted, based on the rules defined in Section 9. * JS-43: Section 11 says: A YANG module can be specified in an alternative XML-based syntax called YIN. This section describes symmetric mapping rules between the two formats. I believe we need to separate the concept of a YANG module from that of a YIN module. I would prefer this instead: A YANG module can be translated into an alternative XML-based syntax called YIN. The translated module is called a YIN module. This section describes symmetric mapping rules between the two formats. This makes it clear that a YANG parser is parsing YANG modules and a YIN parser is parsing YIN modules. * JS-44: I suggest to use this YIN URI "urn:ietf:params:xml:ns:yin:1" instead of "urn:ietf:params:xml:ns:yang:yin:1" since there is little value of nesting this. But I do not care strongly about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jan 5 07:48:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D4128C137 for ; Tue, 5 Jan 2010 07:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgwWSKwI-des for ; Tue, 5 Jan 2010 07:48:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 392FF28C0FF for ; Tue, 5 Jan 2010 07:48:28 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E4CA676C677; Tue, 5 Jan 2010 16:48:25 +0100 (CET) Date: Tue, 05 Jan 2010 16:48:25 +0100 (CET) Message-Id: <20100105.164825.224628419.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1262682464.5559.0.camel@missotis> References: <1262682464.5559.0.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 15:48:33 -0000 Hi Ladislav, Thank you for the detailed review! Ladislav Lhotka wrote: > Hi, > > here is my review of draft-ietf-netmod-yang-09: > > Overall, despite its length and complexity, the draft remains quite > readable and comprehensible. > > Fixed typos and suggestions for (hopefully uncontroversial) formulation > improvements are in this diff file: > > http://staff.cesnet.cz/~lhotka/NETMOD/draft-ietf-netmod-yang-09.diff All applied. > Other comments follow: > > 1. My main remaining concern is the possible impact of the "when" > statement. This was discussed in a separate thread and some changes > may already be pending, but I think it is necessary to make sure > that the rules governing whether a given data node is mandatory or > not are unaffected by "when" (or "must"). My interpretation of that discussion is that there is no consensus to change the current behavior. > Also, the first bullet in sec. 7.19.5 says: > > o If the "when" statement is a child of an "augment" statement, then > the context node is the augment's target node in the data tree, if > the target node is a data node. Otherwise, the context node is > the closest ancestor node to the target node which is also a data > node. > > and then later in the same section: > > The XPath expression MUST NOT include any references to the context > node or any descendants of the context node. > > However, these rules are violated by the example in sec. 4.2.8: The > context node is "user" (the target node of "augment") but the XPath > expression refers to "class" which is a descendant of "user". I suggest: OLD: The XPath expression MUST NOT include any references to the context node or any descendants of the context node. NEW: The XPath expression MUST NOT include any references to nodes defined in the "when" statement's parent statement. > The same problem will probably also happen for "when" under "uses" > but this case is not mentioned in any of the bullets of > sec. 7.19.5. I suggest: OLD: o If the "when" statement is a child of a "choice" or "case" statement, then the context node is the closest ancestor node to the "choice" or "case" node which is also a data node. NEW: o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice" or "case" node which is also a data node. > 2. In several places, the text about (XML) namespaces and prefixes > should be put more in line with the W3C recommendation (its 3rd > edition became available recently). In particular: > > - sec. 5.3 > OLD > All YANG definitions are specified within a module that is bound > to a particular XML Namespace [XML-NAMES], which is a globally > unique URI [RFC3986]. A NETCONF client or server uses the > namespace during XML encoding of data. > NEW > Names of most objects that are defined by a YANG module belong to > an XML namespace [XML-NAMES] defined by the module's "namespace" > statement (see Section 7.1.3). I don't like the phrase "most objects" - it raises the question which objects we mean. > - sec. 5.3.1: > OLD > This namespace is "urn:ietf:params:xml:ns:yang:1". > NEW > The name of this namespace is "urn:ietf:params:xml:ns:yang: Fixed. > - sec. 7.1.4 > OLD > The "prefix" statement is used to define the prefix associated > with the module and its namespace. The "prefix" statement's > argument is the prefix string which is used as a prefix to access > a module. The prefix string MAY be used to refer to definitions > contained in the module, e.g., "if:ifName". A prefix follows the > same rules as an identifier (see Section 6.2). > > When used inside the "module" statement, the "prefix" statement > defines the prefix to be used when this module is imported. To > improve readability of the NETCONF XML, a NETCONF client or > server which generates XML or XPath that use prefixes, the prefix > defined by a module SHOULD be used, unless there is a conflict. > > NEW > The "prefix" statement is used to define the namespace prefix > [XML-NAMES] that is bound to the namespace URI of a module. A > prefix follows the same rules as an identifier (see Section 6.2). > > When used inside the "module" statement, the "prefix" statement > defines the prefix to be used when this module is imported. To > improve readability of the NETCONF XML, a NETCONF client or > server which generates XML or XPath that use prefixes, SHOULD use > the prefix defined by a module, unless there is a conflict. The > prefix MAY be used to refer to definitions contained in > the module, e.g., "if:ifName". I don't think the suggested text is an improvement. As the original text says, the prefix maps to both the module (e.g. "inet:ipv4-address") and XML namespace (e.g. in must XPath expressions). > - sec. 7.2.2 > OLD > The mandatory "prefix" substatement assigns a prefix for the > module to which the submodule belongs. All definitions in the > local submodule and any included submodules can be accessed by > using the prefix. > NEW > The mandatory "prefix" substatement binds a prefix to the > namespace name of the module to which the submodule belongs. The > binding is scoped to the submodule where it appears. All > names defined in the local submodule and any included submodules > MAY be qualified by using the prefix. Same comment here - the prefix is used to access the module, not only namespace. > - sec. 7.5.7, and similarly in sec. 7.6.6, 7.7.6, 7.8.5 and 7.10.2 > OLD > A container node is encoded as an XML element. The element's > name is the container's identifier, and its XML namespace is the > module's XML namespace. > NEW > A container node is encoded as an XML element. The element's > local name is the container's identifier, and its namespace name > is the module's XML namespace defined by the "namespace" > statement. Ok. I suggest this (adding a ref): A container node is encoded as an XML element. The element's local name is the container's identifier, and its namespace name is the module's XML namespace (see Section 7.1.3). > 3. The normalization of XML attributes may affect not only arguments > in YIN but also the values of the "value" attribute in sec. 7.7.7. > For example, a leaf-list item containing a tab character ("\t") > cannot be addressed using the "value" attribute. You are right. The only way to change such a leaf-list is to do a replace of all entries. > 4. Sec. 7.5.3 says: > > Note that since all leaf values in the data tree are conceptually > stored in their canonical form (see Section 7.6 and Section 7.7), any > XPath comparisons are done on the canonical value. > > Does it mean that in the following model the "must" constraint can > never be true? > > must "foo=bar"; > leaf foo { > type uint8; > } > leaf bar { > type decimal64 { > fraction-digits 1; > } > } > > This would be a deviation from XPath which compares all numbers as > floats. No, YANG does not deviate from XPath. This is mentioned in the guidelines document as well (that you must be careful...) We had a long email discussion about this a while back. > 5. The term "complex type" is used in sec. 4.1 and 4.2.6. I think this > term should be explained in the Terminology section or avoided. In 4.1: OLD: YANG permits the definition of complex types using reusable grouping of nodes. NEW: YANG permits the definition of reusable grouping of nodes. I think the usage of this term in 4.2.6 is ok: Groups of nodes can be assembled into the equivalent of complex types using the "grouping" statement. > 6. The term "list key" should be included in Terminology. The document doesn't use the term "list key", so I don't think we need to define it. > 7. Sec. 5.1.2 should also say that the order of top-level data nodes > is arbitrary (as it is in containers). OLD: NETCONF is capable of carrying any XML content as the payload in the and elements. The top-level nodes of YANG modules are encoded as child elements within these elements. NEW: NETCONF is capable of carrying any XML content as the payload in the and elements. The top-level nodes of YANG modules are encoded as child elements, in any order, within these elements. > 8. Sec. 4.1 should explicitly mention the deliberate limitations of > YANG - inability to model XML attributes and recursive structures. It already says: limiting the problem space to allow expression of NETCONF data models, not arbitrary XML documents which I think is sufficient. > 9. Sec. 5.1 says that the names of standard modules and submodules > MUST be unique. It should also mention there is an IANA registry > for these. The registry is mentioned in 7.1 and 7.2. > 10. Maybe the server should also explicitly advertize that it uses > YANG? For one thing, this would inform the client that the other > capabilities are to be interpreted according to sec. 5.6.4. I don't think this is necessary - if the server advertises a URI which the client understands, the client can check if the URI represents a YANG module or not. > 11. Sec. 7.1.6 says: "When a submodule includes another submodule, the > target submodule's definitions are made available to the current > submodule." Does this mean the same rules as for "import" (the > bullet list in sec. 7.1.5)? Yes. > 12. Sec. 7.8.5: if list key(s) inside "rpc" are defined after a > non-key sibling, which rule takes precedence? Do the keys still > have to come before all other siblings? Yes. I think the text is clear: The list's key nodes are encoded as subelements to the list's identifier element, in the same order as they are defined within the key statement. The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the list statement. Would s/the subelements/these subelements/ make it more clear? > 13. Sec. 7.12: > OLD > The identifiers defined in the grouping are not bound to a namespace > until the contents of the grouping are added to the schema tree via a > "uses" statement that does not appear inside a "grouping" statement, > at which point they are bound to the namespace of the current module. > NEW > The identifiers defined or unqualified names used in the grouping > are not bound to a namespace until the contents of the grouping are > added to the schema tree via a "uses" statement that does not > appear inside a "grouping" statement, at which point they are bound > to the namespace of the current module. Fixed. > 14. Sec 8.1: > OLD > o If the constraint is defined on state data, it MUST be true in a > reply to the command. > NEW > o If the constraint is defined on state data, it MUST be true in a > reply to the command with no filter. Fixed. > 15. Sec. 4.2.9: > OLD > YANG allows the definition of NETCONF RPCs. > NEW > YANG allows to define the schema (signature) of NETCONF RPCs. I think the current text is ok. /martin From j.schoenwaelder@jacobs-university.de Tue Jan 5 08:48:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C9F3A68EC for ; Tue, 5 Jan 2010 08:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1mOsAfOVk3H for ; Tue, 5 Jan 2010 08:48:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D637C3A67E3 for ; Tue, 5 Jan 2010 08:48:29 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 286E0C0003; Tue, 5 Jan 2010 17:48:28 +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 Ep9y2HqEETEm; Tue, 5 Jan 2010 17:48:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3523AC001F; Tue, 5 Jan 2010 17:48:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1BCCFFAE1DF; Tue, 5 Jan 2010 17:48:23 +0100 (CET) Date: Tue, 5 Jan 2010 17:48:23 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100105164823.GA35286@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netmod@ietf.org" References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100105.164825.224628419.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2010 16:48:30 -0000 On Tue, Jan 05, 2010 at 04:48:25PM +0100, Martin Bjorklund wrote: > > - sec. 5.3.1: > > OLD > > This namespace is "urn:ietf:params:xml:ns:yang:1". > > NEW > > The name of this namespace is "urn:ietf:params:xml:ns:yang: > > Fixed. Are you sure? I also first thought this is a typo but later I believed the :1 was a version number, similar to the :1.0 we have for the NETCONF URI (somehow we don't have a minor version in mind). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jan 5 10:28:47 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2F528C18C for ; Tue, 5 Jan 2010 10:28:47 -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_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuZiU6LaDQyO for ; Tue, 5 Jan 2010 10:28:47 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2204D28C16C for ; Tue, 5 Jan 2010 10:28:46 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6577176C677; Tue, 5 Jan 2010 19:28:44 +0100 (CET) Date: Tue, 05 Jan 2010 19:28:03 +0100 (CET) Message-Id: <20100105.192803.252138950.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100105164823.GA35286@elstar.local> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <20100105164823.GA35286@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:28:48 -0000 Juergen Schoenwaelder wrote: > On Tue, Jan 05, 2010 at 04:48:25PM +0100, Martin Bjorklund wrote: > > > > - sec. 5.3.1: > > > OLD > > > This namespace is "urn:ietf:params:xml:ns:yang:1". > > > NEW > > > The name of this namespace is "urn:ietf:params:xml:ns:yang: > > > > Fixed. > > Are you sure? Actually, Lada's original text got truncated. The correct text should be: OLD This namespace is "urn:ietf:params:xml:ns:yang:1". NEW The name of this namespace is "urn:ietf:params:xml:ns:yang:1". The URI itself is the same. > I also first thought this is a typo but later I believed > the :1 was a version number, similar to the :1.0 we have for the > NETCONF URI (somehow we don't have a minor version in mind). I hope we don't have YANG version 1, 1.1, 2, 1.2, 2.0.1 etc... /martin From mbj@tail-f.com Tue Jan 5 10:29:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272F128C1AB for ; Tue, 5 Jan 2010 10:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQx6b6IDY4Si for ; Tue, 5 Jan 2010 10:29:34 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4A54028C192 for ; Tue, 5 Jan 2010 10:29:34 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id CD41176C677; Tue, 5 Jan 2010 19:29:32 +0100 (CET) Date: Tue, 05 Jan 2010 19:28:52 +0100 (CET) Message-Id: <20100105.192852.141141230.mbj@tail-f.com> To: phil@idle.juniper.net From: Martin Bjorklund In-Reply-To: <201001051808.o05I8kEu076523@idle.juniper.net> References: <20100105.164825.224628419.mbj@tail-f.com> <201001051808.o05I8kEu076523@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:29:35 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > > The XPath expression MUST NOT include any references to nodes > > defined in the "when" statement's parent statement. > > I'm lost trying to connect this with the laissez-faire attitude > you (plural) wanted WRT typos in XPath expressions. You allow > references to nonsense, but want to restrict references to "when" > nodes? Makes no sense. > > >> 3. The normalization of XML attributes may affect not only arguments > >> in YIN but also the values of the "value" attribute in sec. 7.7.7. > >> For example, a leaf-list item containing a tab character ("\t") > >> cannot be addressed using the "value" attribute. > > > >You are right. The only way to change such a leaf-list is to do a > >replace of all entries. > > This isn't acceptable, since the application now has to notice > this condition and invoke a completely different behavior. See > my proposal in other email. Which other email? Could you send a pointer? /martin From andyb@iwl.com Tue Jan 5 11:20:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36663A683F for ; Tue, 5 Jan 2010 11:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JoWvLP5tZ5p for ; Tue, 5 Jan 2010 11:20:58 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 056E33A6778 for ; Tue, 5 Jan 2010 11:20:58 -0800 (PST) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id B227610CBE63 for ; Tue, 5 Jan 2010 14:20:56 -0500 (EST) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9353710CBDD2 for ; Tue, 5 Jan 2010 14:20:56 -0500 (EST) Message-ID: <4B439128.2070203@iwl.com> Date: Tue, 05 Jan 2010 11:21:12 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] closure on yang-09, sec 10, revision rules thread started 12/07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:20:58 -0000 Hi, IMO, it is important to state that as far as the standard is concerned, a missing revision date is considered to be the special case where there is no revision. This is consistent with the XML namespace rules (xmlns=""). Therefore, any changes to a such a YANG module are illegal changes according to sec. 10. Andy From andyb@iwl.com Tue Jan 5 11:25:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C703A6942 for ; Tue, 5 Jan 2010 11:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYkhMrEI5pph for ; Tue, 5 Jan 2010 11:25:57 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id D384B3A6778 for ; Tue, 5 Jan 2010 11:25:57 -0800 (PST) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id B4AB010CBDC4 for ; Tue, 5 Jan 2010 14:25:56 -0500 (EST) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 93FE210CBFB6 for ; Tue, 5 Jan 2010 14:25:56 -0500 (EST) Message-ID: <4B439254.9050209@iwl.com> Date: Tue, 05 Jan 2010 11:26:12 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] closure on file separator thread X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:25:58 -0000 Hi, I think there is consensus to change the file separator character from '.' to '@'. I think this aspect of YANG shows one of the many areas where NETMOD WG has learned from the mistakes of the SMIv2 WG. It seems like a minor hassle to rename every single MIB module, just to make a different MIB compiler happy. Now that YANG has import-by-revision, the minor hassle has turned into a real interoperability concern. Andy From andyb@iwl.com Tue Jan 5 11:32:51 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14BD828C184 for ; Tue, 5 Jan 2010 11:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR3dXoZZie9x for ; Tue, 5 Jan 2010 11:32:50 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 4A2F128C172 for ; Tue, 5 Jan 2010 11:32:50 -0800 (PST) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 2D4A110CBE35 for ; Tue, 5 Jan 2010 14:32:49 -0500 (EST) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0907910CBDBC for ; Tue, 5 Jan 2010 14:32:48 -0500 (EST) Message-ID: <4B4393F1.8030806@iwl.com> Date: Tue, 05 Jan 2010 11:33:05 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] closure on identifier rule change X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:32:51 -0000 Hi, I think there is WG consensus to change the identifier rules to disallow the 'xml' prefix (in any form). This change has a real impact, because 'xml' is such an obvious prefix to use, especially if one is concerned with reusing identifiers from other access methods (like CLI/SSH or SMI/SNMP). But better to start enforcing the CLR now. Andy From mbj@tail-f.com Tue Jan 5 12:26:54 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6933E3A68CB for ; Tue, 5 Jan 2010 12:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltLvUW0t5Kyz for ; Tue, 5 Jan 2010 12:26:53 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 898673A68BB for ; Tue, 5 Jan 2010 12:26:53 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 57F9876C67B; Tue, 5 Jan 2010 21:26:51 +0100 (CET) Date: Tue, 05 Jan 2010 21:26:50 +0100 (CET) Message-Id: <20100105.212650.150160921.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B439254.9050209@iwl.com> References: <4B439254.9050209@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] closure on file separator thread X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:26:54 -0000 Andy Bierman wrote: > Hi, > > I think there is consensus to change the file separator character > from '.' to '@'. Yes. Juergen had the same comment. I have fixed this for the next version. /martin From mbj@tail-f.com Tue Jan 5 12:29:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2BE3A68CB for ; Tue, 5 Jan 2010 12:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puo2eJhv66QF for ; Tue, 5 Jan 2010 12:29:54 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 85C593A6767 for ; Tue, 5 Jan 2010 12:29:54 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DDA976C67B; Tue, 5 Jan 2010 21:29:53 +0100 (CET) Date: Tue, 05 Jan 2010 21:29:52 +0100 (CET) Message-Id: <20100105.212952.135576528.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4393F1.8030806@iwl.com> References: <4B4393F1.8030806@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] closure on identifier rule change X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:29:55 -0000 Andy Bierman wrote: > Hi, > > I think there is WG consensus to change the identifier > rules to disallow the 'xml' prefix (in any form). Yes. I have made this change, currently as a comment in the grammar: ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") And the main text says: The identifier syntax is formally defined by the rule "identifier" in ^grammar^. /martin From mbj@tail-f.com Tue Jan 5 12:30:43 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18583A68BB for ; Tue, 5 Jan 2010 12:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91nwQRHhL5mI for ; Tue, 5 Jan 2010 12:30:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2780E3A6767 for ; Tue, 5 Jan 2010 12:30:43 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A5D0B76C67B; Tue, 5 Jan 2010 21:30:41 +0100 (CET) Date: Tue, 05 Jan 2010 21:30:41 +0100 (CET) Message-Id: <20100105.213041.71132649.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B439128.2070203@iwl.com> References: <4B439128.2070203@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] closure on yang-09, sec 10, revision rules thread started 12/07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:30:44 -0000 Andy Bierman wrote: > Hi, > > > IMO, it is important to state that as far as the standard > is concerned, a missing revision date is considered to > be the special case where there is no revision. > This is consistent with the XML namespace rules (xmlns=""). > > Therefore, any changes to a such a YANG module are > illegal changes according to sec. 10. I am not sure what change, if any, you are proposing. /martin From lhotka@cesnet.cz Tue Jan 5 12:49:48 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21093A684A for ; Tue, 5 Jan 2010 12:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSUjMe+Z-+cy for ; Tue, 5 Jan 2010 12:49:47 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DAF773A67F2 for ; Tue, 5 Jan 2010 12:49:46 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0A106D80096 for ; Tue, 5 Jan 2010 21:49:45 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <20100105.164825.224628419.mbj@tail-f.com> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 05 Jan 2010 21:49:43 +0100 Message-ID: <1262724583.11199.79.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:49:48 -0000 Martin Bjorklund píše v Út 05. 01. 2010 v 16:48 +0100: > > > > 1. My main remaining concern is the possible impact of the "when" > > statement. This was discussed in a separate thread and some changes > > may already be pending, but I think it is necessary to make sure > > that the rules governing whether a given data node is mandatory or > > not are unaffected by "when" (or "must"). > > My interpretation of that discussion is that there is no consensus to > change the current behavior. But I actually meant to stick strictly to the current text. It says, e.g., in sec. 7.6.5: "the leaf MUST exist", full stop, i.e., without regard to any "when" or "must". Thus having the leaf definition leaf foo { mandatory true; when "1=0"; } the leaf MUST exist (if the corresponding ancestor exists), otherwise the above condition is clearly violated. > > > Also, the first bullet in sec. 7.19.5 says: > > > > o If the "when" statement is a child of an "augment" statement, then > > the context node is the augment's target node in the data tree, if > > the target node is a data node. Otherwise, the context node is > > the closest ancestor node to the target node which is also a data > > node. > > > > and then later in the same section: > > > > The XPath expression MUST NOT include any references to the context > > node or any descendants of the context node. > > > > However, these rules are violated by the example in sec. 4.2.8: The > > context node is "user" (the target node of "augment") but the XPath > > expression refers to "class" which is a descendant of "user". > > I suggest: > > OLD: > > The XPath expression MUST NOT include any references to the context > node or any descendants of the context node. > > NEW: > > The XPath expression MUST NOT include any references to nodes > defined in the "when" statement's parent statement. But what if there are two sibling augment statements, both referring via 'when' to each other's nodes? > > > The same problem will probably also happen for "when" under "uses" > > but this case is not mentioned in any of the bullets of > > sec. 7.19.5. > > I suggest: > > OLD: > > o If the "when" statement is a child of a "choice" or "case" > statement, then the context node is the closest ancestor node to > the "choice" or "case" node which is also a data node. > > NEW: > > o If the "when" statement is a child of a "uses", "choice", or "case" > statement, then the context node is the closest ancestor node to > the "uses", "choice" or "case" node which is also a data node. > OK. > > > 2. In several places, the text about (XML) namespaces and prefixes > > should be put more in line with the W3C recommendation (its 3rd > > edition became available recently). In particular: > > > > - sec. 5.3 > > OLD > > All YANG definitions are specified within a module that is bound > > to a particular XML Namespace [XML-NAMES], which is a globally > > unique URI [RFC3986]. A NETCONF client or server uses the > > namespace during XML encoding of data. > > NEW > > Names of most objects that are defined by a YANG module belong to > > an XML namespace [XML-NAMES] defined by the module's "namespace" > > statement (see Section 7.1.3). > > I don't like the phrase "most objects" - it raises the question which > objects we mean. The old text seems to imply that all names within a module belong to the module's namespace - which is not true. ... > > - sec. 7.1.4 > > OLD > > The "prefix" statement is used to define the prefix associated > > with the module and its namespace. The "prefix" statement's > > argument is the prefix string which is used as a prefix to access > > a module. The prefix string MAY be used to refer to definitions > > contained in the module, e.g., "if:ifName". A prefix follows the > > same rules as an identifier (see Section 6.2). > > > > When used inside the "module" statement, the "prefix" statement > > defines the prefix to be used when this module is imported. To > > improve readability of the NETCONF XML, a NETCONF client or > > server which generates XML or XPath that use prefixes, the prefix > > defined by a module SHOULD be used, unless there is a conflict. > > > > NEW > > The "prefix" statement is used to define the namespace prefix > > [XML-NAMES] that is bound to the namespace URI of a module. A > > prefix follows the same rules as an identifier (see Section 6.2). > > > > When used inside the "module" statement, the "prefix" statement > > defines the prefix to be used when this module is imported. To > > improve readability of the NETCONF XML, a NETCONF client or > > server which generates XML or XPath that use prefixes, SHOULD use > > the prefix defined by a module, unless there is a conflict. The > > prefix MAY be used to refer to definitions contained in > > the module, e.g., "if:ifName". > > I don't think the suggested text is an improvement. As the original > text says, the prefix maps to both the module > (e.g. "inet:ipv4-address") and XML namespace (e.g. in must XPath > expressions). I find this "overloading" slightly confusing. ... > > - sec. 7.5.7, and similarly in sec. 7.6.6, 7.7.6, 7.8.5 and 7.10.2 > > OLD > > A container node is encoded as an XML element. The element's > > name is the container's identifier, and its XML namespace is the > > module's XML namespace. > > NEW > > A container node is encoded as an XML element. The element's > > local name is the container's identifier, and its namespace name > > is the module's XML namespace defined by the "namespace" > > statement. > > Ok. I suggest this (adding a ref): > > A container node is encoded as an XML element. The element's local > name is the container's identifier, and its namespace name is the > module's XML namespace (see Section 7.1.3). Fine. ... > > 4. Sec. 7.5.3 says: > > > > Note that since all leaf values in the data tree are conceptually > > stored in their canonical form (see Section 7.6 and Section 7.7), any > > XPath comparisons are done on the canonical value. > > > > Does it mean that in the following model the "must" constraint can > > never be true? > > > > must "foo=bar"; > > leaf foo { > > type uint8; > > } > > leaf bar { > > type decimal64 { > > fraction-digits 1; > > } > > } > > > > This would be a deviation from XPath which compares all numbers as > > floats. > > No, YANG does not deviate from XPath. This is mentioned in the > guidelines document as well (that you must be careful...) We had a > long email discussion about this a while back. So the note in sec. 7.5.3 just says that all values are "canonized" before they are used in XPath expressions, not just comparisons. For numbers it's not relevant anyway. > > > 5. The term "complex type" is used in sec. 4.1 and 4.2.6. I think this > > term should be explained in the Terminology section or avoided. > > In 4.1: > > OLD: > > YANG permits the definition of complex types using reusable grouping > of nodes. > > NEW: > > YANG permits the definition of reusable grouping of nodes. > > I think the usage of this term in 4.2.6 is ok: > > Groups of nodes can be assembled into the equivalent of complex types > using the "grouping" statement. If XSD complex types are meant here, I don't think groupings are really equivalent to them. > > > 6. The term "list key" should be included in Terminology. > > The document doesn't use the term "list key", so I don't think we need > to define it. OK, so how about "key leaf"? > > > 7. Sec. 5.1.2 should also say that the order of top-level data nodes > > is arbitrary (as it is in containers). > > OLD: > > NETCONF is capable of carrying any XML content as the payload in the > and elements. The top-level nodes of YANG modules > are encoded as child elements within these elements. > > NEW: > > NETCONF is capable of carrying any XML content as the payload in the > and elements. The top-level nodes of YANG modules > are encoded as child elements, in any order, within these elements. OK. > > > 8. Sec. 4.1 should explicitly mention the deliberate limitations of > > YANG - inability to model XML attributes and recursive structures. > > It already says: > > limiting > the problem space to allow expression of NETCONF data models, not > arbitrary XML documents I guess NETCONF doesn't forbid attributes or recursive content models, does it? > > which I think is sufficient. > > > 9. Sec. 5.1 says that the names of standard modules and submodules > > MUST be unique. It should also mention there is an IANA registry > > for these. > > The registry is mentioned in 7.1 and 7.2. Sure, but I thought it could be mentioned here, too. > > > 10. Maybe the server should also explicitly advertize that it uses > > YANG? For one thing, this would inform the client that the other > > capabilities are to be interpreted according to sec. 5.6.4. > > I don't think this is necessary - if the server advertises a URI which > the client understands, the client can check if the URI represents a > YANG module or not. How can you check this? The URI needn't point to any resource. > > > 11. Sec. 7.1.6 says: "When a submodule includes another submodule, the > > target submodule's definitions are made available to the current > > submodule." Does this mean the same rules as for "import" (the > > bullet list in sec. 7.1.5)? > > Yes. Then the text should say so, because "submodule's definitions" may mean different things. > > > 12. Sec. 7.8.5: if list key(s) inside "rpc" are defined after a > > non-key sibling, which rule takes precedence? Do the keys still > > have to come before all other siblings? > > Yes. I think the text is clear: > > The list's key nodes are encoded as subelements to the list's > identifier element, in the same order as they are defined within the > key statement. > > The rest of the list's child nodes are encoded as subelements to the > list element, after the keys. If the list defines RPC input or > output parameters, the subelements are encoded in the same order as > they are defined within the list statement. But we have two conflicting rules here: rpc my-rpc { input { list foo { key clef; leaf bar { ... } leaf clef { ... } } } ... } The rule for list keys implies the order "clef bar" but the rule for RPC implies "bar clef". > > Would s/the subelements/these subelements/ make it more clear? > ... > > > 15. Sec. 4.2.9: > > OLD > > YANG allows the definition of NETCONF RPCs. > > NEW > > YANG allows to define the schema (signature) of NETCONF RPCs. > > I think the current text is ok. > By "definition of NETCONF RPCs" I understand also the definition of their semantics, which YANG doesn't address. Lada > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Tue Jan 5 12:51:54 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63CF3A6890 for ; Tue, 5 Jan 2010 12:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AapyqtIyFKD for ; Tue, 5 Jan 2010 12:51:54 -0800 (PST) Received: from smtp115.iad.emailsrvr.com (smtp115.iad.emailsrvr.com [207.97.245.115]) by core3.amsl.com (Postfix) with ESMTP id E39413A67F2 for ; Tue, 5 Jan 2010 12:51:53 -0800 (PST) Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 7BA7C1B4055; Tue, 5 Jan 2010 15:51:52 -0500 (EST) Received: by relay31.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 33BE51B403D; Tue, 5 Jan 2010 15:51:52 -0500 (EST) Message-ID: <4B43A678.1050800@iwl.com> Date: Tue, 05 Jan 2010 12:52:08 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B439128.2070203@iwl.com> <20100105.213041.71132649.mbj@tail-f.com> In-Reply-To: <20100105.213041.71132649.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] closure on yang-09, sec 10, revision rules thread started 12/07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:51:54 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> >> IMO, it is important to state that as far as the standard >> is concerned, a missing revision date is considered to >> be the special case where there is no revision. >> This is consistent with the XML namespace rules (xmlns=""). >> >> Therefore, any changes to a such a YANG module are >> illegal changes according to sec. 10. > > I am not sure what change, if any, you are proposing. > yang-09, sec. 10, para 2: OLD: For any published change, a new "revision" statement (Section 7.1.9) SHOULD be included in front of the existing revision statements. Furthermore, any necessary changes MUST be applied to any meta data statements, including the "organization" and "contact" statements (Section 7.1.7, Section 7.1.8). NEW: For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing revision statements. ^^^^ If there are no existing revision statements, then one MUST be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ added to identify the new revision. Furthermore, any necessary ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ changes MUST be applied to any meta data statements, including the "organization" and "contact" statements (Section 7.1.7, Section 7.1.8). Note that 'published' only refers to new RFCs and new vendor module revisions. > > /martin > Andy From andyb@iwl.com Tue Jan 5 12:56:19 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F5A28C0D9 for ; Tue, 5 Jan 2010 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt4xfcftUuBr for ; Tue, 5 Jan 2010 12:56:18 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id A25933A691B for ; Tue, 5 Jan 2010 12:56:18 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 7106513D33D6; Tue, 5 Jan 2010 15:56:17 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 403C013D33A9; Tue, 5 Jan 2010 15:56:17 -0500 (EST) Message-ID: <4B43A781.7080300@iwl.com> Date: Tue, 05 Jan 2010 12:56:33 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724583.11199.79.camel@missotis> In-Reply-To: <1262724583.11199.79.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:56:19 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Út 05. 01. 2010 v 16:48 +0100: >>> 1. My main remaining concern is the possible impact of the "when" >>> statement. This was discussed in a separate thread and some changes >>> may already be pending, but I think it is necessary to make sure >>> that the rules governing whether a given data node is mandatory or >>> not are unaffected by "when" (or "must"). >> My interpretation of that discussion is that there is no consensus to >> change the current behavior. > > But I actually meant to stick strictly to the current text. It says, > e.g., in sec. 7.6.5: "the leaf MUST exist", full stop, i.e., without > regard to any "when" or "must". Thus having the leaf definition > > leaf foo { > mandatory true; > when "1=0"; > } > > the leaf MUST exist (if the corresponding ancestor exists), otherwise > the above condition is clearly violated. No -- we need to make it clear that there is a 'property precedence' defined for YANG, just like an 'operator precedence' in a programming language. The when-stmt has precedence over the mandatory-stmt and min-elements-stmt. If it is false, then the schema node does not conceptually exist. How the validation code deals with this is an implementation detail. Andy From lhotka@cesnet.cz Tue Jan 5 13:18:53 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9350F3A68A7 for ; Tue, 5 Jan 2010 13:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1DD3Pkv1OTw for ; Tue, 5 Jan 2010 13:18:52 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 4D8ED3A684A for ; Tue, 5 Jan 2010 13:18:52 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id D4C9DD800C0; Tue, 5 Jan 2010 22:18:50 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201001051758.o05HwAFI075689@idle.juniper.net> References: <201001051758.o05HwAFI075689@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 05 Jan 2010 22:18:49 +0100 Message-ID: <1262726329.11199.104.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:18:53 -0000 Phil Shafer píše v Út 05. 01. 2010 v 12:58 -0500: > > > > - sec. 5.3.1: > > OLD > > This namespace is "urn:ietf:params:xml:ns:yang:1". > > NEW > > The name of this namespace is "urn:ietf:params:xml:ns:yang:1". > > -1 to these two. I do not see any additional clarity from the changes. The URN is not the namespace. "Namespaces in XML 1.0 (Third Edition)" has this definition in sec. 2.1: "For a name N in a namespace identified by a URI I, the namespace name is I." > > > - sec. 7.1.4 > > OLD > > The "prefix" statement is used to define the prefix associated > > with the module and its namespace. The "prefix" statement's > > argument is the prefix string which is used as a prefix to access > > a module. The prefix string MAY be used to refer to definitions > > contained in the module, e.g., "if:ifName". A prefix follows the > > same rules as an identifier (see Section 6.2). > > > > When used inside the "module" statement, the "prefix" statement > > defines the prefix to be used when this module is imported. To > > improve readability of the NETCONF XML, a NETCONF client or > > server which generates XML or XPath that use prefixes, the prefix > > defined by a module SHOULD be used, unless there is a conflict. > > > > NEW > > The "prefix" statement is used to define the namespace prefix > > [XML-NAMES] that is bound to the namespace URI of a module. A > > prefix follows the same rules as an identifier (see Section 6.2). > > > > When used inside the "module" statement, the "prefix" statement > > defines the prefix to be used when this module is imported. To > > improve readability of the NETCONF XML, a NETCONF client or > > server which generates XML or XPath that use prefixes, SHOULD use > > the prefix defined by a module, unless there is a conflict. The > > prefix MAY be used to refer to definitions contained in > > the module, e.g., "if:ifName". > > -1 also. "namespace prefix" is not a better term than "prefix" here. > I think the intent is clear from the current text. The term "namespace > name" just sounds silly. It is a terminus technicus used in the W3C recommendation cited above. > > >3. The normalization of XML attributes may affect not only arguments > > in YIN but also the values of the "value" attribute in sec. 7.7.7. > > For example, a leaf-list item containing a tab character ("\t") > > cannot be addressed using the "value" attribute. > > This is yet another case where one must ask "what were they thinking". > The normalization of "value" and "key" means we need a new mechanism, > since we cannot make tabs illegal in identifiers. It's not only about identifiers, the "yang:value" attribute contains leaf-list values. > > The simplest change would be to have a "yang" namespace with "insert", > "key", and "value" as elements of that namespace. Then we'd require > that these elements appear first under the parent element. This would > allow a simpler solution for multiple keys: > > > before > > 10.1.2.0/24 > or-longer > > 10.1.1.0/24 > exact > > > (assuming "list prefix" is "key 'name type'"). Where would the edit-config "operation" attribute be? > > Is this change acceptable? > ... > >10. Maybe the server should also explicitly advertize that it uses > > YANG? For one thing, this would inform the client that the other > > capabilities are to be interpreted according to sec. 5.6.4. > > Avertising a YANG based data model is sufficient, since there is > nothing YANG-ish to support outside of a specific data model. In > fact, I could suppport 3 YANG models and 3 non-YANG models in the > same box. No YANG-specific operations can be done on the non-YANG > models. > > >12. Sec. 7.8.5: if list key(s) inside "rpc" are defined after a > > non-key sibling, which rule takes precedence? Do the keys still > > have to come before all other siblings? > > I don't follow the question. Please expand on it a bit. I gave an example in my previous reply to Martin's message. > > >13. Sec. 7.12: > > OLD > > The identifiers defined in the grouping are not bound to a namespace > > until the contents of the grouping are added to the schema tree via a > > "uses" statement that does not appear inside a "grouping" statement, > > at which point they are bound to the namespace of the current module. > > NEW > > The identifiers defined or unqualified names used in the grouping > > are not bound to a namespace until the contents of the grouping are > > added to the schema tree via a "uses" statement that does not > > appear inside a "grouping" statement, at which point they are bound > > to the namespace of the current module. > > This is not true. Unqualified names used in a grouping are resolved > in the place where the grouping is defined, not where it is used. grouping ggg { leaf foo { type uint8; } leaf bar { type uint8; must ". < ../foo"; } I think we agreed that both the definition and use of "foo" get the namespace of the module where the grouping is used. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Jan 5 13:27:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFD63A691B for ; Tue, 5 Jan 2010 13:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF2mzd67-fFZ for ; Tue, 5 Jan 2010 13:27:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B304D3A691A for ; Tue, 5 Jan 2010 13:27:36 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 0DCD8D800CC; Tue, 5 Jan 2010 22:27:35 +0100 (CET) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4B43A781.7080300@iwl.com> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724583.11199.79.camel@missotis> <4B43A781.7080300@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 05 Jan 2010 22:27:33 +0100 Message-ID: <1262726853.11199.112.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:27:37 -0000 Andy Bierman píše v Út 05. 01. 2010 v 12:56 -0800: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 05. 01. 2010 v 16:48 +0100: > >>> 1. My main remaining concern is the possible impact of the "when" > >>> statement. This was discussed in a separate thread and some changes > >>> may already be pending, but I think it is necessary to make sure > >>> that the rules governing whether a given data node is mandatory or > >>> not are unaffected by "when" (or "must"). > >> My interpretation of that discussion is that there is no consensus to > >> change the current behavior. > > > > But I actually meant to stick strictly to the current text. It says, > > e.g., in sec. 7.6.5: "the leaf MUST exist", full stop, i.e., without > > regard to any "when" or "must". Thus having the leaf definition > > > > leaf foo { > > mandatory true; > > when "1=0"; > > } > > > > the leaf MUST exist (if the corresponding ancestor exists), otherwise > > the above condition is clearly violated. > > > No -- we need to make it clear that there is a 'property > precedence' defined for YANG, just like an 'operator precedence' > in a programming language. > > The when-stmt has precedence over the mandatory-stmt and > min-elements-stmt. If it is false, then the schema node does not > conceptually exist. How the validation code deals with > this is an implementation detail. But I strongly object exactly to stating this kind of precedence. One then could not tell whether the schema node exists or not before interpreting the data that the schema is supposed to describe. Lada > > > > Andy > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jan 5 13:49:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45B628C0EA for ; Tue, 5 Jan 2010 13:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgDbGHk4gZVf for ; Tue, 5 Jan 2010 13:49:33 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 05FB83A67F2 for ; Tue, 5 Jan 2010 13:49:33 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BEA1476C67B; Tue, 5 Jan 2010 22:49:30 +0100 (CET) Date: Tue, 05 Jan 2010 22:48:49 +0100 (CET) Message-Id: <20100105.224849.77241759.mbj@tail-f.com> To: phil@idle.juniper.net From: Martin Bjorklund In-Reply-To: <201001051808.o05I8kEu076523@idle.juniper.net> References: <20100105.164825.224628419.mbj@tail-f.com> <201001051808.o05I8kEu076523@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:49:33 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > > The XPath expression MUST NOT include any references to nodes > > defined in the "when" statement's parent statement. > > I'm lost trying to connect this with the laissez-faire attitude > you (plural) wanted WRT typos in XPath expressions. You allow > references to nonsense, but want to restrict references to "when" > nodes? Makes no sense. No you are right. A better fix, for consistency, is to remove this sentence. /martin From mbj@tail-f.com Tue Jan 5 13:52:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408853A6893 for ; Tue, 5 Jan 2010 13:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D38FnE+DBqoF for ; Tue, 5 Jan 2010 13:52:39 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 396463A67F2 for ; Tue, 5 Jan 2010 13:52:39 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DDE876C67D; Tue, 5 Jan 2010 22:52:37 +0100 (CET) Date: Tue, 05 Jan 2010 22:51:56 +0100 (CET) Message-Id: <20100105.225156.161166134.mbj@tail-f.com> To: david.kessens@nsn.com, david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <201001051841.o05IfD4U080187@idle.juniper.net> References: <20100105.192852.141141230.mbj@tail-f.com> <201001051841.o05IfD4U080187@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: [netmod] Lost email (Was review of yang-09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:52:40 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Which other email? Could you send a pointer? > > Attached. My response was: To the chairs: it seems emails from Phil today don't make it to the list. This fact makes the conversation a bit difficult to follow... I suspect they are classified as spam, and are held in the moderation queue. /martin From mbj@tail-f.com Tue Jan 5 13:53:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321FD3A659C for ; Tue, 5 Jan 2010 13:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-MfCJB2it0p for ; Tue, 5 Jan 2010 13:53:54 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 542703A6407 for ; Tue, 5 Jan 2010 13:53:54 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A3CAD76C67D; Tue, 5 Jan 2010 22:53:52 +0100 (CET) Date: Tue, 05 Jan 2010 22:53:11 +0100 (CET) Message-Id: <20100105.225311.133419012.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B43A678.1050800@iwl.com> References: <4B439128.2070203@iwl.com> <20100105.213041.71132649.mbj@tail-f.com> <4B43A678.1050800@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] closure on yang-09, sec 10, revision rules thread started 12/07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:53:55 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> > >> IMO, it is important to state that as far as the standard > >> is concerned, a missing revision date is considered to > >> be the special case where there is no revision. > >> This is consistent with the XML namespace rules (xmlns=""). > >> > >> Therefore, any changes to a such a YANG module are > >> illegal changes according to sec. 10. > > > > I am not sure what change, if any, you are proposing. > > > > yang-09, sec. 10, para 2: > > OLD: > > For any published change, a new "revision" statement (Section 7.1.9) > SHOULD be included in front of the existing revision statements. > Furthermore, any necessary changes MUST be applied to any meta data > statements, including the "organization" and "contact" statements > (Section 7.1.7, Section 7.1.8). > > NEW: > > For any published change, a new "revision" statement (Section 7.1.9) > MUST be included in front of the existing revision statements. > ^^^^ > If there are no existing revision statements, then one MUST be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > added to identify the new revision. Furthermore, any necessary > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > changes MUST be applied to any meta data statements, including the > "organization" and "contact" statements (Section 7.1.7, Section 7.1.8). Ok, fixed. /martin From andyb@iwl.com Tue Jan 5 14:03:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB483A67AC for ; Tue, 5 Jan 2010 14:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJTdmRoMhxTD for ; Tue, 5 Jan 2010 14:03:39 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 7327B3A6405 for ; Tue, 5 Jan 2010 14:03:39 -0800 (PST) Received: from relay1.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay1.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id D19361279C81; Tue, 5 Jan 2010 17:03:37 -0500 (EST) Received: by relay1.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9EBC31279C76; Tue, 5 Jan 2010 17:03:37 -0500 (EST) Message-ID: <4B43B74A.8080802@iwl.com> Date: Tue, 05 Jan 2010 14:03:54 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724583.11199.79.camel@missotis> <4B43A781.7080300@iwl.com> <1262726853.11199.112.camel@missotis> In-Reply-To: <1262726853.11199.112.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:03:40 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v Út 05. 01. 2010 v 12:56 -0800: >> Ladislav Lhotka wrote: >>> Martin Bjorklund píše v Út 05. 01. 2010 v 16:48 +0100: >>>>> 1. My main remaining concern is the possible impact of the "when" >>>>> statement. This was discussed in a separate thread and some changes >>>>> may already be pending, but I think it is necessary to make sure >>>>> that the rules governing whether a given data node is mandatory or >>>>> not are unaffected by "when" (or "must"). >>>> My interpretation of that discussion is that there is no consensus to >>>> change the current behavior. >>> But I actually meant to stick strictly to the current text. It says, >>> e.g., in sec. 7.6.5: "the leaf MUST exist", full stop, i.e., without >>> regard to any "when" or "must". Thus having the leaf definition >>> >>> leaf foo { >>> mandatory true; >>> when "1=0"; >>> } >>> >>> the leaf MUST exist (if the corresponding ancestor exists), otherwise >>> the above condition is clearly violated. >> >> No -- we need to make it clear that there is a 'property >> precedence' defined for YANG, just like an 'operator precedence' >> in a programming language. >> >> The when-stmt has precedence over the mandatory-stmt and >> min-elements-stmt. If it is false, then the schema node does not >> conceptually exist. How the validation code deals with >> this is an implementation detail. > > But I strongly object exactly to stating this kind of precedence. One > then could not tell whether the schema node exists or not before > interpreting the data that the schema is supposed to describe. > yes, so what's your point? It may be hard to implement, but it is the intent of the when-stmt. If not, then uses-when and augment-when become very restricted features, and they are very important. It is very likely that nodes in a grouping will have constraints related to members of the grouping. We have also wanted a SPARSE-AUGMENTS in MIBs for 15 years, so the use-case for augment-when seems quite string. > Lada > >> Andy From mbj@tail-f.com Tue Jan 5 14:10:01 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B93A3A67D4 for ; Tue, 5 Jan 2010 14:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E2TSbT5KrJ0 for ; Tue, 5 Jan 2010 14:10:00 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C34963A659C for ; Tue, 5 Jan 2010 14:09:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B51876C67D; Tue, 5 Jan 2010 23:09:58 +0100 (CET) Date: Tue, 05 Jan 2010 23:09:17 +0100 (CET) Message-Id: <20100105.230917.154923876.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1262726329.11199.104.camel@missotis> References: <201001051758.o05HwAFI075689@idle.juniper.net> <1262726329.11199.104.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org, phil@idle.juniper.net Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:10:01 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgw5p0IDA1LiAwMS4gMjAxMCB2IDEyOjU4IC0wNTAwOg0KPiA+ID4NCj4gPiA+ICAg LSBzZWMuIDUuMy4xOg0KPiA+ID4gICAgIE9MRA0KPiA+ID4gICAgIFRoaXMgbmFtZXNwYWNlIGlz ICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6MSIuDQo+ID4gPiAgICAgTkVXDQo+ID4gPiAg ICAgVGhlIG5hbWUgb2YgdGhpcyBuYW1lc3BhY2UgaXMgInVybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzoxIi4NCj4gPiANCj4gPiAtMSB0byB0aGVzZSB0d28uICBJIGRvIG5vdCBzZWUgYW55IGFk ZGl0aW9uYWwgY2xhcml0eSBmcm9tIHRoZSBjaGFuZ2VzLg0KPiANCj4gVGhlIFVSTiBpcyBub3Qg dGhlIG5hbWVzcGFjZS4gIk5hbWVzcGFjZXMgaW4gWE1MIDEuMCAoVGhpcmQgRWRpdGlvbikiDQo+ IGhhcyB0aGlzIGRlZmluaXRpb24gaW4gc2VjLiAyLjE6ICJGb3IgYSBuYW1lIE4gaW4gYSBuYW1l c3BhY2UgaWRlbnRpZmllZA0KPiBieSBhIFVSSSBJLCB0aGUgbmFtZXNwYWNlIG5hbWUgaXMgSS4i DQoNCkkgYWdyZWUgd2l0aCBMYWRhLCB3ZSBzaG91bGQgZm9sbG93IHRoZSBXM0MgdGVybWlub2xv Z3kuDQoNCj4gPiA+My4gVGhlIG5vcm1hbGl6YXRpb24gb2YgWE1MIGF0dHJpYnV0ZXMgbWF5IGFm ZmVjdCBub3Qgb25seSBhcmd1bWVudHMNCj4gPiA+ICAgaW4gWUlOIGJ1dCBhbHNvIHRoZSB2YWx1 ZXMgb2YgdGhlICJ2YWx1ZSIgYXR0cmlidXRlIGluIHNlYy4gNy43LjcuDQo+ID4gPiAgIEZvciBl eGFtcGxlLCBhIGxlYWYtbGlzdCBpdGVtIGNvbnRhaW5pbmcgYSB0YWIgY2hhcmFjdGVyICgiXHQi KQ0KPiA+ID4gICBjYW5ub3QgYmUgYWRkcmVzc2VkIHVzaW5nIHRoZSAidmFsdWUiIGF0dHJpYnV0 ZS4NCj4gPiANCj4gPiBUaGlzIGlzIHlldCBhbm90aGVyIGNhc2Ugd2hlcmUgb25lIG11c3QgYXNr ICJ3aGF0IHdlcmUgdGhleSB0aGlua2luZyIuDQo+ID4gVGhlIG5vcm1hbGl6YXRpb24gb2YgInZh bHVlIiBhbmQgImtleSIgbWVhbnMgd2UgbmVlZCBhIG5ldyBtZWNoYW5pc20sDQo+ID4gc2luY2Ug d2UgY2Fubm90IG1ha2UgdGFicyBpbGxlZ2FsIGluIGlkZW50aWZpZXJzLg0KPiANCj4gSXQncyBu b3Qgb25seSBhYm91dCBpZGVudGlmaWVycywgdGhlICJ5YW5nOnZhbHVlIiBhdHRyaWJ1dGUgY29u dGFpbnMNCj4gbGVhZi1saXN0IHZhbHVlcy4NCg0KUmlnaHQuDQoNCj4gPiBUaGUgc2ltcGxlc3Qg Y2hhbmdlIHdvdWxkIGJlIHRvIGhhdmUgYSAieWFuZyIgbmFtZXNwYWNlIHdpdGggImluc2VydCIs DQo+ID4gImtleSIsIGFuZCAidmFsdWUiIGFzIGVsZW1lbnRzIG9mIHRoYXQgbmFtZXNwYWNlLiAg VGhlbiB3ZSdkIHJlcXVpcmUNCj4gPiB0aGF0IHRoZXNlIGVsZW1lbnRzIGFwcGVhciBmaXJzdCB1 bmRlciB0aGUgcGFyZW50IGVsZW1lbnQuICBUaGlzIHdvdWxkDQo+ID4gYWxsb3cgYSBzaW1wbGVy IHNvbHV0aW9uIGZvciBtdWx0aXBsZSBrZXlzOg0KPiA+IA0KPiA+ICAgICA8cHJlZml4Pg0KPiA+ ICAgICAgICA8eWFuZzppbnNlcnQ+YmVmb3JlPC95YW5nOmluc2VydD4NCj4gPiAgICAgICAgPHlh bmc6a2V5cz4NCj4gPiAgICAgICAgICAgPG5hbWU+MTAuMS4yLjAvMjQ8L25hbWU+DQo+ID4gICAg ICAgICAgIDx0eXBlPm9yLWxvbmdlcjwvdHlwZT4NCj4gPiAgICAgICAgPC95YW5nOmtleXM+DQo+ ID4gICAgICAgIDxuYW1lPjEwLjEuMS4wLzI0PC9uYW1lPg0KPiA+ICAgICAgICA8dHlwZT5leGFj dDwvdHlwZT4NCj4gPiAgICAgPC9wcmVmaXg+DQo+ID4gDQo+ID4gKGFzc3VtaW5nICJsaXN0IHBy ZWZpeCIgaXMgImtleSAnbmFtZSB0eXBlJyIpLg0KPiANCj4gV2hlcmUgd291bGQgdGhlIGVkaXQt Y29uZmlnICJvcGVyYXRpb24iIGF0dHJpYnV0ZSBiZT8NCg0KSnVzdCBhcyB3aXRoIHRoZSBhdHRy aWJ1dGUgc29sdXRpb24gLSBpbiB0aGUgPHByZWZpeD4gZWxlbWVudC4NCg0KPiA+ID4xMy4gU2Vj LiA3LjEyOg0KPiA+ID4gICBPTEQNCj4gPiA+ICAgVGhlIGlkZW50aWZpZXJzIGRlZmluZWQgaW4g dGhlIGdyb3VwaW5nIGFyZSBub3QgYm91bmQgdG8gYSBuYW1lc3BhY2UNCj4gPiA+ICAgdW50aWwg dGhlIGNvbnRlbnRzIG9mIHRoZSBncm91cGluZyBhcmUgYWRkZWQgdG8gdGhlIHNjaGVtYSB0cmVl IHZpYSBhDQo+ID4gPiAgICJ1c2VzIiBzdGF0ZW1lbnQgdGhhdCBkb2VzIG5vdCBhcHBlYXIgaW5z aWRlIGEgImdyb3VwaW5nIiBzdGF0ZW1lbnQsDQo+ID4gPiAgIGF0IHdoaWNoIHBvaW50IHRoZXkg YXJlIGJvdW5kIHRvIHRoZSBuYW1lc3BhY2Ugb2YgdGhlIGN1cnJlbnQgbW9kdWxlLg0KPiA+ID4g ICBORVcNCj4gPiA+ICAgVGhlIGlkZW50aWZpZXJzIGRlZmluZWQgb3IgdW5xdWFsaWZpZWQgbmFt ZXMgdXNlZCBpbiB0aGUgZ3JvdXBpbmcNCj4gPiA+ICAgYXJlIG5vdCBib3VuZCB0byBhIG5hbWVz cGFjZSB1bnRpbCB0aGUgY29udGVudHMgb2YgdGhlIGdyb3VwaW5nIGFyZQ0KPiA+ID4gICBhZGRl ZCB0byB0aGUgc2NoZW1hIHRyZWUgdmlhIGEgInVzZXMiIHN0YXRlbWVudCB0aGF0IGRvZXMgbm90 DQo+ID4gPiAgIGFwcGVhciBpbnNpZGUgYSAiZ3JvdXBpbmciIHN0YXRlbWVudCwgYXQgd2hpY2gg cG9pbnQgdGhleSBhcmUgYm91bmQNCj4gPiA+ICAgdG8gdGhlIG5hbWVzcGFjZSBvZiB0aGUgY3Vy cmVudCBtb2R1bGUuDQo+ID4gDQo+ID4gVGhpcyBpcyBub3QgdHJ1ZS4gIFVucXVhbGlmaWVkIG5h bWVzIHVzZWQgaW4gYSBncm91cGluZyBhcmUgcmVzb2x2ZWQNCj4gPiBpbiB0aGUgcGxhY2Ugd2hl cmUgdGhlIGdyb3VwaW5nIGlzIGRlZmluZWQsIG5vdCB3aGVyZSBpdCBpcyB1c2VkLg0KPiANCj4g Z3JvdXBpbmcgZ2dnIHsNCj4gICAgICBsZWFmIGZvbyB7DQo+ICAgICAgICAgdHlwZSB1aW50ODsN Cj4gICAgICB9DQo+ICAgICAgbGVhZiBiYXIgew0KPiAgICAgICAgIHR5cGUgdWludDg7DQo+IAlt dXN0ICIuIDwgLi4vZm9vIjsNCj4gICAgICB9DQo+IA0KPiBJIHRoaW5rIHdlIGFncmVlZCB0aGF0 IGJvdGggdGhlIGRlZmluaXRpb24gYW5kIHVzZSBvZiAiZm9vIiBnZXQgdGhlDQo+IG5hbWVzcGFj ZSBvZiB0aGUgbW9kdWxlIHdoZXJlIHRoZSBncm91cGluZyBpcyB1c2VkLg0KDQpXZSBkaWQsIGFu ZCB0aGF0J3Mgc3BlY2lmaWVkIGluIDYuNC4xICpmb3IgWFBhdGggZXhwcmVzc2lvbnMqLg0KDQpI b3dldmVyLCB1bnF1YWxpZmllZCB0eXBlIHJlZmVyZW5jZXMgKGV0YykgYXJlIHJlc29sdmVkIHdo ZXJlIHRoZQ0KZ3JvdXBpbmcgaXMgZGVmaW5lZCwgYXMgZGVzY3JpYmVkIGluIDcuMTE6DQoNCiAg IElkZW50aWZpZXJzIGFwcGVhcmluZyBpbnNpZGUgdGhlIGdyb3VwaW5nIGFyZSByZXNvbHZlZCBy ZWxhdGl2ZSB0bw0KICAgdGhlIHNjb3BlIGluIHdoaWNoIHRoZSBncm91cGluZyBpcyBkZWZpbmVk LCBub3Qgd2hlcmUgaXQgaXMgdXNlZC4NCg0KU28gdGhlIG9yaWdpbmFsIHRleHQsIHdoaWNoIGRp ZCBub3QgbWVudGlvbiB0aGUgdXNhZ2Ugb2YgbmFtZXMsIGlzDQphY3R1YWxseSBjb3JyZWN0LCBh bmQgdGhlIHRleHQgYWxyZWFkeSBzcGVjaWZpZXMgaG93IHVucXVhbGlmaWVkDQpuYW1lcyBhcmUg cmVzb2x2ZWQuDQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Tue Jan 5 14:14:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D0D3A67D4 for ; Tue, 5 Jan 2010 14:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK2c1B6YcZtP for ; Tue, 5 Jan 2010 14:14:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7AA763A659C for ; Tue, 5 Jan 2010 14:14:32 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 02C1376C67F; Tue, 5 Jan 2010 23:14:30 +0100 (CET) Date: Tue, 05 Jan 2010 23:13:50 +0100 (CET) Message-Id: <20100105.231350.117682449.mbj@tail-f.com> To: lhotka@cesnet.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1262724551.11199.78.camel@missotis> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724551.11199.78.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:14:33 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3Jr bHVuZCBww63FoWUgdiDDmnQgMDUuIDAxLiAyMDEwIHYgMTY6NDggKzAxMDA6DQo+ID4gPiANCj4g PiA+IDEuIE15IG1haW4gcmVtYWluaW5nIGNvbmNlcm4gaXMgdGhlIHBvc3NpYmxlIGltcGFjdCBv ZiB0aGUgIndoZW4iDQo+ID4gPiAgICBzdGF0ZW1lbnQuIFRoaXMgd2FzIGRpc2N1c3NlZCBpbiBh IHNlcGFyYXRlIHRocmVhZCBhbmQgc29tZSBjaGFuZ2VzDQo+ID4gPiAgICBtYXkgYWxyZWFkeSBi ZSBwZW5kaW5nLCBidXQgSSB0aGluayBpdCBpcyBuZWNlc3NhcnkgdG8gbWFrZSBzdXJlDQo+ID4g PiAgICB0aGF0IHRoZSBydWxlcyBnb3Zlcm5pbmcgd2hldGhlciBhIGdpdmVuIGRhdGEgbm9kZSBp cyBtYW5kYXRvcnkgb3INCj4gPiA+ICAgIG5vdCBhcmUgdW5hZmZlY3RlZCBieSAid2hlbiIgKG9y ICJtdXN0IikuDQo+ID4gDQo+ID4gTXkgaW50ZXJwcmV0YXRpb24gb2YgdGhhdCBkaXNjdXNzaW9u IGlzIHRoYXQgdGhlcmUgaXMgbm8gY29uc2Vuc3VzIHRvDQo+ID4gY2hhbmdlIHRoZSBjdXJyZW50 IGJlaGF2aW9yLg0KPiANCj4gQnV0IEkgYWN0dWFsbHkgbWVhbnQgdG8gc3RpY2sgc3RyaWN0bHkg dG8gdGhlIGN1cnJlbnQgdGV4dC4gSXQgc2F5cywNCj4gZS5nLiwgaW4gc2VjLiA3LjYuNTogInRo ZSBsZWFmIE1VU1QgZXhpc3QiLCBmdWxsIHN0b3AsIGkuZS4sIHdpdGhvdXQNCj4gcmVnYXJkIHRv IGFueSAid2hlbiIgb3IgIm11c3QiLiBUaHVzIGhhdmluZyB0aGUgbGVhZiBkZWZpbml0aW9uDQo+ IA0KPiBsZWFmIGZvbyB7DQo+ICAgICBtYW5kYXRvcnkgdHJ1ZTsNCj4gICAgIHdoZW4gIjE9MCI7 DQo+IH0NCj4gDQo+IHRoZSBsZWFmIE1VU1QgZXhpc3QgKGlmIHRoZSBjb3JyZXNwb25kaW5nIGFu Y2VzdG9yIGV4aXN0cyksIG90aGVyd2lzZQ0KPiB0aGUgYWJvdmUgY29uZGl0aW9uIGlzIGNsZWFy bHkgdmlvbGF0ZWQuDQoNCkkgdW5kZXJzdGFuZCB0aGF0LCBidXQgSSB0aGluayB5b3UgYXJlIHRo ZSBvbmx5IG9uZSBvYmplY3RpbmcgdG8gdGhlDQpjdXJyZW50IHRleHQsIHdoaWNoIHNheXM6DQoN CiAgIm11c3QiLCAibWFuZGF0b3J5IiwgIm1pbi1lbGVtZW50cyIsIGFuZCAibWF4LWVsZW1lbnRz IiBjb25zdHJhaW50cw0KICBhcmUgbm90IGVuZm9yY2VkIGlmIHRoZSBwYXJlbnQgbm9kZSBoYXMg YSAid2hlbiIgb3IgImlmLWZlYXR1cmUiDQogIHByb3BlcnR5IHRoYXQgaXMgbm90IHNhdGlzZmll ZCBvbiB0aGUgY3VycmVudCBkZXZpY2UuDQoNCj4gPiA+IDEyLiBTZWMuIDcuOC41OiBpZiBsaXN0 IGtleShzKSBpbnNpZGUgInJwYyIgYXJlIGRlZmluZWQgYWZ0ZXIgYQ0KPiA+ID4gICAgIG5vbi1r ZXkgc2libGluZywgd2hpY2ggcnVsZSB0YWtlcyBwcmVjZWRlbmNlPyBEbyB0aGUga2V5cyBzdGls bA0KPiA+ID4gICAgIGhhdmUgdG8gY29tZSBiZWZvcmUgYWxsIG90aGVyIHNpYmxpbmdzPw0KPiA+ IA0KPiA+IFllcy4gIEkgdGhpbmsgdGhlIHRleHQgaXMgY2xlYXI6DQo+ID4gDQo+ID4gICAgVGhl IGxpc3QncyBrZXkgbm9kZXMgYXJlIGVuY29kZWQgYXMgc3ViZWxlbWVudHMgdG8gdGhlIGxpc3Qn cw0KPiA+ICAgIGlkZW50aWZpZXIgZWxlbWVudCwgaW4gdGhlIHNhbWUgb3JkZXIgYXMgdGhleSBh cmUgZGVmaW5lZCB3aXRoaW4gdGhlDQo+ID4gICAga2V5IHN0YXRlbWVudC4NCj4gPiANCj4gPiAg ICBUaGUgcmVzdCBvZiB0aGUgbGlzdCdzIGNoaWxkIG5vZGVzIGFyZSBlbmNvZGVkIGFzIHN1YmVs ZW1lbnRzIHRvIHRoZQ0KPiA+ICAgIGxpc3QgZWxlbWVudCwgYWZ0ZXIgdGhlIGtleXMuICBJZiB0 aGUgbGlzdCBkZWZpbmVzIFJQQyBpbnB1dCBvcg0KPiA+ICAgIG91dHB1dCBwYXJhbWV0ZXJzLCB0 aGUgc3ViZWxlbWVudHMgYXJlIGVuY29kZWQgaW4gdGhlIHNhbWUgb3JkZXIgYXMNCj4gPiAgICB0 aGV5IGFyZSBkZWZpbmVkIHdpdGhpbiB0aGUgbGlzdCBzdGF0ZW1lbnQuDQo+IA0KPiBCdXQgd2Ug aGF2ZSB0d28gY29uZmxpY3RpbmcgcnVsZXMgaGVyZToNCj4gDQo+IHJwYyBteS1ycGMgew0KPiAg ICAgaW5wdXQgew0KPiAgICAgICAgIGxpc3QgZm9vIHsNCj4gICAgICAgICAgICAga2V5IGNsZWY7 DQo+ICAgICAgICAgICAgIGxlYWYgYmFyIHsgLi4uIH0NCj4gICAgICAgICAgICAgbGVhZiBjbGVm IHsgLi4uIH0NCj4gICAgICAgICB9DQo+ICAgICB9DQo+ICAgICAuLi4NCj4gfQ0KPiANCj4gVGhl IHJ1bGUgZm9yIGxpc3Qga2V5cyBpbXBsaWVzIHRoZSBvcmRlciAiY2xlZiBiYXIiIGJ1dCB0aGUg cnVsZSBmb3IgUlBDDQo+IGltcGxpZXMgImJhciBjbGVmIi4NCg0KTm8sIHRoZSB0ZXh0IHNheXM6 DQoNCiAgICBUaGUgcmVzdCBvZiB0aGUgbGlzdCdzIGNoaWxkIG5vZGVzIGFyZSBlbmNvZGVkIGFz IHN1YmVsZW1lbnRzIHRvDQogICAgdGhlIGxpc3QgZWxlbWVudCwgYWZ0ZXIgdGhlIGtleXMuDQoN ClRoZXJlIGFyZSBubyBleGNlcHRpb25zIHRvIHRoaXMgcnVsZSBpbiB0aGUgdGV4dC4gIEFsbCBu b24ta2V5IGNoaWxkDQpub2RlcyBhcmUgZW5jb2RlZCBhZnRlciB0aGUga2V5IG5vZGVzLg0KDQo+ ID4gPiAxNS4gU2VjLiA0LjIuOToNCj4gPiA+ICAgICBPTEQNCj4gPiA+ICAgICBZQU5HIGFsbG93 cyB0aGUgZGVmaW5pdGlvbiBvZiBORVRDT05GIFJQQ3MuDQo+ID4gPiAgICAgTkVXDQo+ID4gPiAg ICAgWUFORyBhbGxvd3MgdG8gZGVmaW5lIHRoZSBzY2hlbWEgKHNpZ25hdHVyZSkgb2YgTkVUQ09O RiBSUENzLg0KPiA+IA0KPiA+IEkgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBpcyBvay4NCj4gPiAN Cj4gDQo+IEJ5ICJkZWZpbml0aW9uIG9mIE5FVENPTkYgUlBDcyIgSSB1bmRlcnN0YW5kIGFsc28g dGhlIGRlZmluaXRpb24gb2YNCj4gdGhlaXIgc2VtYW50aWNzLCB3aGljaCBZQU5HIGRvZXNuJ3Qg YWRkcmVzcy4NCg0KVGhlIHNlbWFudGljcyBpcyBkZWZpbmVkIGluIHRoZSBkZXNjcmlwdGlvbiBj bGF1c2UuDQoNCg0KL21hcnRpbg0KDQoNCg== From mbj@tail-f.com Tue Jan 5 14:15:41 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2A33A6768 for ; Tue, 5 Jan 2010 14:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpxs995mz9Xf for ; Tue, 5 Jan 2010 14:15:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CEF533A659C for ; Tue, 5 Jan 2010 14:15:39 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 56B8476C67F; Tue, 5 Jan 2010 23:15:38 +0100 (CET) Date: Tue, 05 Jan 2010 23:14:57 +0100 (CET) Message-Id: <20100105.231457.38838413.mbj@tail-f.com> To: lhotka@cesnet.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1262724551.11199.78.camel@missotis> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724551.11199.78.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:15:41 -0000 Ladislav Lhotka wrote: > > I think the usage of this term in 4.2.6 is ok: > > > > Groups of nodes can be assembled into the equivalent of complex types > > using the "grouping" statement. > > If XSD complex types are meant here, I don't think groupings are really > equivalent to them. Ok. Do you think we can say "structured type" instead? Or should we simply remove the sentence? /martin From mbj@tail-f.com Tue Jan 5 14:47:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EBF3A683C for ; Tue, 5 Jan 2010 14:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnTs0KebBFs7 for ; Tue, 5 Jan 2010 14:47:50 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AE9493A681F for ; Tue, 5 Jan 2010 14:47:49 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2CB9A76C67F; Tue, 5 Jan 2010 23:47:48 +0100 (CET) Date: Tue, 05 Jan 2010 23:47:47 +0100 (CET) Message-Id: <20100105.234747.137861106.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100105122737.GA34963@elstar.local> References: <20100105122737.GA34963@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 22:47:52 -0000 Hi, Thank you Juergen for the detailed review! Juergen Schoenwaelder wrote: > * JS-01: > > In the terminology section, I think it would help if the text would > spell out 'data node' or 'schema node' where it currently just says > 'node' since data node and schema node are defined terms and node is > not defined and also more ambiguous. This affects multiple I will get back on this one. > * JS-02: > > OLD: > > o conformance: A measure of how accurately a device follows the > model. > > NEW > > o conformance: A measure of how accurately a device implements a > data model. Fixed. > * JS-03: > > RPC vs. method vs. RPC method vs. operation: All these terms seem to > mean the same and I would prefer to have less of these terms around. > My preference would be to eliminate the usage of "method" or "RPC > method" in favour of "operation" throughout the YANG spec. Personally, > I would even go as far as eliminating RPC in most cases in the text. Ok. I replaced "method" with "operation". (Maybe this should be fixed in 4741bis as well.) > * JS-04: > > The third sentence of the following text is ambiguous: > > A list defines a sequence of list entries. Each entry is like a > structure or a record instance, and is uniquely identified by the > values of its key leafs. A list can define multiple keys and may > contain any number of child nodes of any type (including leafs, > lists, containers etc.). > > I think it should be "A list can define multiple key leafs ...". Fixed. > There is only one key but the key may be made up of multiple key > leafs. Perhaps we need a definition of the terms "key" and "key leaf". > > * JS-05: > > I do not understand the column "Type" in the table on page 20 nor do I > see that it is needed since the "Description" column is sufficient. I > suggest to get rid of the "Type" column. Ok, the Type column is removed. > * JS-06: > > OLD > > using the "grouping" statement. "grouping" defines a set of nodes > > NEW > > using the "grouping" statement. A "grouping" defines a set of nodes NEWER: using the "grouping" statement. A grouping defines a set of nodes > * JS-07: > > The separator of the revision-data in the file name (section 5.2) > should change, see also the mailing list discussion. Ok. Changed to '@'. > * JS-08: > > OLD > > reasons. Many errors and warnings that cannot be detected during > > NEW > > reasons. Errors and warnings that cannot be detected during Fixed. > * JS-09: > > There are multiple places where the ID talks about RFC streams. Shall > we add a reference to RFC 4844 in those places? I think that makes sense. > * JS-10: > > OLD > > and semantics behind the modeled data. The strength of YANG lies in > the strength of this contract and the mindless devotion with which > implementers follow it. > > NEW > > and semantics behind the modeled data. The strength of YANG lies in > the strength of this contract. Fixed. > * JS-11: > > OLD: > > In many models, the modeler will allow sections of the model to be > conditional, based on the device. > > NEW > > In many models, the modeler will allow sections of the model to be > conditional. Fixed. > * JS-12: > > I fail to understand the purpose of section 5.7. This either needs to > be rewritten or it should be removed. Here is the section: > > 5.7. Data Store Modification > > Data models may allow the server to alter the configuration data > store. A formal mechanism for specifying the circumstances where > these changes are allowed is out of scope for this specification. This was suggested in the thread "resolution of system-creatable discussion". > * JS-13: > > Quoting: > > The following sections describe all of the YANG core statements. > > This raises the question what are core statements and what are > non-core statements. And given the organization of the document, type > restrictions (defined in section 9) suddenly are not YANG core > statements anymore. I believe the wording "core statements" creates > more trouble than it is adding value and I thus prefer to avoid using > this term. If the term, however, is considered essential, define it > properly in the terminology section. I agree, I have removed 'core' from the document. > * JS-14: > > Quoting: > > Note that even a statement which does not have any substatements > defined in core YANG can have vendor-specific extensions as > substatements. For example, the "description" statement does not > have any substatements defined in core YANG, but the following is > legal: > > This now talks about core YANG. Similar to JS-13, I believe we are > better served to avoid this terminology. Yes. removed. > * JS-15: > > OLD > > the module, including the initial revision. A series of revisions > > NEW > > the module, including the initial revision. A series of revision Fixed. > * JS-16: > > OLD > > The "container" statement is used to define an interior node in the > schema tree. > > NEW > > The "container" statement is used to define an interior data node in the > schema tree. See JS-1. > * JS-17: > > It seems the examples are pretty much chosen randomly. We have > examples related to DNS resolvers, interfaces, ssh services, users, > sonet, gps, and rock-the-house (perhaps even stuff I do not recall). > Perhaps we can replace some of the more esoteric examples with more > down to earth stuff easily understood by most readers. I think the examples are ok, but feel free to suggest improvements! > * JS-18: > > The examples come with varying level of completeness. I would prefer > to make several examples more complete. A good example is section > 9.2.5 and 9.4.5. Ok, I have changed some examples in section 9 to be more complete. > * JS-19: > > This text is somewhat unclear: > > When a datastore is validated, all "must" constraints are > conceptually evaluated once for each corresponding instance in the > data tree > > What is a 'corresponding instance'? I guess I know what the intent is > behind the text but I see why someone new might get confused. Perhaps > this is what was intended: > > When a datastore is validated, all "must" constraints are > conceptually evaluated for each data node in the data tree > matching a schema node holding a "must" statement. Hmm... do we need to explain what "matching" a schema node means? I will think some more about this one. > * JS-20: > > There are some "elements of procedure" for the NETCONF > operation and it seems they over simplify things. An example is > 7.6.7: > > If the operation is "merge", the node is created if it does not > exist, and its value is set to the value found in the XML RPC > data. > > If the operation is "replace", the node is created if it does not > exist, and its value is set to the value found in the XML RPC > data. > > If the operation is "create" the node is created if it does not > exist. > > I assume the value is assigned in a create as well. This means, the > text for all three (merge, replace, create) then is the same but the > NETCONF processing is not since the create fails if the node exists. > I think we serve the reader by spelling out this in more detail. And > is it really true that "merge" and "replace" are interchangeable or > does "replace" require that the data mode exists? Note that this > comment affects multiple places in the document. Agreed. See my email "YANG WGLC: edit-config clarifications" from 22 dec. with suggested changes to this text. > * JS-21: > > A usage examples that "creates a leaf" by using a "merge" may be > confusing since a "merge" is not the same as a "create". (This affects > section 7.6.8. and 7.7.8, perhaps other examples as well.) There are also some examples with operation create. I think it is good to show both methods. > * JS-22: > > OLD > > Where the "leaf" statement is used to define a simple scalar variable > of a particular type, the "leaf-list" statement is used to define an > array of a particular type. > > NEW > > Where the "leaf" statement is used to define a simple scalar variable > of a particular type, the "leaf-list" statement is used to define an > ordered set of values of a particular type. > > The word "array" may be potentially confusing and is never used > elsewhere in the document. "array" is used to distinguish it from "simple scalar varaible". I think it is ok to use. > * JS-23: > > The ordered-by statement takes as argument "user" or "system". The > text in section 7.7.1 talks about user and the device. NETCONF itself > has clients and servers. There might be meaning behind the decision of > using all these different terms. But then the terminology section does > not help with understanding the differences. Perhaps this really > should have been 'ordered-by device'? Or declare that device and > system are the same? I think 7.7.1 does that: In many lists, the order of list entries does not impact the implementation of the list's configuration, and the device is free to sort the list entries in any reasonable order. [...] YANG calls this style of list "system ordered" and they are indicated with the statement "ordered-by system". > * JS-24: > > This text perhaps needs some revision: > > A leaf-list node is encoded as a series of XML elements. Each > element's name is the leaf-list's identifier, and its XML namespace > is the module's XML namespace. > > The value of the leaf-list node is encoded to XML according to the > type, and sent as character data in the element. > > The point here is that the schema tree leaf-list node leads to > multiple data tree nodes. If we only talk about "node", the text > becomes somewhat confusing I think. NEW: A leaf-list node is encoded as a series of XML elements. Each element's local name is the leaf-list's identifier, and its namespace name is the module's XML namespace (see ^namespace^). The value of each leaf-list entry is encoded to XML according to the type, and sent as character data in the element. > * JS-25: > > The insert behaviour is not clear to me. Suppose I have this slight > variation of what is in 7.7.8: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns:yang="urn:ietf:params:xml:ns:yang:1"> > > > > > > > > > yang:insert="after" > yang:value="3des-cbc">blowfish-cbc > aaa > > > > > > > > Where does aaa go? Do the yang:insert and yang:value attributes have > impact of the subsequent create? No; aaa will be added last in the list. > * JS-26: > > The move feature defined by way of example in section 7.8.7. probably > requires some mentioning in the section 7.8.6. as well. It came to me > as a surprise after having read 7.8.6. 7.8.6 mentions 'move': These can be used during "create" operations to insert a new list entry, or during "merge" or "replace" operations to insert a new list entry or move an existing one. > * JS-27: > > OLD > > the subelements are be encoded in any order. > > NEW > > the subelements are encoded in any order. Fixed. > * JS-28: > > This might be wrong: > > The grouping statement is not a data definition statement and, as > such, does not define any nodes in the schema tree. > > Perhaps you meant the data tree and not the schema tree. No it is correct - a grouping does not define a node in the schema tree. Maybe the sentence should be removed. We should not list everything we *don't* do. > * JS-29: > > OLD > > with the "refine" statement. The argument is a a string which > > NEW > > with the "refine" statement. The argument is a string which Fixed. > * JS-30: > > If a "config" statement is present for any node in the output tree, > it is ignored. > > What is being ignored, the config statement of the node? NEW: If a "config" statement is present for any node in the input tree, the "config" statement is ignored. > > * JS-31: > > What is the rationale behind this: > > If a container in the notification tree has a "presence" statement, > the container need not be present in a NETCONF notification. I agree that it doesn't really say anything. I will remove this sentence. > * JS-32: > > If a "config" statement is present for any node in the notification > tree, it is ignored. > > Again, it is unclear what is ignored (the config statement of the node). Fixed. > * JS-33: > > I suggest to replace the very abstract even notification with > something more down to earth. This is pretty much the high-level > opaque stuff we prefer not to see in YANG data models. (At least > this is my opinion. ;-) The example is from rfc 5277; it is just a YANG version of an example there. But I am open to suggestions! We also have some other examples in the document. > * JS-34: > > OLD > > name is created by combining the the prefix of the module in which > > NEW > > name is created by combining the prefix of the module in which Fixed. > * JS-35: > > OLD > > The deviation statement defines a hierarchy of the module which the > > NEW > > The deviation statement defines a hierarchy of a module which the Fixed. > * JS-36: > > OLD > > identifies the node in the schema tree where a deviation from the > > NEW > > identifies the node in the schema tree where a deviation from a > > * JS-37: > > OLD > > the standard. This means that deviations MUST never be part of a > > NEW > > a standard. This means that deviations MUST never be part of a Fixed. > * JS-38: > > OLD > > Instead, YANG allows devices to document portions of the base module > > NEW > > Instead, YANG allows devices to document portions of a base module Fixed. > * JS-39: > > OLD > > properties to delete are identified by substatement to "delete". The > > NEW > > properties to delete are identified by a substatement of the "delete" statement. The Fixed. > * JS-40: > > Section 9.4 contains this: > > // any Unicode character, excluding the surrogate blocks, > // FFFE, and FFFF. > string = *char > char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / > %x10000-10FFFF > > It is unclear what this is. Looks like ABNF but then the comment > character would be wrong. Ok, changed comment character to ; > * JS-41: > > as defined in [XSD-TYPES]. It is used to restrict the built-in type > "string", or types derived from "string", to values that completely > matches the pattern. > > Not sure what "completely" adds here. The pattern matches or it does > not - I think there is no notion of a partial match. Agreed. I removed 'completely'. > * JS-42: > > OLD > > restricted, based on the rules defined in Section 9 chapter. > > NEW > > restricted, based on the rules defined in Section 9. Fixed. > * JS-43: > > Section 11 says: > > A YANG module can be specified in an alternative XML-based syntax > called YIN. This section describes symmetric mapping rules between > the two formats. > > I believe we need to separate the concept of a YANG module from that > of a YIN module. I would prefer this instead: > > A YANG module can be translated into an alternative XML-based > syntax called YIN. The translated module is called a YIN > module. This section describes symmetric mapping rules between the > two formats. > > This makes it clear that a YANG parser is parsing YANG modules and a > YIN parser is parsing YIN modules. Ok, fixed. > * JS-44: > > I suggest to use this YIN URI > > "urn:ietf:params:xml:ns:yin:1" > > instead of > > "urn:ietf:params:xml:ns:yang:yin:1" > > since there is little value of nesting this. But I do not care > strongly about this. I prefer to keep the current one. /martin From phil@juniper.net Tue Jan 5 16:11:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492493A68CB for ; Tue, 5 Jan 2010 16:11:22 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dh2YwBaMIP2 for ; Tue, 5 Jan 2010 16:11:21 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 03FAE3A657C for ; Tue, 5 Jan 2010 16:11:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKS0PVI+CSD0b+jR557Dmkpcpd8314btOz@postini.com; Tue, 05 Jan 2010 16:11:20 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 5 Jan 2010 16:07:04 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 16:07:04 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 16:07:03 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 16:07:03 -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 o06072j63087; Tue, 5 Jan 2010 16:07:02 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o05Nplwl089125; Tue, 5 Jan 2010 23:51:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001052351.o05Nplwl089125@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100105.225156.161166134.mbj@tail-f.com> Date: Tue, 5 Jan 2010 18:51:47 -0500 From: Phil Shafer X-OriginalArrivalTime: 06 Jan 2010 00:07:03.0448 (UTC) FILETIME=[2CE3C980:01CA8E64] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Lost email (Was review of yang-09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 00:11:22 -0000 Martin Bjorklund writes: >I suspect they are classified as spam, and are held in the moderation >queue. My bad. I upgraded, fixed /etc/mail/*.mc, but did "make" instead of "make install". Fixed now, and I'll resend the two emails shortly. Thanks, Phil From phil@juniper.net Tue Jan 5 16:19:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2CE3A6830 for ; Tue, 5 Jan 2010 16:19: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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v71SI7n6HOp for ; Tue, 5 Jan 2010 16:19:31 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id EB7C13A657C for ; Tue, 5 Jan 2010 16:19:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKS0PXDaw+xsY3xiu+WtNoBt0dqU0I85ip@postini.com; Tue, 05 Jan 2010 16:19:30 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 5 Jan 2010 16:16:09 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 16:16:09 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 16:16:09 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 16:16:08 -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 o060G7j65983; Tue, 5 Jan 2010 16:16:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o0600r4A089192; Wed, 6 Jan 2010 00:00:53 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001060000.o0600r4A089192@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100105.230917.154923876.mbj@tail-f.com> Date: Tue, 5 Jan 2010 19:00:53 -0500 From: Phil Shafer X-OriginalArrivalTime: 06 Jan 2010 00:16:08.0800 (UTC) FILETIME=[71F1E600:01CA8E65] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 00:19:32 -0000 Martin Bjorklund writes: >I agree with Lada, we should follow the W3C terminology. The new terminology is verbose and IMHO does more harm than good. Are we willing to s/prefix/namespace prefix/ and s/element name/element local name/ (or whatever the new term is) throughout the entire YANG spec? Thanks, Phil From lhotka@cesnet.cz Tue Jan 5 23:37:57 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94453A67B5 for ; Tue, 5 Jan 2010 23:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bezmQbi48GMF for ; Tue, 5 Jan 2010 23:37:57 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A6E1A3A659A for ; Tue, 5 Jan 2010 23:37:56 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 512BED800C8; Wed, 6 Jan 2010 08:37:54 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100105.230917.154923876.mbj@tail-f.com> References: <201001051758.o05HwAFI075689@idle.juniper.net> <1262726329.11199.104.camel@missotis> <20100105.230917.154923876.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Jan 2010 08:37:52 +0100 Message-ID: <1262763472.12822.27.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, phil@idle.juniper.net Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 07:37:57 -0000 Martin Bjorklund píše v Út 05. 01. 2010 v 23:09 +0100: > > > The simplest change would be to have a "yang" namespace with "insert", > > > "key", and "value" as elements of that namespace. Then we'd require > > > that these elements appear first under the parent element. This would > > > allow a simpler solution for multiple keys: > > > > > > > > > before > > > > > > 10.1.2.0/24 > > > or-longer > > > > > > 10.1.1.0/24 > > > exact > > > > > > > > > (assuming "list prefix" is "key 'name type'"). > > > > Where would the edit-config "operation" attribute be? > > Just as with the attribute solution - in the element. Hmm, this is not very nice, it would then be much better to have the NETCONF operation as a subelement, too, and encapsulate the additional info inside it. > > > > >13. Sec. 7.12: > > > > OLD > > > > The identifiers defined in the grouping are not bound to a namespace > > > > until the contents of the grouping are added to the schema tree via a > > > > "uses" statement that does not appear inside a "grouping" statement, > > > > at which point they are bound to the namespace of the current module. > > > > NEW > > > > The identifiers defined or unqualified names used in the grouping > > > > are not bound to a namespace until the contents of the grouping are > > > > added to the schema tree via a "uses" statement that does not > > > > appear inside a "grouping" statement, at which point they are bound > > > > to the namespace of the current module. > > > > > > This is not true. Unqualified names used in a grouping are resolved > > > in the place where the grouping is defined, not where it is used. > > > > grouping ggg { > > leaf foo { > > type uint8; > > } > > leaf bar { > > type uint8; > > must ". < ../foo"; > > } > > > > I think we agreed that both the definition and use of "foo" get the > > namespace of the module where the grouping is used. > > We did, and that's specified in 6.4.1 *for XPath expressions*. > > However, unqualified type references (etc) are resolved where the > grouping is defined, as described in 7.11: > > Identifiers appearing inside the grouping are resolved relative to > the scope in which the grouping is defined, not where it is used. Does this mean that "foo" inside the XPath expression in my example is bound to the namespace of the module where "ggg" is defined? I hope not. Lada > > So the original text, which did not mention the usage of names, is > actually correct, and the text already specifies how unqualified > names are resolved. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Jan 5 23:41:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0413A67C1 for ; Tue, 5 Jan 2010 23:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynwq0mNn6Sfz for ; Tue, 5 Jan 2010 23:41:25 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 215C23A659A for ; Tue, 5 Jan 2010 23:41:25 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id B9389D800CE; Wed, 6 Jan 2010 08:41:23 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100105.231457.38838413.mbj@tail-f.com> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724551.11199.78.camel@missotis> <20100105.231457.38838413.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Jan 2010 08:41:22 +0100 Message-ID: <1262763682.12822.30.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 07:41:26 -0000 Martin Bjorklund píše v Út 05. 01. 2010 v 23:14 +0100: > Ladislav Lhotka wrote: > > > I think the usage of this term in 4.2.6 is ok: > > > > > > Groups of nodes can be assembled into the equivalent of complex types > > > using the "grouping" statement. > > > > If XSD complex types are meant here, I don't think groupings are really > > equivalent to them. > > Ok. Do you think we can say "structured type" instead? Or should we > simply remove the sentence? How about "reusable sets"? Only leafs have types in YANG. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Jan 5 23:56:04 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F173A67FD for ; Tue, 5 Jan 2010 23:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jETKxd9SUrwh for ; Tue, 5 Jan 2010 23:56:04 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9CC543A67FC for ; Tue, 5 Jan 2010 23:56:03 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 5500AD800E8; Wed, 6 Jan 2010 08:56:02 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100105.231350.117682449.mbj@tail-f.com> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724551.11199.78.camel@missotis> <20100105.231350.117682449.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Jan 2010 08:56:00 +0100 Message-ID: <1262764560.12822.44.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 07:56:04 -0000 Martin Bjorklund píše v Út 05. 01. 2010 v 23:13 +0100: > Ladislav Lhotka wrote: > > Martin Bjorklund píše v Út 05. 01. 2010 v 16:48 +0100: > > > > > > > > 1. My main remaining concern is the possible impact of the "when" > > > > statement. This was discussed in a separate thread and some changes > > > > may already be pending, but I think it is necessary to make sure > > > > that the rules governing whether a given data node is mandatory or > > > > not are unaffected by "when" (or "must"). > > > > > > My interpretation of that discussion is that there is no consensus to > > > change the current behavior. > > > > But I actually meant to stick strictly to the current text. It says, > > e.g., in sec. 7.6.5: "the leaf MUST exist", full stop, i.e., without > > regard to any "when" or "must". Thus having the leaf definition > > > > leaf foo { > > mandatory true; > > when "1=0"; > > } > > > > the leaf MUST exist (if the corresponding ancestor exists), otherwise > > the above condition is clearly violated. > > I understand that, but I think you are the only one objecting to the > current text, which says: > > "must", "mandatory", "min-elements", and "max-elements" constraints > are not enforced if the parent node has a "when" or "if-feature" > property that is not satisfied on the current device. Note that no parent node is involved in my example. On the other hand, the above sentence also doesn't apply to container outer { when "..."; container inner { leaf foo { mandatory true; ... } } } > > > > > 12. Sec. 7.8.5: if list key(s) inside "rpc" are defined after a > > > > non-key sibling, which rule takes precedence? Do the keys still > > > > have to come before all other siblings? > > > > > > Yes. I think the text is clear: > > > > > > The list's key nodes are encoded as subelements to the list's > > > identifier element, in the same order as they are defined within the > > > key statement. > > > > > > The rest of the list's child nodes are encoded as subelements to the > > > list element, after the keys. If the list defines RPC input or > > > output parameters, the subelements are encoded in the same order as > > > they are defined within the list statement. > > > > But we have two conflicting rules here: > > > > rpc my-rpc { > > input { > > list foo { > > key clef; > > leaf bar { ... } > > leaf clef { ... } > > } > > } > > ... > > } > > > > The rule for list keys implies the order "clef bar" but the rule for RPC > > implies "bar clef". > > No, the text says: > > The rest of the list's child nodes are encoded as subelements to > the list element, after the keys. > > There are no exceptions to this rule in the text. All non-key child > nodes are encoded after the key nodes. Then I propose this: OLD If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the list statement. NEW If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the list statement, with the exception of key leafs that must always come first. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Jan 6 00:30:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FB63A6811 for ; Wed, 6 Jan 2010 00:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhM43Ngh-4o1 for ; Wed, 6 Jan 2010 00:30:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6B2B73A680A for ; Wed, 6 Jan 2010 00:30:36 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A840DD800CE; Wed, 6 Jan 2010 09:30:34 +0100 (CET) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4B43B74A.8080802@iwl.com> References: <1262682464.5559.0.camel@missotis> <20100105.164825.224628419.mbj@tail-f.com> <1262724583.11199.79.camel@missotis> <4B43A781.7080300@iwl.com> <1262726853.11199.112.camel@missotis> <4B43B74A.8080802@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Jan 2010 09:30:33 +0100 Message-ID: <1262766633.12822.76.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 08:30:37 -0000 Andy Bierman píše v Út 05. 01. 2010 v 14:03 -0800: > Ladislav Lhotka wrote: > > Andy Bierman píše v Út 05. 01. 2010 v 12:56 -0800: > >> Ladislav Lhotka wrote: > >>> Martin Bjorklund píše v Út 05. 01. 2010 v 16:48 +0100: > >>>>> 1. My main remaining concern is the possible impact of the "when" > >>>>> statement. This was discussed in a separate thread and some changes > >>>>> may already be pending, but I think it is necessary to make sure > >>>>> that the rules governing whether a given data node is mandatory or > >>>>> not are unaffected by "when" (or "must"). > >>>> My interpretation of that discussion is that there is no consensus to > >>>> change the current behavior. > >>> But I actually meant to stick strictly to the current text. It says, > >>> e.g., in sec. 7.6.5: "the leaf MUST exist", full stop, i.e., without > >>> regard to any "when" or "must". Thus having the leaf definition > >>> > >>> leaf foo { > >>> mandatory true; > >>> when "1=0"; > >>> } > >>> > >>> the leaf MUST exist (if the corresponding ancestor exists), otherwise > >>> the above condition is clearly violated. > >> > >> No -- we need to make it clear that there is a 'property > >> precedence' defined for YANG, just like an 'operator precedence' > >> in a programming language. > >> > >> The when-stmt has precedence over the mandatory-stmt and > >> min-elements-stmt. If it is false, then the schema node does not > >> conceptually exist. How the validation code deals with > >> this is an implementation detail. > > > > But I strongly object exactly to stating this kind of precedence. One > > then could not tell whether the schema node exists or not before > > interpreting the data that the schema is supposed to describe. > > > > yes, so what's your point? > It may be hard to implement, but it is the intent of > the when-stmt. So you are essentially saying that real men are able to parse XML without having a schema. It may be true for simple examples, but with all the flexibility that YANG offers, a strict schema is IMO a necessity and first line of defense against attacks. > > If not, then uses-when and augment-when become very > restricted features, and they are very important. > It is very likely that nodes in a grouping > will have constraints related to members of the grouping. > We have also wanted a SPARSE-AUGMENTS in MIBs for 15 years, > so the use-case for augment-when seems quite string. I think it is still possible to accomplish this even if "mandatory" is immune to the effects of "when" (and "must", for that matter). The complication in YANG, which is not present e.g. in RELAX NG, is that "mandatory" in leafs permeates up to the ancestor NP containers. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jan 6 01:09:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6D63A680A for ; Wed, 6 Jan 2010 01:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7veHOJMYkbW for ; Wed, 6 Jan 2010 01:09:39 -0800 (PST) Received: from smtp135.dfw.emailsrvr.com (smtp135.dfw.emailsrvr.com [67.192.241.135]) by core3.amsl.com (Postfix) with ESMTP id 9C0353A659A for ; Wed, 6 Jan 2010 01:09:39 -0800 (PST) Received: from relay3.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5D8605D826E; Wed, 6 Jan 2010 04:09:32 -0500 (EST) Received: by relay3.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0B8ED5D8219; Wed, 6 Jan 2010 04:09:31 -0500 (EST) Message-ID: <4B44535C.5010902@iwl.com> Date: Wed, 06 Jan 2010 01:09:48 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <201001051758.o05HwAFI075689@idle.juniper.net> <1262726329.11199.104.camel@missotis> <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> In-Reply-To: <1262763472.12822.27.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: phil@idle.juniper.net, netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 09:09:40 -0000 Ladislav Lhotka wrote: > Martin Bjorklund píše v Út 05. 01. 2010 v 23:09 +0100: > >>>> The simplest change would be to have a "yang" namespace with "insert", >>>> "key", and "value" as elements of that namespace. Then we'd require >>>> that these elements appear first under the parent element. This would >>>> allow a simpler solution for multiple keys: >>>> >>>> >>>> before >>>> >>>> 10.1.2.0/24 >>>> or-longer >>>> >>>> 10.1.1.0/24 >>>> exact >>>> >>>> >>>> (assuming "list prefix" is "key 'name type'"). >>> Where would the edit-config "operation" attribute be? >> Just as with the attribute solution - in the element. > > Hmm, this is not very nice, it would then be much better to have the > NETCONF operation as a subelement, too, and encapsulate the additional > info inside it. > I am strongly opposed to changing the insert operation at this late date. If YANG needs to redo the NETCONF protocol this drastically, then the entire operation should be dropped, and perhaps put into the NETCONF protocol some time in the future. I don't really understand why the YANG data modeling language needs to define new NETCONF protocol operations in the first place. It seems like the NETCONF WG should be defining an 'insert' operation if it was that important. Andy >>>>> 13. Sec. 7.12: >>>>> OLD >>>>> The identifiers defined in the grouping are not bound to a namespace >>>>> until the contents of the grouping are added to the schema tree via a >>>>> "uses" statement that does not appear inside a "grouping" statement, >>>>> at which point they are bound to the namespace of the current module. >>>>> NEW >>>>> The identifiers defined or unqualified names used in the grouping >>>>> are not bound to a namespace until the contents of the grouping are >>>>> added to the schema tree via a "uses" statement that does not >>>>> appear inside a "grouping" statement, at which point they are bound >>>>> to the namespace of the current module. >>>> This is not true. Unqualified names used in a grouping are resolved >>>> in the place where the grouping is defined, not where it is used. >>> grouping ggg { >>> leaf foo { >>> type uint8; >>> } >>> leaf bar { >>> type uint8; >>> must ". < ../foo"; >>> } >>> >>> I think we agreed that both the definition and use of "foo" get the >>> namespace of the module where the grouping is used. >> We did, and that's specified in 6.4.1 *for XPath expressions*. >> >> However, unqualified type references (etc) are resolved where the >> grouping is defined, as described in 7.11: >> >> Identifiers appearing inside the grouping are resolved relative to >> the scope in which the grouping is defined, not where it is used. > > Does this mean that "foo" inside the XPath expression in my example is > bound to the namespace of the module where "ggg" is defined? I hope not. > > Lada > >> So the original text, which did not mention the usage of names, is >> actually correct, and the text already specifies how unqualified >> names are resolved. >> >> >> /martin > > From mbj@tail-f.com Wed Jan 6 01:18:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9503A6853 for ; Wed, 6 Jan 2010 01:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaMUbKGMP3U7 for ; Wed, 6 Jan 2010 01:18:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 04EF73A67E4 for ; Wed, 6 Jan 2010 01:18:26 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 91EB976C680; Wed, 6 Jan 2010 10:18:24 +0100 (CET) Date: Wed, 06 Jan 2010 10:17:42 +0100 (CET) Message-Id: <20100106.101742.250243724.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201001060000.o0600r4A089192@idle.juniper.net> References: <20100105.230917.154923876.mbj@tail-f.com> <201001060000.o0600r4A089192@idle.juniper.net> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 09:18:28 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >I agree with Lada, we should follow the W3C terminology. > > The new terminology is verbose and IMHO does more harm > than good. Are we willing to s/prefix/namespace prefix/ > and s/element name/element local name/ (or whatever the > new term is) throughout the entire YANG spec? I think the term "local name" is an improvement. "namespace name" not so much. - Is that Phil over there? - No no, it's the person with the name Phil. So how about this (in 7 places): OLD: A leaf node is encoded as an XML element. The element's name is the leaf's identifier, and its XML namespace is the module's XML namespace. NEW: A leaf node is encoded as an XML element. The element's local name is the leaf's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). /martin From mbj@tail-f.com Wed Jan 6 01:30:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306573A679C for ; Wed, 6 Jan 2010 01:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_BACKHAIR_53=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1FyKU+8NaRM for ; Wed, 6 Jan 2010 01:30:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 700463A676A for ; Wed, 6 Jan 2010 01:30:23 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A5F0276C680; Wed, 6 Jan 2010 10:30:21 +0100 (CET) Date: Wed, 06 Jan 2010 10:29:39 +0100 (CET) Message-Id: <20100106.102939.152175197.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B44535C.5010902@iwl.com> References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: phil@idle.juniper.net, netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 09:30:25 -0000 QW5keSBCaWVybWFuIDxhbmR5YkBpd2wuY29tPiB3cm90ZToNCj4gTGFkaXNsYXYgTGhvdGthIHdy b3RlOg0KPiA+IE1hcnRpbiBCam9ya2x1bmQgcMOtxaFlIHYgw5p0IDA1LiAwMS4gMjAxMCB2IDIz OjA5ICswMTAwOg0KPiA+IA0KPiA+Pj4+IFRoZSBzaW1wbGVzdCBjaGFuZ2Ugd291bGQgYmUgdG8g aGF2ZSBhICJ5YW5nIiBuYW1lc3BhY2Ugd2l0aCAiaW5zZXJ0IiwNCj4gPj4+PiAia2V5IiwgYW5k ICJ2YWx1ZSIgYXMgZWxlbWVudHMgb2YgdGhhdCBuYW1lc3BhY2UuICBUaGVuIHdlJ2QgcmVxdWly ZQ0KPiA+Pj4+IHRoYXQgdGhlc2UgZWxlbWVudHMgYXBwZWFyIGZpcnN0IHVuZGVyIHRoZSBwYXJl bnQgZWxlbWVudC4gIFRoaXMgd291bGQNCj4gPj4+PiBhbGxvdyBhIHNpbXBsZXIgc29sdXRpb24g Zm9yIG11bHRpcGxlIGtleXM6DQo+ID4+Pj4NCj4gPj4+PiAgICAgPHByZWZpeD4NCj4gPj4+PiAg ICAgICAgPHlhbmc6aW5zZXJ0PmJlZm9yZTwveWFuZzppbnNlcnQ+DQo+ID4+Pj4gICAgICAgIDx5 YW5nOmtleXM+DQo+ID4+Pj4gICAgICAgICAgIDxuYW1lPjEwLjEuMi4wLzI0PC9uYW1lPg0KPiA+ Pj4+ICAgICAgICAgICA8dHlwZT5vci1sb25nZXI8L3R5cGU+DQo+ID4+Pj4gICAgICAgIDwveWFu ZzprZXlzPg0KPiA+Pj4+ICAgICAgICA8bmFtZT4xMC4xLjEuMC8yNDwvbmFtZT4NCj4gPj4+PiAg ICAgICAgPHR5cGU+ZXhhY3Q8L3R5cGU+DQo+ID4+Pj4gICAgIDwvcHJlZml4Pg0KPiA+Pj4+DQo+ ID4+Pj4gKGFzc3VtaW5nICJsaXN0IHByZWZpeCIgaXMgImtleSAnbmFtZSB0eXBlJyIpLg0KPiA+ Pj4gV2hlcmUgd291bGQgdGhlIGVkaXQtY29uZmlnICJvcGVyYXRpb24iIGF0dHJpYnV0ZSBiZT8N Cj4gPj4gSnVzdCBhcyB3aXRoIHRoZSBhdHRyaWJ1dGUgc29sdXRpb24gLSBpbiB0aGUgPHByZWZp eD4gZWxlbWVudC4NCj4gPiANCj4gPiBIbW0sIHRoaXMgaXMgbm90IHZlcnkgbmljZSwgaXQgd291 bGQgdGhlbiBiZSBtdWNoIGJldHRlciB0byBoYXZlIHRoZQ0KPiA+IE5FVENPTkYgb3BlcmF0aW9u IGFzIGEgc3ViZWxlbWVudCwgdG9vLCBhbmQgZW5jYXBzdWxhdGUgdGhlIGFkZGl0aW9uYWwNCj4g PiBpbmZvIGluc2lkZSBpdC4NCj4gPiANCj4gDQo+IEkgYW0gc3Ryb25nbHkgb3Bwb3NlZCB0byBj aGFuZ2luZyB0aGUgaW5zZXJ0IG9wZXJhdGlvbg0KPiBhdCB0aGlzIGxhdGUgZGF0ZS4NCg0KSWYg d2UgaGF2ZSBpZGVudGlmaWVkIGEgcHJvYmxlbSwgc2hvdWxkbid0IHdlIHRyeSB0byBmaXggaXQ/ DQoNCk9uZSBwcm9ibGVtIHdpdGggdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIHRoYXQgaXQgaXMg YXdrd2FyZCBmb3INCmxlYWYtbGlzdHM6DQoNCiAgICAgPGFsbG93LXVzZXI+PHlhbmc6aW5zZXJ0 PmJlZm9yZTwveWFuZzppbnNlcnQ+PHlhbmc6dmFsdWU+YWxpY2U8L3lhbmc6dmFsdWU+Ym9iPC9h bGxvdy11c2VyPg0KDQpOb3RlIHRoYXQgdGhpcyBpcyBub3QgdGhlIHNhbWU6DQoNCiAgICAgPGFs bG93LXVzZXI+DQogICAgICAgPHlhbmc6aW5zZXJ0PmJlZm9yZTwveWFuZzppbnNlcnQ+DQogICAg ICAgPHlhbmc6dmFsdWU+YWxpY2U8L3lhbmc6dmFsdWU+DQogICAgICAgYm9iDQogICAgIDwvYWxs b3ctdXNlcj4NCg0KPiBJZiBZQU5HIG5lZWRzIHRvIHJlZG8gdGhlIE5FVENPTkYgcHJvdG9jb2wN Cj4gdGhpcyBkcmFzdGljYWxseSwgdGhlbiB0aGUgZW50aXJlIG9wZXJhdGlvbiBzaG91bGQgYmUg ZHJvcHBlZCwNCj4gYW5kIHBlcmhhcHMgcHV0IGludG8gdGhlIE5FVENPTkYgcHJvdG9jb2wgc29t ZSB0aW1lIGluIHRoZSBmdXR1cmUuDQo+IA0KPiBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHdo eSB0aGUgWUFORyBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlDQo+IG5lZWRzIHRvIGRlZmluZSBuZXcg TkVUQ09ORiBwcm90b2NvbCBvcGVyYXRpb25zIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gSXQgc2Vl bXMgbGlrZSB0aGUgTkVUQ09ORiBXRyBzaG91bGQgYmUgZGVmaW5pbmcgYW4gJ2luc2VydCcNCj4g b3BlcmF0aW9uIGlmIGl0IHdhcyB0aGF0IGltcG9ydGFudC4NCg0KWUFORyBuZWVkcyB0byBkZWZp bmUgdGhlIGluc2VydCBvcGVyYXRpb24gYmVjYXVzZSBpdCBpcyB0aWdodGx5DQpjb3VwbGVkIHRv IHRoZSBkYXRhIG1vZGVsLiAgSXQgaXMgbm90IGEgZ2VuZXJpYyBORVRDT05GIG9wZXJhdGlvbi4g IEl0DQpjYW4gb25seSBiZSB1c2VkIGZvciBvcmRlcmVkLWJ5IHVzZXIgbGlzdHMuICBPdGhlciBk YXRhIG1vZGVsbGluZw0KbGFuZ3VhZ2VzIG1heSBpbnRyb2R1Y2UgdGhlaXIgb3duIHNwZWNpYWwg b3BlcmF0aW9ucyB0byBoYW5kbGUgdGhlaXINCnNwZWNpYWwgbmVlZHMuDQoNCg0KL21hcnRpbg0K From andyb@iwl.com Wed Jan 6 01:36:54 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441043A67AC for ; Wed, 6 Jan 2010 01:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_53=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRGt7mtoPOTl for ; Wed, 6 Jan 2010 01:36:53 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 78B043A67A2 for ; Wed, 6 Jan 2010 01:36:53 -0800 (PST) Received: from relay1.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay1.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 35DB41278763; Wed, 6 Jan 2010 04:36:52 -0500 (EST) Received: by relay1.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id CC2FA1278717; Wed, 6 Jan 2010 04:36:51 -0500 (EST) Message-ID: <4B4459C4.7060404@iwl.com> Date: Wed, 06 Jan 2010 01:37:08 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> In-Reply-To: <20100106.102939.152175197.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: phil@idle.juniper.net, netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 09:36:54 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Ladislav Lhotka wrote: >>> Martin Bjorklund píše v Út 05. 01. 2010 v 23:09 +0100: >>> >>>>>> The simplest change would be to have a "yang" namespace with "insert", >>>>>> "key", and "value" as elements of that namespace. Then we'd require >>>>>> that these elements appear first under the parent element. This would >>>>>> allow a simpler solution for multiple keys: >>>>>> >>>>>> >>>>>> before >>>>>> >>>>>> 10.1.2.0/24 >>>>>> or-longer >>>>>> >>>>>> 10.1.1.0/24 >>>>>> exact >>>>>> >>>>>> >>>>>> (assuming "list prefix" is "key 'name type'"). >>>>> Where would the edit-config "operation" attribute be? >>>> Just as with the attribute solution - in the element. >>> Hmm, this is not very nice, it would then be much better to have the >>> NETCONF operation as a subelement, too, and encapsulate the additional >>> info inside it. >>> >> I am strongly opposed to changing the insert operation >> at this late date. > > If we have identified a problem, shouldn't we try to fix it? > We could remove the insert operation entirely, and add it to the protocol in a proper form. I do not agree that this is a significant problem. The use of whitespace in identifiers is extremely rare. Even if that happens, the entire list can be replaced, and the insert operation not used at all. > One problem with the proposed solution is that it is awkward for > leaf-lists: > > beforealicebob > > Note that this is not the same: > > > before > alice > bob > > >> If YANG needs to redo the NETCONF protocol >> this drastically, then the entire operation should be dropped, >> and perhaps put into the NETCONF protocol some time in the future. >> >> I don't really understand why the YANG data modeling language >> needs to define new NETCONF protocol operations in the first place. >> It seems like the NETCONF WG should be defining an 'insert' >> operation if it was that important. > > YANG needs to define the insert operation because it is tightly > coupled to the data model. It is not a generic NETCONF operation. It > can only be used for ordered-by user lists. Other data modelling > languages may introduce their own special operations to handle their > special needs. > I do not buy this argument. There is nothing YANG specific about an insert operation. The concept of multiple elements, and the need to control the order of instances of these elements, is not specific to YANG. > > /martin Andy From j.schoenwaelder@jacobs-university.de Wed Jan 6 01:46:57 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C970E3A679C for ; Wed, 6 Jan 2010 01:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G74DpQUGjiG for ; Wed, 6 Jan 2010 01:46:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B54CD3A6768 for ; Wed, 6 Jan 2010 01:46:56 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5058FC0025; Wed, 6 Jan 2010 10:46:55 +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 0PO-lGNKKlIQ; Wed, 6 Jan 2010 10:46:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4218CC0022; Wed, 6 Jan 2010 10:46:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2A70FB000E; Wed, 6 Jan 2010 10:46:50 +0100 (CET) Date: Wed, 6 Jan 2010 10:46:50 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100106094650.GB36828@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "phil@idle.juniper.net" , "netmod@ietf.org" References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> <4B4459C4.7060404@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4459C4.7060404@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" , "phil@idle.juniper.net" Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 06 Jan 2010 09:46:57 -0000 On Wed, Jan 06, 2010 at 10:37:08AM +0100, Andy Bierman wrote: > >> I don't really understand why the YANG data modeling language > >> needs to define new NETCONF protocol operations in the first place. > >> It seems like the NETCONF WG should be defining an 'insert' > >> operation if it was that important. > > > > YANG needs to define the insert operation because it is tightly > > coupled to the data model. It is not a generic NETCONF operation. It > > can only be used for ordered-by user lists. Other data modelling > > languages may introduce their own special operations to handle their > > special needs. > > I do not buy this argument. > There is nothing YANG specific about > an insert operation. The concept of multiple > elements, and the need to control the order of instances > of these elements, is not specific to YANG. I tend to agree with Andy that technically a better solution would be a generic "improvement" of the edit-config operation. Procedurally, NETCONF is not chartered to do NETCONF 1.1 and this makes it somewhat problematic to implement this "improvement" in NETCONF soon... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jan 6 05:50:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FB63A6864 for ; Wed, 6 Jan 2010 05:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6PYMaulyaOH for ; Wed, 6 Jan 2010 05:50:30 -0800 (PST) Received: from smtp175.iad.emailsrvr.com (smtp175.iad.emailsrvr.com [207.97.245.175]) by core3.amsl.com (Postfix) with ESMTP id 0939B3A6800 for ; Wed, 6 Jan 2010 05:50:30 -0800 (PST) Received: from relay17.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E28B51B96A7; Wed, 6 Jan 2010 08:50:27 -0500 (EST) Received: by relay17.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6FC9F1B962B; Wed, 6 Jan 2010 08:50:27 -0500 (EST) Message-ID: <4B449534.6080004@iwl.com> Date: Wed, 06 Jan 2010 05:50:44 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "phil@idle.juniper.net" , "netmod@ietf.org" References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> <4B4459C4.7060404@iwl.com> <20100106094650.GB36828@elstar.local> In-Reply-To: <20100106094650.GB36828@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 13:50:31 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 06, 2010 at 10:37:08AM +0100, Andy Bierman wrote: > >>>> I don't really understand why the YANG data modeling language >>>> needs to define new NETCONF protocol operations in the first place. >>>> It seems like the NETCONF WG should be defining an 'insert' >>>> operation if it was that important. >>> YANG needs to define the insert operation because it is tightly >>> coupled to the data model. It is not a generic NETCONF operation. It >>> can only be used for ordered-by user lists. Other data modelling >>> languages may introduce their own special operations to handle their >>> special needs. >> I do not buy this argument. >> There is nothing YANG specific about >> an insert operation. The concept of multiple >> elements, and the need to control the order of instances >> of these elements, is not specific to YANG. > > I tend to agree with Andy that technically a better solution would > be a generic "improvement" of the edit-config operation. Procedurally, > NETCONF is not chartered to do NETCONF 1.1 and this makes it somewhat > problematic to implement this "improvement" in NETCONF soon... > I do not think the problem statement is very compelling, and also the proposed solution (AFAIK w/o any real details) is complicated and a massive change to the spec that may have ripple effects -- it certainly would need another 2 months to write and review such a large change. 1) the insert operation is already redundant. One could use a replace operation. It causes more bytes of XML to be transfered, but so what? 2) The 'problem' with attributes here is that if list keys or leaf-list nodes differ in value only in the consecutive whitespace characters, such that when the whitespace is normalized, the strings are the same. IMO this is not a real problem and even if it was, there is a workaround to the insert operation already. > /js > Andy From andyb@iwl.com Wed Jan 6 06:18:08 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053593A681E for ; Wed, 6 Jan 2010 06:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfbu6vvz8JNM for ; Wed, 6 Jan 2010 06:18:07 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 49CB63A6850 for ; Wed, 6 Jan 2010 06:18:07 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 68C1F13D32C4; Wed, 6 Jan 2010 09:18:05 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1C36E13D32AF; Wed, 6 Jan 2010 09:18:05 -0500 (EST) Message-ID: <4B449BAE.5010002@iwl.com> Date: Wed, 06 Jan 2010 06:18:22 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Martin Bjorklund , "phil@idle.juniper.net" , "netmod@ietf.org" References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> <4B4459C4.7060404@iwl.com> <20100106094650.GB36828@elstar.local> In-Reply-To: <20100106094650.GB36828@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 14:18:08 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 06, 2010 at 10:37:08AM +0100, Andy Bierman wrote: > >>>> I don't really understand why the YANG data modeling language >>>> needs to define new NETCONF protocol operations in the first place. >>>> It seems like the NETCONF WG should be defining an 'insert' >>>> operation if it was that important. >>> YANG needs to define the insert operation because it is tightly >>> coupled to the data model. It is not a generic NETCONF operation. It >>> can only be used for ordered-by user lists. Other data modelling >>> languages may introduce their own special operations to handle their >>> special needs. >> I do not buy this argument. >> There is nothing YANG specific about >> an insert operation. The concept of multiple >> elements, and the need to control the order of instances >> of these elements, is not specific to YANG. > > I tend to agree with Andy that technically a better solution would > be a generic "improvement" of the edit-config operation. Procedurally, > NETCONF is not chartered to do NETCONF 1.1 and this makes it somewhat > problematic to implement this "improvement" in NETCONF soon... > quick question -- why can't the client use character entities in the key/value attributes to represent whitespace that needs to exactly match the whitespace in the database? > /js > Andy From lhotka@cesnet.cz Wed Jan 6 06:24:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091E83A685A for ; Wed, 6 Jan 2010 06:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0W0+wNHW4su for ; Wed, 6 Jan 2010 06:24:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3183D3A6849 for ; Wed, 6 Jan 2010 06:24:15 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 37B8CD800EF; Wed, 6 Jan 2010 15:24:13 +0100 (CET) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4B449534.6080004@iwl.com> References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> <4B4459C4.7060404@iwl.com> <20100106094650.GB36828@elstar.local> <4B449534.6080004@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Jan 2010 15:24:11 +0100 Message-ID: <1262787851.12822.267.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" , "phil@idle.juniper.net" Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 14:24:16 -0000 Andy Bierman píše v St 06. 01. 2010 v 05:50 -0800: > 1) the insert operation is already redundant. > One could use a replace operation. It causes more > bytes of XML to be transfered, but so what? The problem of "yang:value" normalization is the same for replace operation. > > 2) The 'problem' with attributes here is that if list keys > or leaf-list nodes differ in value only in the > consecutive whitespace characters, such that when the > whitespace is normalized, the strings are the same. > IMO this is not a real problem and even if it was, > there is a workaround to the insert operation already. The normalization also affects character and entity references. Lada > > > /js > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Jan 6 06:35:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7E23A686B for ; Wed, 6 Jan 2010 06:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHFWqOA58Wc7 for ; Wed, 6 Jan 2010 06:35:05 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id C39C43A6849 for ; Wed, 6 Jan 2010 06:35:04 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 2C64ED800F1; Wed, 6 Jan 2010 15:35:03 +0100 (CET) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4B449BAE.5010002@iwl.com> References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> <4B4459C4.7060404@iwl.com> <20100106094650.GB36828@elstar.local> <4B449BAE.5010002@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 06 Jan 2010 15:35:01 +0100 Message-ID: <1262788501.12822.274.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" , "phil@idle.juniper.net" Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 14:35:05 -0000 Andy Bierman píše v St 06. 01. 2010 v 06:18 -0800: > Juergen Schoenwaelder wrote: > > On Wed, Jan 06, 2010 at 10:37:08AM +0100, Andy Bierman wrote: > > > >>>> I don't really understand why the YANG data modeling language > >>>> needs to define new NETCONF protocol operations in the first place. > >>>> It seems like the NETCONF WG should be defining an 'insert' > >>>> operation if it was that important. > >>> YANG needs to define the insert operation because it is tightly > >>> coupled to the data model. It is not a generic NETCONF operation. It > >>> can only be used for ordered-by user lists. Other data modelling > >>> languages may introduce their own special operations to handle their > >>> special needs. > >> I do not buy this argument. > >> There is nothing YANG specific about > >> an insert operation. The concept of multiple > >> elements, and the need to control the order of instances > >> of these elements, is not specific to YANG. > > > > I tend to agree with Andy that technically a better solution would > > be a generic "improvement" of the edit-config operation. Procedurally, > > NETCONF is not chartered to do NETCONF 1.1 and this makes it somewhat > > problematic to implement this "improvement" in NETCONF soon... > > > > quick question -- why can't the client use character entities > in the key/value attributes to represent whitespace that needs > to exactly match the whitespace in the database? Yes, this could actually work, if the client is careful enough - even with the tab character. So maybe it's not a real issue after all. Lada > > > > /js > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Wed Jan 6 07:21:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1240E3A6896 for ; Wed, 6 Jan 2010 07:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C-QD1UphMcB for ; Wed, 6 Jan 2010 07:21:11 -0800 (PST) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 45FB83A684F for ; Wed, 6 Jan 2010 07:21:11 -0800 (PST) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id CB6F33EF23A; Wed, 6 Jan 2010 10:21:09 -0500 (EST) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 7E1183EF1EA; Wed, 6 Jan 2010 10:21:09 -0500 (EST) Message-ID: <4B44AA76.5010309@iwl.com> Date: Wed, 06 Jan 2010 07:21:26 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20100105.230917.154923876.mbj@tail-f.com> <1262763472.12822.27.camel@missotis> <4B44535C.5010902@iwl.com> <20100106.102939.152175197.mbj@tail-f.com> <4B4459C4.7060404@iwl.com> <20100106094650.GB36828@elstar.local> <4B449BAE.5010002@iwl.com> <1262788501.12822.274.camel@missotis> In-Reply-To: <1262788501.12822.274.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" , "phil@idle.juniper.net" Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:21:12 -0000 Ladislav Lhotka wrote: > Andy Bierman píše v St 06. 01. 2010 v 06:18 -0800: >> Juergen Schoenwaelder wrote: >>> On Wed, Jan 06, 2010 at 10:37:08AM +0100, Andy Bierman wrote: >>> >>>>>> I don't really understand why the YANG data modeling language >>>>>> needs to define new NETCONF protocol operations in the first place. >>>>>> It seems like the NETCONF WG should be defining an 'insert' >>>>>> operation if it was that important. >>>>> YANG needs to define the insert operation because it is tightly >>>>> coupled to the data model. It is not a generic NETCONF operation. It >>>>> can only be used for ordered-by user lists. Other data modelling >>>>> languages may introduce their own special operations to handle their >>>>> special needs. >>>> I do not buy this argument. >>>> There is nothing YANG specific about >>>> an insert operation. The concept of multiple >>>> elements, and the need to control the order of instances >>>> of these elements, is not specific to YANG. >>> I tend to agree with Andy that technically a better solution would >>> be a generic "improvement" of the edit-config operation. Procedurally, >>> NETCONF is not chartered to do NETCONF 1.1 and this makes it somewhat >>> problematic to implement this "improvement" in NETCONF soon... >>> >> quick question -- why can't the client use character entities >> in the key/value attributes to represent whitespace that needs >> to exactly match the whitespace in the database? > > Yes, this could actually work, if the client is careful enough - even > with the tab character. So maybe it's not a real issue after all. > The client already has to make sure it replaces " with " when encoding an attribute, so why not replace space and tab also? > Lada > >> >>> /js >>> >> Andy Andy From phil@juniper.net Wed Jan 6 11:22:00 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8940728C154 for ; Wed, 6 Jan 2010 11:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f--bS5GqAW8 for ; Wed, 6 Jan 2010 11:21:59 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 927EA28C13A for ; Wed, 6 Jan 2010 11:21:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKS0Ti0gZ3UjKMuIt/stnm0xjniUaRimyv@postini.com; Wed, 06 Jan 2010 11:21:58 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 6 Jan 2010 11:11:37 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 11:11:37 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 11:11:37 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 11:11:36 -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 o06JBZj50679; Wed, 6 Jan 2010 11:11:35 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o06IuKYm058357; Wed, 6 Jan 2010 18:56:21 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001061856.o06IuKYm058357@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1262763682.12822.30.camel@missotis> Date: Wed, 6 Jan 2010 13:56:20 -0500 From: Phil Shafer X-OriginalArrivalTime: 06 Jan 2010 19:11:36.0781 (UTC) FILETIME=[1162CFD0:01CA8F04] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:22:00 -0000 Ladislav Lhotka writes: >How about "reusable sets"? Only leafs have types in YANG. "reusable collections"? Thanks, Phil From lhotka@cesnet.cz Wed Jan 6 22:51:01 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB8E3A6866 for ; Wed, 6 Jan 2010 22:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.051 X-Spam-Level: X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLUlEBiTUYQ1 for ; Wed, 6 Jan 2010 22:51:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CD0453A67A4 for ; Wed, 6 Jan 2010 22:51:00 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 7BD96D800E8; Thu, 7 Jan 2010 07:50:58 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201001061856.o06IuKYm058357@idle.juniper.net> References: <201001061856.o06IuKYm058357@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 07 Jan 2010 07:50:57 +0100 Message-ID: <1262847057.22024.0.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 06:51:01 -0000 Phil Shafer píše v St 06. 01. 2010 v 13:56 -0500: > Ladislav Lhotka writes: > >How about "reusable sets"? Only leafs have types in YANG. > > "reusable collections"? +1. Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jan 7 01:35:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057DC3A6808 for ; Thu, 7 Jan 2010 01:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uehlsacmsAoO for ; Thu, 7 Jan 2010 01:35:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0ED993A659A for ; Thu, 7 Jan 2010 01:35:28 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7125676C67F; Thu, 7 Jan 2010 10:35:26 +0100 (CET) Date: Thu, 07 Jan 2010 10:35:25 +0100 (CET) Message-Id: <20100107.103525.227020912.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1262788501.12822.274.camel@missotis> References: <20100106094650.GB36828@elstar.local> <4B449BAE.5010002@iwl.com> <1262788501.12822.274.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 09:35:30 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFu IHDDrcWhZSB2IFN0IDA2LiAwMS4gMjAxMCB2IDA2OjE4IC0wODAwOg0KPiA+IHF1aWNrIHF1ZXN0 aW9uIC0tIHdoeSBjYW4ndCB0aGUgY2xpZW50IHVzZSBjaGFyYWN0ZXIgZW50aXRpZXMNCj4gPiBp biB0aGUga2V5L3ZhbHVlIGF0dHJpYnV0ZXMgdG8gcmVwcmVzZW50IHdoaXRlc3BhY2UgdGhhdCBu ZWVkcw0KPiA+IHRvIGV4YWN0bHkgbWF0Y2ggdGhlIHdoaXRlc3BhY2UgaW4gdGhlIGRhdGFiYXNl Pw0KPiANCj4gWWVzLCB0aGlzIGNvdWxkIGFjdHVhbGx5IHdvcmssIGlmIHRoZSBjbGllbnQgaXMg Y2FyZWZ1bCBlbm91Z2gNCg0KV2hpY2gsIGFzIGl0IHR1cm5zIG91dCwgZS5nLiB0aGUgZnVuY3Rp b24gcXVvdGVhdHRyIGluDQp4bWwuc2F4LnNheHV0aWxzIGluIFB5dGhvbiBkb2VzLg0KDQo+IC0g ZXZlbiB3aXRoIHRoZSB0YWIgY2hhcmFjdGVyLiBTbyBtYXliZSBpdCdzIG5vdCBhIHJlYWwgaXNz dWUgYWZ0ZXIgYWxsLg0KDQpHb29kIQ0KDQpTbywgbWF5YmUgd2Ugc2hvdWxkIHJldmVydCB0aGUg cGVuZGluZyBjaGFuZ2VzIHRvIFlJTiBhcyB3ZWxsIC0tIHRoZXJlDQppcyBubyByZWFzb24gdG8g bWFrZSBlbGVtZW50cyBmb3Igb3RoZXIgYXJndW1lbnRzIHRoYW4gdGhlICd0ZXh0Jw0KYXJndW1l bnRzIChkZXNjcmlwdGlvbiwgcmVmZXJlbmNlLCBvcmdhbml6YXRpb24sIGNvbnRhY3QsDQplcnJv ci1tZXNzYWdlKS4NCg0KDQoNCi9tYXJ0aW4NCg== From mbj@tail-f.com Thu Jan 7 01:36:59 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4C53A6808 for ; Thu, 7 Jan 2010 01:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kay011CJ-Xv9 for ; Thu, 7 Jan 2010 01:36:58 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 261343A659A for ; Thu, 7 Jan 2010 01:36:58 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 514A176C67F; Thu, 7 Jan 2010 10:36:56 +0100 (CET) Date: Thu, 07 Jan 2010 10:36:56 +0100 (CET) Message-Id: <20100107.103656.57371538.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1262847057.22024.0.camel@missotis> References: <201001061856.o06IuKYm058357@idle.juniper.net> <1262847057.22024.0.camel@missotis> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 09:36:59 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAY2VzbmV0LmN6PiB3cm90ZToNCj4gUGhpbCBTaGFmZXIg cMOtxaFlIHYgU3QgMDYuIDAxLiAyMDEwIHYgMTM6NTYgLTA1MDA6DQo+ID4gTGFkaXNsYXYgTGhv dGthIHdyaXRlczoNCj4gPiA+SG93IGFib3V0ICJyZXVzYWJsZSBzZXRzIj8gT25seSBsZWFmcyBo YXZlIHR5cGVzIGluIFlBTkcuDQo+ID4gDQo+ID4gInJldXNhYmxlIGNvbGxlY3Rpb25zIj8NCj4g DQo+ICsxLiBMYWRhDQoNCk9MRDoNCg0KR3JvdXBzIG9mIG5vZGVzIGNhbiBiZSBhc3NlbWJsZWQg aW50byB0aGUgZXF1aXZhbGVudCBvZiBjb21wbGV4IHR5cGVzDQp1c2luZyB0aGUgImdyb3VwaW5n IiBzdGF0ZW1lbnQuDQoNCk5FVzoNCg0KR3JvdXBzIG9mIG5vZGVzIGNhbiBiZSBhc3NlbWJsZWQg aW50byByZXN1YWJsZSBjb2xsZWN0aW9ucw0KdXNpbmcgdGhlICJncm91cGluZyIgc3RhdGVtZW50 Lg0KDQoNCg0KL21hcnRpbg0K From mbj@tail-f.com Thu Jan 7 02:26:24 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C153A6820 for ; Thu, 7 Jan 2010 02:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba4qrK4fY92U for ; Thu, 7 Jan 2010 02:26:23 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5494A28C150 for ; Thu, 7 Jan 2010 02:26:23 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 910CE76C6DB; Thu, 7 Jan 2010 11:26:21 +0100 (CET) Date: Thu, 07 Jan 2010 11:26:20 +0100 (CET) Message-Id: <20100107.112620.44109977.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100105.234747.137861106.mbj@tail-f.com> References: <20100105122737.GA34963@elstar.local> <20100105.234747.137861106.mbj@tail-f.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 10:26:24 -0000 Hi, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > * JS-01: > > > > In the terminology section, I think it would help if the text would > > spell out 'data node' or 'schema node' where it currently just says > > 'node' since data node and schema node are defined terms and node is > > not defined and also more ambiguous. This affects multiple > > I will get back on this one. These are the changes for this one: -- anyxml: A node which can contain an unknown chunk of XML data. +- anyxml: A data node which can contain an unknown chunk of XML data. -- augment: Adds new nodes to a previously defined node. +- augment: Adds new schema nodes to a previously defined schema node. -- choice: A node where only one of a number of identified - alternative nodes is valid. +- choice: A schema node where only one of a number of identified + alternatives is valid. -- container: An interior node in the data tree which exist in at most - one instance. A container node has no value, but rather a set of - child nodes. +- container: An interior data node which exists in at most one + instance in the data tree. A container has no value, but rather a + set of child nodes. -- extension: An extension attaches non-YANG semantics to nodes. The +- extension: An extension attaches non-YANG semantics to statements. The extension statement defines new statements to express these semantics. -- grouping: A reusable set of nodes, which may be used locally +- grouping: A reusable set of schema nodes, which may be used locally in the module, in modules which include it, and by other modules which import from it. The grouping statement is not a data definition statement and, as such, does not define any nodes in the -- leaf: A node in the data tree with a value but no child - nodes. +- leaf: A data node which exists in at most one instance in the data + tree. A leaf has a value but no child nodes. -- list: Interior nodes in the data tree which may exist in multiple - instances. A list node has no value, but rather a set of child +- list: An interior data node which may exist in multiple instances in + the data tree. A list has no value, but rather a set of child nodes. -- uses: The "uses" statement is used to instantiate the set of nodes - defined in a grouping statement. The instantiated nodes may be - refined and augmented to tailor them to any specific needs. +- uses: The "uses" statement is used to instantiate the set of schema + nodes defined in a grouping statement. The instantiated nodes may + be refined and augmented to tailor them to any specific needs. > > * JS-19: > > > > This text is somewhat unclear: > > > > When a datastore is validated, all "must" constraints are > > conceptually evaluated once for each corresponding instance in the > > data tree > > > > What is a 'corresponding instance'? I guess I know what the intent is > > behind the text but I see why someone new might get confused. Perhaps > > this is what was intended: > > > > When a datastore is validated, all "must" constraints are > > conceptually evaluated for each data node in the data tree > > matching a schema node holding a "must" statement. > > Hmm... do we need to explain what "matching" a schema node means? I > will think some more about this one. How about this: 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 ^leaf-default-value^). If an data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated. > > * JS-28: > > > > This might be wrong: > > > > The grouping statement is not a data definition statement and, as > > such, does not define any nodes in the schema tree. > > > > Perhaps you meant the data tree and not the schema tree. > > No it is correct - a grouping does not define a node in the schema > tree. > > Maybe the sentence should be removed. We should not list everything > we *don't* do. Actually, the sentence was added because someone wanted this clarification. I think we should keep it. /martin From j.schoenwaelder@jacobs-university.de Thu Jan 7 05:23:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092A53A6846 for ; Thu, 7 Jan 2010 05:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6UtDqFS3iPq for ; Thu, 7 Jan 2010 05:23:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AD0F53A6810 for ; Thu, 7 Jan 2010 05:23:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F39DC0033; Thu, 7 Jan 2010 14:23:37 +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 LzrlIaXipSrN; Thu, 7 Jan 2010 14:23:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14E76C0011; Thu, 7 Jan 2010 14:23:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BCC4FFB2B08; Thu, 7 Jan 2010 14:23:32 +0100 (CET) Date: Thu, 7 Jan 2010 14:23:32 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100107132332.GB39239@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20100105122737.GA34963@elstar.local> <20100105.234747.137861106.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100105.234747.137861106.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 13:23:40 -0000 On Tue, Jan 05, 2010 at 11:47:47PM +0100, Martin Bjorklund wrote: > > * JS-12: > > > > I fail to understand the purpose of section 5.7. This either needs to > > be rewritten or it should be removed. Here is the section: > > > > 5.7. Data Store Modification > > > > Data models may allow the server to alter the configuration data > > store. A formal mechanism for specifying the circumstances where > > these changes are allowed is out of scope for this specification. > > This was suggested in the thread "resolution of system-creatable > discussion". Ah, now I understand what this is trying to tell me. What about this rewrite: Data models may allow the server to alter the configuration data store while not processing NETCONF protocol messages affecting the data store. A formal mechanism for specifying the circumstances where these such changes to a configuration data store are allowed is out of scope for this specification. Perhaps this wording can be further improved. I was missing in the first sentence the hint that we talk about changes not initiated by NETCONF message processing. > > * JS-21: > > > > A usage examples that "creates a leaf" by using a "merge" may be > > confusing since a "merge" is not the same as a "create". (This affects > > section 7.6.8. and 7.7.8, perhaps other examples as well.) > > There are also some examples with operation create. I think it is > good to show both methods. Thats fine but then the text should in my view explain that such an example is a merge and not a create. > > * JS-28: > > > > This might be wrong: > > > > The grouping statement is not a data definition statement and, as > > such, does not define any nodes in the schema tree. > > > > Perhaps you meant the data tree and not the schema tree. > > No it is correct - a grouping does not define a node in the schema > tree. > > Maybe the sentence should be removed. We should not list everything > we *don't* do. Or reduce the sentence to "The grouping statement is not a data definition statement." > > * JS-33: > > > > I suggest to replace the very abstract even notification with > > something more down to earth. This is pretty much the high-level > > opaque stuff we prefer not to see in YANG data models. (At least > > this is my opinion. ;-) > > The example is from rfc 5277; it is just a YANG version of an example > there. But I am open to suggestions! We also have some other > examples in the document. But RFC 5277 is written in caml style. :) I would prefer a basic link-down notification example. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Thu Jan 7 05:47:15 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA9A3A67B0 for ; Thu, 7 Jan 2010 05:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqaqj+4Dto19 for ; Thu, 7 Jan 2010 05:47:15 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id BACB13A63D3 for ; Thu, 7 Jan 2010 05:47:14 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS0Xl3DiaJLlaq/TReZ3PVzhEUD3n315T@postini.com; Thu, 07 Jan 2010 05:47:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 7 Jan 2010 05:44:59 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 05:44:59 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 05:44:58 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 05:44:58 -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 o07Divj85918; Thu, 7 Jan 2010 05:44:57 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o07DTgMn067005; Thu, 7 Jan 2010 13:29:42 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001071329.o07DTgMn067005@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100107132332.GB39239@elstar.local> Date: Thu, 7 Jan 2010 08:29:42 -0500 From: Phil Shafer X-OriginalArrivalTime: 07 Jan 2010 13:44:58.0840 (UTC) FILETIME=[9A841580:01CA8F9F] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 13:47:15 -0000 Juergen Schoenwaelder writes: >Perhaps this wording can be further improved. I was missing in the >first sentence the hint that we talk about changes not initiated by >NETCONF message processing. The changes may be initiated by NETCONF message processing, but not be the exact change requested. Setting to 5 may set to 10. Or creating may create a . How about: Data models may allow the server to alter the configuration data store in ways not explicitly directed via NETCONF protocol messages. For example, a data model may define leafs that are assigned system-generated values when the client does not provide one. A formal mechanism for specifying the circumstances where these changes are allowed is out of scope for this specification. Thanks, Phil From j.schoenwaelder@jacobs-university.de Thu Jan 7 05:58:20 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990693A67B0 for ; Thu, 7 Jan 2010 05:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu-Rijh-bPvv for ; Thu, 7 Jan 2010 05:58:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9731A3A6784 for ; Thu, 7 Jan 2010 05:58:19 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0778C0035; Thu, 7 Jan 2010 14:58:17 +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 BPrZnLVbcLB4; Thu, 7 Jan 2010 14:58:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71D4AC0034; Thu, 7 Jan 2010 14:58:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DAA66FB2C25; Thu, 7 Jan 2010 14:58:13 +0100 (CET) Date: Thu, 7 Jan 2010 14:58:13 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100107135813.GC39239@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , "netmod@ietf.org" References: <20100107132332.GB39239@elstar.local> <201001071329.o07DTgMn067005@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001071329.o07DTgMn067005@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 13:58:20 -0000 On Thu, Jan 07, 2010 at 02:29:42PM +0100, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Perhaps this wording can be further improved. I was missing in the > >first sentence the hint that we talk about changes not initiated by > >NETCONF message processing. > > The changes may be initiated by NETCONF message processing, but not > be the exact change requested. Setting to 5 may set > to 10. Or creating may create a . How about: Good point. > Data models may allow the server to alter the configuration > data store in ways not explicitly directed via NETCONF protocol > messages. For example, a data model may define leafs that are > assigned system-generated values when the client does not provide > one. A formal mechanism for specifying the circumstances where > these changes are allowed is out of scope for this specification. Fine with me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jan 7 06:11:11 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D17C3A67F5 for ; Thu, 7 Jan 2010 06:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0vY1FkSwa0N for ; Thu, 7 Jan 2010 06:11:10 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E22393A67EA for ; Thu, 7 Jan 2010 06:11:09 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6BBCC76C6DB; Thu, 7 Jan 2010 15:11:07 +0100 (CET) Date: Thu, 07 Jan 2010 15:11:07 +0100 (CET) Message-Id: <20100107.151107.205711948.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100107135813.GC39239@elstar.local> References: <20100107132332.GB39239@elstar.local> <201001071329.o07DTgMn067005@idle.juniper.net> <20100107135813.GC39239@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:11:11 -0000 Juergen Schoenwaelder wrote: > > Data models may allow the server to alter the configuration > > data store in ways not explicitly directed via NETCONF protocol > > messages. For example, a data model may define leafs that are > > assigned system-generated values when the client does not provide > > one. A formal mechanism for specifying the circumstances where > > these changes are allowed is out of scope for this specification. > > Fine with me. +1. /martin From mbj@tail-f.com Thu Jan 7 06:28:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735923A6810 for ; Thu, 7 Jan 2010 06:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NDRHosdPoc9 for ; Thu, 7 Jan 2010 06:28:04 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 645543A67F3 for ; Thu, 7 Jan 2010 06:28:04 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7057476C6DB; Thu, 7 Jan 2010 15:28:02 +0100 (CET) Date: Thu, 07 Jan 2010 15:28:02 +0100 (CET) Message-Id: <20100107.152802.215191074.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100107132332.GB39239@elstar.local> References: <20100105122737.GA34963@elstar.local> <20100105.234747.137861106.mbj@tail-f.com> <20100107132332.GB39239@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:28:05 -0000 Juergen Schoenwaelder wrote: > > > * JS-21: > > > > > > A usage examples that "creates a leaf" by using a "merge" may be > > > confusing since a "merge" is not the same as a "create". (This affects > > > section 7.6.8. and 7.7.8, perhaps other examples as well.) > > > > There are also some examples with operation create. I think it is > > good to show both methods. > > Thats fine but then the text should in my view explain that such an > example is a merge and not a create. Ok. In 7.6.8: OLD: To create a leaf with an : NEW: To set the value of a leaf with an : And 7.7.8: OLD: To create a new element in the list: NEW: To create a new element in this list, using the default operation "merge": > > > * JS-28: > > > > > > This might be wrong: > > > > > > The grouping statement is not a data definition statement and, as > > > such, does not define any nodes in the schema tree. > > > > > > Perhaps you meant the data tree and not the schema tree. > > > > No it is correct - a grouping does not define a node in the schema > > tree. > > > > Maybe the sentence should be removed. We should not list everything > > we *don't* do. > > Or reduce the sentence to "The grouping statement is not a data > definition statement." I would prefer to keep the current text. IIRC it was requested by someone who reviewed the document. > > > * JS-33: > > > > > > I suggest to replace the very abstract even notification with > > > something more down to earth. This is pretty much the high-level > > > opaque stuff we prefer not to see in YANG data models. (At least > > > this is my opinion. ;-) > > > > The example is from rfc 5277; it is just a YANG version of an example > > there. But I am open to suggestions! We also have some other > > examples in the document. > > But RFC 5277 is written in caml style. :) I would prefer a basic > link-down notification example. We already have one 'link-failure' in the document. I don't want to copy&paste the same example twice. /martin From lhotka@cesnet.cz Thu Jan 7 08:30:29 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AEF3A689A for ; Thu, 7 Jan 2010 08:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfLLNIJDuLXK for ; Thu, 7 Jan 2010 08:30:28 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 8767F3A6809 for ; Thu, 7 Jan 2010 08:30:28 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 4B4D6D800C1; Thu, 7 Jan 2010 17:30:26 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100105.234747.137861106.mbj@tail-f.com> References: <20100105122737.GA34963@elstar.local> <20100105.234747.137861106.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 07 Jan 2010 17:30:24 +0100 Message-ID: <1262881824.22024.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:30:29 -0000 Martin Bjorklund píše v Út 05. 01. 2010 v 23:47 +0100: > > * JS-22: > > > > OLD > > > > Where the "leaf" statement is used to define a simple scalar variable > > of a particular type, the "leaf-list" statement is used to define an > > array of a particular type. > > > > NEW > > > > Where the "leaf" statement is used to define a simple scalar variable > > of a particular type, the "leaf-list" statement is used to define an > > ordered set of values of a particular type. > > > > The word "array" may be potentially confusing and is never used > > elsewhere in the document. > > "array" is used to distinguish it from "simple scalar varaible". I > think it is ok to use. I think "set" it more precise here because all values must be unique, which is normally not assumed for arrays. (But in fact also not for lists, so strictly speaking "leaf-set" would be a more appropriate name.) > > > * JS-23: > > > > The ordered-by statement takes as argument "user" or "system". The > > text in section 7.7.1 talks about user and the device. NETCONF itself > > has clients and servers. There might be meaning behind the decision of > > using all these different terms. But then the terminology section does > > not help with understanding the differences. Perhaps this really > > should have been 'ordered-by device'? Or declare that device and > > system are the same? > > I think 7.7.1 does that: > > In many lists, the order of list entries does not impact > the implementation of the list's configuration, and the device is > free to sort the list entries in any reasonable order. [...] YANG calls > this style of list "system ordered" and they are indicated with the > statement "ordered-by system". I also tend to think that "ordered-by server" and "ordered-by client" would be clearer. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Thu Jan 7 09:34:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6DC3A68D7 for ; Thu, 7 Jan 2010 09:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTM4kbvNIxQC for ; Thu, 7 Jan 2010 09:34:04 -0800 (PST) Received: from smtp205.iad.emailsrvr.com (smtp205.iad.emailsrvr.com [207.97.245.205]) by core3.amsl.com (Postfix) with ESMTP id 7CD253A68B7 for ; Thu, 7 Jan 2010 09:34:04 -0800 (PST) Received: from relay20.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B64691B6096; Thu, 7 Jan 2010 12:34:02 -0500 (EST) Received: by relay20.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4BEBE1B5F94; Thu, 7 Jan 2010 12:34:02 -0500 (EST) Message-ID: <4B461B1C.20308@iwl.com> Date: Thu, 07 Jan 2010 09:34:20 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ladislav Lhotka References: <20100105122737.GA34963@elstar.local> <20100105.234747.137861106.mbj@tail-f.com> <1262881824.22024.23.camel@missotis> In-Reply-To: <1262881824.22024.23.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:34:05 -0000 Ladislav Lhotka wrote: > I also tend to think that "ordered-by server" and "ordered-by client" > would be clearer. > If this was a review of -00, then I would agree that tweaking the terminology would be a good idea, even though it is a subjective process. IMO, 'system' is better because it suggests that the database order may indeed come from the HW within the system. The NETCONF server is just one component within the managed system. > Lada > Andy From j.schoenwaelder@jacobs-university.de Thu Jan 7 09:59:42 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCD13A681E for ; Thu, 7 Jan 2010 09:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUem15ms4oDA for ; Thu, 7 Jan 2010 09:59:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 42C4F3A6856 for ; Thu, 7 Jan 2010 09:59:41 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82B0CC0037; Thu, 7 Jan 2010 18:59: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 8VyKwUyW0OKn; Thu, 7 Jan 2010 18:59:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C72FBC0033; Thu, 7 Jan 2010 18:59:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C74A5FB3779; Thu, 7 Jan 2010 18:59:34 +0100 (CET) Date: Thu, 7 Jan 2010 18:59:34 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100107175934.GH39239@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20100105122737.GA34963@elstar.local> <20100105.234747.137861106.mbj@tail-f.com> <20100107.112620.44109977.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100107.112620.44109977.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of yang-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2010 17:59:42 -0000 On Thu, Jan 07, 2010 at 11:26:20AM +0100, Martin Bjorklund wrote: > Hi, > > Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > * JS-01: > > > > > > In the terminology section, I think it would help if the text would > > > spell out 'data node' or 'schema node' where it currently just says > > > 'node' since data node and schema node are defined terms and node is > > > not defined and also more ambiguous. This affects multiple > > > > I will get back on this one. > > These are the changes for this one: > > -- anyxml: A node which can contain an unknown chunk of XML data. > +- anyxml: A data node which can contain an unknown chunk of XML data. > > -- augment: Adds new nodes to a previously defined node. > +- augment: Adds new schema nodes to a previously defined schema node. > > -- choice: A node where only one of a number of identified > - alternative nodes is valid. > +- choice: A schema node where only one of a number of identified > + alternatives is valid. > > -- container: An interior node in the data tree which exist in at most > - one instance. A container node has no value, but rather a set of > - child nodes. > +- container: An interior data node which exists in at most one > + instance in the data tree. A container has no value, but rather a > + set of child nodes. > > -- extension: An extension attaches non-YANG semantics to nodes. The > +- extension: An extension attaches non-YANG semantics to statements. The > extension statement defines new statements to express these > semantics. > > -- grouping: A reusable set of nodes, which may be used locally > +- grouping: A reusable set of schema nodes, which may be used locally > in the module, in modules which include it, and by other > modules which import from it. The grouping statement is not a data > definition statement and, as such, does not define any nodes in the > > -- leaf: A node in the data tree with a value but no child > - nodes. > +- leaf: A data node which exists in at most one instance in the data > + tree. A leaf has a value but no child nodes. > > -- list: Interior nodes in the data tree which may exist in multiple > - instances. A list node has no value, but rather a set of child > +- list: An interior data node which may exist in multiple instances in > + the data tree. A list has no value, but rather a set of child > nodes. > > -- uses: The "uses" statement is used to instantiate the set of nodes > - defined in a grouping statement. The instantiated nodes may be > - refined and augmented to tailor them to any specific needs. > +- uses: The "uses" statement is used to instantiate the set of schema > + nodes defined in a grouping statement. The instantiated nodes may > + be refined and augmented to tailor them to any specific needs. Looks OK to me. > > > * JS-19: > > > > > > This text is somewhat unclear: > > > > > > When a datastore is validated, all "must" constraints are > > > conceptually evaluated once for each corresponding instance in the > > > data tree > > > > > > What is a 'corresponding instance'? I guess I know what the intent is > > > behind the text but I see why someone new might get confused. Perhaps > > > this is what was intended: > > > > > > When a datastore is validated, all "must" constraints are > > > conceptually evaluated for each data node in the data tree > > > matching a schema node holding a "must" statement. > > > > Hmm... do we need to explain what "matching" a schema node means? I > > will think some more about this one. > > How about this: > > 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 ^leaf-default-value^). > If an data node does not exist in the data tree, and it does not > have a default value, its "must" statements are not evaluated. OK > > > * JS-28: > > > > > > This might be wrong: > > > > > > The grouping statement is not a data definition statement and, as > > > such, does not define any nodes in the schema tree. > > > > > > Perhaps you meant the data tree and not the schema tree. > > > > No it is correct - a grouping does not define a node in the schema > > tree. > > > > Maybe the sentence should be removed. We should not list everything > > we *don't* do. > > Actually, the sentence was added because someone wanted this > clarification. I think we should keep it. Fine with me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Fri Jan 8 16:29:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F863A6407 for ; Fri, 8 Jan 2010 16:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvUu0s3smGRr for ; Fri, 8 Jan 2010 16:29:15 -0800 (PST) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 613773A6767 for ; Fri, 8 Jan 2010 16:29:15 -0800 (PST) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 1765C3EF24C for ; Fri, 8 Jan 2010 19:29:12 -0500 (EST) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id EDB493EF21D for ; Fri, 8 Jan 2010 19:29:11 -0500 (EST) Message-ID: <4B47CDD6.3070903@iwl.com> Date: Fri, 08 Jan 2010 16:29:10 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] anyxml-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:29:16 -0000 Hi, I'm not saying the draft needs to change... I'm just saying that when we changed anyxml from a type to its own object type, we lost the ability to define a leaf-list of type anyxml. I'm working on on a YANG module now where I needed that. The hack workaround is to define a list with no key and make the anyxml a child node. It's not very elegant. Andy From mbj@tail-f.com Sat Jan 9 05:42:00 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251DA3A679C for ; Sat, 9 Jan 2010 05:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7VWiGuQ0IQt for ; Sat, 9 Jan 2010 05:41:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5301F3A67B7 for ; Sat, 9 Jan 2010 05:41:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F56C616006; Sat, 9 Jan 2010 14:41:56 +0100 (CET) Date: Sat, 09 Jan 2010 14:41:02 +0100 (CET) Message-Id: <20100109.144102.96097125.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B47CDD6.3070903@iwl.com> References: <4B47CDD6.3070903@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] anyxml-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 13:42:00 -0000 Andy Bierman wrote: > Hi, > > I'm not saying the draft needs to change... > I'm just saying that when we changed anyxml > from a type to its own object type, we lost > the ability to define a leaf-list of type anyxml. I don't mind changing: An anyxml node exists in zero or one instances in the data tree. to: An anyxml node exists in zero or more instances in the data tree. Since it's an unknown chunk of XML, it doesn't really matter how many instances there are. > I'm working on on a YANG module now where I needed that. > The hack workaround is to define a list with no key > and make the anyxml a child node. It's not very elegant. As an alternative, maybe you can make the top-level anyxml a container, and stick your leafs underneath it: anyxml foo; 1 ... ... /martin From andyb@iwl.com Sat Jan 9 06:09:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02353A6783 for ; Sat, 9 Jan 2010 06:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBcCR4iJiJPI for ; Sat, 9 Jan 2010 06:09:52 -0800 (PST) Received: from smtp175.dfw.emailsrvr.com (smtp175.dfw.emailsrvr.com [67.192.241.175]) by core3.amsl.com (Postfix) with ESMTP id 03CB73A67EB for ; Sat, 9 Jan 2010 06:09:51 -0800 (PST) Received: from relay17.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 038A92C72414; Sat, 9 Jan 2010 09:09:50 -0500 (EST) Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id C85262C7240E; Sat, 9 Jan 2010 09:09:49 -0500 (EST) Message-ID: <4B488E2B.7090805@iwl.com> Date: Sat, 09 Jan 2010 06:09:47 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B47CDD6.3070903@iwl.com> <20100109.144102.96097125.mbj@tail-f.com> In-Reply-To: <20100109.144102.96097125.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] anyxml-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 14:09:52 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I'm not saying the draft needs to change... >> I'm just saying that when we changed anyxml >> from a type to its own object type, we lost >> the ability to define a leaf-list of type anyxml. > > I don't mind changing: > > An anyxml node exists in zero or one instances in the data tree. > > to: > > An anyxml node exists in zero or more instances in the data tree. > No -- I am worried that there is other text that will be affected by this change, not to mention code. I also like the symmetry of the YANG definitions: 0 or 1 0 or more simple leaf leaf-list complex container list The terminology is not consistent, but the control is there. (Personally, I like the instance control stuff in RelaxNG better than YANG (*,+,?), but that battle was lost a long time ago ;-) > Since it's an unknown chunk of XML, it doesn't really matter how many > instances there are. > >> I'm working on on a YANG module now where I needed that. >> The hack workaround is to define a list with no key >> and make the anyxml a child node. It's not very elegant. > > As an alternative, maybe you can make the top-level anyxml a > container, and stick your leafs underneath it: > > anyxml foo; > > > 1 > ... > ... > > > > /martin > Andy From andyb@iwl.com Mon Jan 11 10:21:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4641F3A6861 for ; Mon, 11 Jan 2010 10:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hi7JQErLAdQ for ; Mon, 11 Jan 2010 10:21:31 -0800 (PST) Received: from smtp175.dfw.emailsrvr.com (smtp175.dfw.emailsrvr.com [67.192.241.175]) by core3.amsl.com (Postfix) with ESMTP id 6347C3A6824 for ; Mon, 11 Jan 2010 10:21:31 -0800 (PST) Received: from relay17.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 561A32C70565; Mon, 11 Jan 2010 13:21:28 -0500 (EST) Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0E3462C7013D; Mon, 11 Jan 2010 13:21:28 -0500 (EST) Message-ID: <4B4B6C1E.1060809@iwl.com> Date: Mon, 11 Jan 2010 10:21:18 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20100106094650.GB36828@elstar.local> <4B449BAE.5010002@iwl.com> <1262788501.12822.274.camel@missotis> <20100107.103525.227020912.mbj@tail-f.com> In-Reply-To: <20100107.103525.227020912.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: [netmod] attribute encoding (was Re: review of yang-09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 18:21:32 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Andy Bierman píše v St 06. 01. 2010 v 06:18 -0800: >>> quick question -- why can't the client use character entities >>> in the key/value attributes to represent whitespace that needs >>> to exactly match the whitespace in the database? >> Yes, this could actually work, if the client is careful enough > > Which, as it turns out, e.g. the function quoteattr in > xml.sax.saxutils in Python does. > Let's nail down the exact text... > > < < " " & & \t Does ' ' get converted to   or   or   or Does \n get converted to or left alone? Do all other 'isspace(c)==true' characters get converted to &#num-c; Or do all other 'isprint(c)==false' characters get converted to &#num-c; >> - even with the tab character. So maybe it's not a real issue after all. > > Good! > > So, maybe we should revert the pending changes to YIN as well -- there > is no reason to make elements for other arguments than the 'text' > arguments (description, reference, organization, contact, > error-message). > put a stake in the ground and leave it there > > > /martin Andy From phil@juniper.net Mon Jan 11 10:38:02 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C41D3A6839 for ; Mon, 11 Jan 2010 10:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcECOR0r7uW8 for ; Mon, 11 Jan 2010 10:38:01 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 686043A63C9 for ; Mon, 11 Jan 2010 10:38:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKS0twAk5cS8C4gDg/m3ZpNZF0u56b+e0N@postini.com; Mon, 11 Jan 2010 10:37:59 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 11 Jan 2010 10:36:40 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 10:36:39 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 10:36:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 10:36:39 -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 o0BIacj01100; Mon, 11 Jan 2010 10:36:38 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o0BILJNl038168; Mon, 11 Jan 2010 18:21:19 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001111821.o0BILJNl038168@idle.juniper.net> To: andyb@iwl.com In-Reply-To: <4B4B6C1E.1060809@iwl.com> Date: Mon, 11 Jan 2010 13:21:19 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Jan 2010 18:36:39.0358 (UTC) FILETIME=[034A35E0:01CA92ED] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] attribute encoding (was Re: review of yang-09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 18:38:02 -0000 Andy Bierman writes: > Does ' ' get converted to   or   or   or   is not ' '. > Does \n get converted to or left alone? Can't leave it alone. > Do all other 'isspace(c)==true' characters get converted to &#num-c; > Or do all other 'isprint(c)==false' characters get converted to &#num-c; XML can't encode control characters, but we're DOA for those. Hmmmm.... Perhaps we just need to define "well known" entities for these? &c01; &c02; &c03; &c04; etc. Not being about to encode strings containing control characters is a problem that I'd like to see solved. I say this assuming that we don't need to explicitly declare these entities. 32 lines of would stink. >put a stake in the ground and leave it there We did. It moved. Let's move it back. Please revert those changes and let's limit ourselves to more serious issues. Thanks, Phil From andyb@iwl.com Mon Jan 11 11:09:07 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DF73A67FE for ; Mon, 11 Jan 2010 11:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhSUbFxS57lt for ; Mon, 11 Jan 2010 11:09:06 -0800 (PST) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id CD5503A681A for ; Mon, 11 Jan 2010 11:09:06 -0800 (PST) Received: from relay12.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5D5402080309; Mon, 11 Jan 2010 14:09:04 -0500 (EST) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1140E20802AE; Mon, 11 Jan 2010 14:09:04 -0500 (EST) Message-ID: <4B4B774B.1030804@iwl.com> Date: Mon, 11 Jan 2010 11:08:59 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <201001111821.o0BILJNl038168@idle.juniper.net> In-Reply-To: <201001111821.o0BILJNl038168@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] attribute encoding (was Re: review of yang-09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 19:09:07 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Does ' ' get converted to   or   or   or > >   is not ' '. > OK -- so is the answer. >> Does \n get converted to or left alone? > > Can't leave it alone. > OK >> Do all other 'isspace(c)==true' characters get converted to &#num-c; >> Or do all other 'isprint(c)==false' characters get converted to &#num-c; > > XML can't encode control characters, but we're DOA for those. Hmmmm.... > > Perhaps we just need to define "well known" entities for these? &c01; > &c02; &c03; &c04; etc. Not being about to encode strings containing > control characters is a problem that I'd like to see solved. > Why not just encode all unprintable chars as &#num; This seems to apply to element content as well. > I say this assuming that we don't need to explicitly declare these > entities. 32 lines of would stink. > >> put a stake in the ground and leave it there > > We did. It moved. Let's move it back. Please revert those changes > and let's limit ourselves to more serious issues. > the chart had a bug in it (which I found). Arbitrary choices tend to produce more debate than normal. 1 more XML question about whitespace... Is an XML parser expected to tidy up element whitespace (beyond leading and trailing whitespace). Let's say some leaf foo has some newlines in it: Hello world Hello YANG world Hello What if the XML is indented for easier reading: Hello world Hello YANG world Hello Does this alter the content as follows: Hello world Hello YANG world Hello OR Hello world Hello YANG world Hello Does the YANG text adjustment for double-quoted strings apply here? If not, should it? How important is it to preserve whitespace in YANG values? Is this a server-specified behavior or standard? Fixed or configurable? > Thanks, > Phil > Andy From phil@juniper.net Mon Jan 11 11:22:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074A93A691B for ; Mon, 11 Jan 2010 11:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfOw1ycZrPMS for ; Mon, 11 Jan 2010 11:22:50 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 615193A687D for ; Mon, 11 Jan 2010 11:22:50 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKS0t6ggKJJAt8KIRMD26RgK7wpeSg3fwI@postini.com; Mon, 11 Jan 2010 11:22:48 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 11 Jan 2010 11:19:26 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 11:19:26 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 11:19:25 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 11:19: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 o0BJJOj19349; Mon, 11 Jan 2010 11:19:24 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o0BJ45tx038726; Mon, 11 Jan 2010 19:04:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001111904.o0BJ45tx038726@idle.juniper.net> To: andyb@iwl.com In-Reply-To: <4B4B774B.1030804@iwl.com> Date: Mon, 11 Jan 2010 14:04:05 -0500 From: Phil Shafer X-OriginalArrivalTime: 11 Jan 2010 19:19:25.0638 (UTC) FILETIME=[FCE97660:01CA92F2] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] attribute encoding (was Re: review of yang-09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 19:22:52 -0000 Andy Bierman writes: >Why not just encode all unprintable chars as &#num; Discussed in an earlier thread, but the answer is because the XML authors made control characters illegal. The encoding does not matter; the content is still illegal: Idle % cat test.xml  Idle % xmllint test.xml test.xml:2: parser error : xmlParseCharRef: invalid xmlChar value 1  ^ test.xml:2: parser error : xmlParseCharRef: invalid xmlChar value 2  ^ test.xml:2: parser error : xmlParseCharRef: invalid xmlChar value 3  ^ test.xml:2: parser error : xmlParseCharRef: invalid xmlChar value 4  ^ Idle % >How important is it to preserve whitespace in YANG values? a b is different than a b. >Is this a server-specified behavior or standard? Fixed or configurable? Data model specific. Thanks, Phil From root@core3.amsl.com Tue Jan 12 00:45:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5B2E53A6883; Tue, 12 Jan 2010 00:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100112084501.5B2E53A6883@core3.amsl.com> Date: Tue, 12 Jan 2010 00:45:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 08:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-10.txt Pages : 181 Date : 2010-01-12 YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-12004203.I-D@ietf.org> --NextPart-- From david.partain@ericsson.com Tue Jan 12 23:07:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4263A68EC for ; Tue, 12 Jan 2010 23:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc-pn4csDkxd for ; Tue, 12 Jan 2010 23:07:52 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id ADAC83A698E for ; Tue, 12 Jan 2010 23:07:51 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-2d-4b4d71432273 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 31.12.04178.3417D4B4; Wed, 13 Jan 2010 08:07:47 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 08:07:19 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 08:07:18 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 13 Jan 2010 08:07:18 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001130807.18538.david.partain@ericsson.com> X-OriginalArrivalTime: 13 Jan 2010 07:07:18.0875 (UTC) FILETIME=[0B58DAB0:01CA941F] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 07:07:52 -0000 Dear all, This is a two-week working group last call on the current working group document: - Common YANG Data Types: http://tools.ietf.org/html/draft-ietf-netmod-yang-types-05.txt This WGLC will end on January 27, 2010. Please review the document and post your comments on the mailing list. Please use an appropriate Subject line so that the chairs and editor can easily keep track of the issues that need to be dealt with. Thanks. David^2 From remi.scavenius@wanadoo.fr Wed Jan 13 00:48:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D7F3A6A6A for ; Wed, 13 Jan 2010 00:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.227 X-Spam-Level: * X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_50=0.001, HELO_EQ_FR=0.35, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oGwz7VSU9cV for ; Wed, 13 Jan 2010 00:48:53 -0800 (PST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.48]) by core3.amsl.com (Postfix) with ESMTP id 750563A68DE for ; Wed, 13 Jan 2010 00:48:53 -0800 (PST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2114.orange.fr (SMTP Server) with ESMTP id EAA0C1C00D37; Wed, 13 Jan 2010 09:48:47 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2114.orange.fr (SMTP Server) with ESMTP id DB3F61C00F74; Wed, 13 Jan 2010 09:48:47 +0100 (CET) Received: from PCdeMonOrdina (ABordeaux-205-1-1-146.w80-15.abo.wanadoo.fr [80.15.5.146]) by mwinf2114.orange.fr (SMTP Server) with SMTP id 950EA1C00D37; Wed, 13 Jan 2010 09:42:40 +0100 (CET) X-ME-UUID: 20100113084240610.950EA1C00D37@mwinf2114.orange.fr Message-ID: From: "Remi Scavenius" To: "David Partain" , References: <201001130807.18538.david.partain@ericsson.com> In-Reply-To: <201001130807.18538.david.partain@ericsson.com> Date: Wed, 13 Jan 2010 09:42:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 08:48:56 -0000 Dear all, Just a few words for the Network Automation CFP, ending at the end of this month. I would gladly welcome papers proposals from IETF members involved in this process. http://www.upperside.fr/networkautomation2010/networkautomation2010intro.htm Best Remi Scavenius, agenda manager ----- Original Message ----- From: "David Partain" To: Sent: Wednesday, January 13, 2010 8:07 AM Subject: [netmod] Working Group Last Call: Common YANG Data Types > > Dear all, > > This is a two-week working group last call on the current working group > document: > > - Common YANG Data Types: > http://tools.ietf.org/html/draft-ietf-netmod-yang-types-05.txt > > This WGLC will end on January 27, 2010. Please review the document and > post > your comments on the mailing list. Please use an appropriate Subject line > so > that the chairs and editor can easily keep track of the issues that need > to > be dealt with. > > Thanks. > > David^2 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --------------------------------------------------------------------------------------- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > From mbj@tail-f.com Thu Jan 14 13:37:39 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217353A67FC for ; Thu, 14 Jan 2010 13:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iApuhRyq2Gvz for ; Thu, 14 Jan 2010 13:37:38 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 087B33A68D7 for ; Thu, 14 Jan 2010 13:37:37 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C1F1C61600D for ; Thu, 14 Jan 2010 22:37:33 +0100 (CET) Date: Thu, 14 Jan 2010 22:37:33 +0100 (CET) Message-Id: <20100114.223733.83933084.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <201001130807.18538.david.partain@ericsson.com> References: <201001130807.18538.david.partain@ericsson.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 21:37:39 -0000 Hi, I have reviewed this document, and here are my (minor) comments. 1. Section 2. The overview mentions the types and their equivalent SMIv2 types. It is not clear why the SMIv2 types are listed. Is it just as information, or something else? And what does "equivalent" really mean? 2. s/Table 1 list the/Table 1 lists the/ s/Table 2 list the/Table 2 lists the/ 3. Some YANG types in table 2 do not have an "equivalent" SMIv2 type. It seems ip-version should have InetVersion? Or is it not "equivalent enough"? 4. Terminology. The terms "object" and "object instance" are used, e.g. counter32 says: "... as specified in the description of an object instance using this type" (should this be object?) The YANG spec does not use the term "object". 5. The type zero-based-counter32 has a default statement, I think it should be removed. (same for zero-based-counter64) 6. counter32 says: increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. but zero-based-counter32 says: wrapping back to zero(0) when the value 2^32 is reached It presumably means the same thing, but looks odd (I understand that the text is copied from 2578 and 2021...) 7. gauge32: s/semantics equivalent to the Counter32/ s/semantics equivalent to the Gauge32/ 8. timeticks: s/When objects are defined which use/ When an object is defined which uses/ 9. xpath1.0: We should add something like: When an object is defined which uses this type, the description of the object MUST specify the XPath context in which the XPath expression is evaluated. 10. ipv6-address: s/The normalized format/The canonical format/ ? (same for ipv6-prefix) 11. domain-name: The text says: The description clause of objects using the domain-name type MUST describe how (and when) these names are resolved to IP addresses. s/description clause/description/ (or description statement) I realize that this text comes from rfc 4001, but I do not quite understand why this is necessary. I couldn't find many MIBs that allow dns(16), but some did not follow this MUST, and DISMAN-NSLOOKUP-MIB has: Specification of dns(16) as the value for this object means that a function such as, for example, getaddrinfo() or gethostbyname() should be performed to return one or more numeric addresses. Is this necessary (as in MUST)? 12. uri: s/uri type must be/uri type MUST be/ ? 13. uri: s/where required/where required./ Also, I have implemented the modules in this document. /martin From andyb@iwl.com Thu Jan 14 15:03:02 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B0A28B23E for ; Thu, 14 Jan 2010 15:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVTHePIHTfyE for ; Thu, 14 Jan 2010 15:03:01 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 85E2A3A68D7 for ; Thu, 14 Jan 2010 15:03:01 -0800 (PST) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 6CBD69083CD; Thu, 14 Jan 2010 18:02:58 -0500 (EST) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4156C908178; Thu, 14 Jan 2010 18:02:58 -0500 (EST) Message-ID: <4B4FA2A1.8090200@iwl.com> Date: Thu, 14 Jan 2010 15:02:57 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <201001130807.18538.david.partain@ericsson.com> <20100114.223733.83933084.mbj@tail-f.com> In-Reply-To: <20100114.223733.83933084.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 23:03:02 -0000 Martin Bjorklund wrote: ... > 5. The type zero-based-counter32 has a default statement, I think > it should be removed. (same for zero-based-counter64) > We already established that default-stmt for config=false is OK. It has meaning wrt/ the with-defaults=trim filtering. In this case, the default means the server MUST create all instances of the leaf with the value zero. This is the exact semantics that is required for these typedefs. I think the default-stmt text says that default (for a data node) means that the server will create the node with that value. It doesn't say (or mean) that the server has to keep the leaf at that value forever. In other contexts, the server does not have a chance to alter the leaf (rpc-reply, notification). > > /martin Andy From mbj@tail-f.com Thu Jan 14 15:09:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258EB3A69ED for ; Thu, 14 Jan 2010 15:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E98SXThXXr37 for ; Thu, 14 Jan 2010 15:09:39 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 571933A6833 for ; Thu, 14 Jan 2010 15:09:39 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 732F661600D; Fri, 15 Jan 2010 00:09:35 +0100 (CET) Date: Fri, 15 Jan 2010 00:09:35 +0100 (CET) Message-Id: <20100115.000935.00628050.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4FA2A1.8090200@iwl.com> References: <201001130807.18538.david.partain@ericsson.com> <20100114.223733.83933084.mbj@tail-f.com> <4B4FA2A1.8090200@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 23:09:40 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > ... > > 5. The type zero-based-counter32 has a default statement, I think > > it should be removed. (same for zero-based-counter64) > > > > We already established that default-stmt for config=false is OK. Yes. > It has meaning wrt/ the with-defaults=trim filtering. Yes. > In this case, the default means the server MUST create all > instances of the leaf with the value zero. The YANG spec does not say that default for config false means initial value. The description of this typedef says that though, and that is correct. A default on a config false means the same as a default on config true, right? I.e. if the instance does not exist, it operationally has the default value. > I think the default-stmt text says that default (for a data node) > means that the server will create the node with that value. No it says: The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. But I don't want to re-re-re-start the debate of what a default is! /martin From andyb@iwl.com Thu Jan 14 15:31:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8229528C0D8 for ; Thu, 14 Jan 2010 15:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNKjql2f0-0J for ; Thu, 14 Jan 2010 15:31:54 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id D25FF28B23E for ; Thu, 14 Jan 2010 15:31:54 -0800 (PST) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 1873010CBFA7; Thu, 14 Jan 2010 18:31:52 -0500 (EST) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DBE4610CBD9C; Thu, 14 Jan 2010 18:31:51 -0500 (EST) Message-ID: <4B4FA966.8040809@iwl.com> Date: Thu, 14 Jan 2010 15:31:50 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <201001130807.18538.david.partain@ericsson.com> <20100114.223733.83933084.mbj@tail-f.com> <4B4FA2A1.8090200@iwl.com> <20100115.000935.00628050.mbj@tail-f.com> In-Reply-To: <20100115.000935.00628050.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 23:31:55 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >> ... >>> 5. The type zero-based-counter32 has a default statement, I think >>> it should be removed. (same for zero-based-counter64) >>> >> We already established that default-stmt for config=false is OK. > > Yes. > >> It has meaning wrt/ the with-defaults=trim filtering. > > Yes. > >> In this case, the default means the server MUST create all >> instances of the leaf with the value zero. > > The YANG spec does not say that default for config false means initial > value. The description of this typedef says that though, and that is > correct. > > A default on a config false means the same as a default on config > true, right? I.e. if the instance does not exist, it operationally > has the default value. > > >> I think the default-stmt text says that default (for a data node) >> means that the server will create the node with that value. > > No it says: > > The default value of a leaf is the value that the server uses if the > leaf does not exist in the data tree. > > > But I don't want to re-re-re-start the debate of what a default is! > Well, this is still the desired behavior, especially for rare error counters. The default=0 says the server does not actually have to return all these 'never been incremented' counters. Without the default-stmt, the server MUST return all these zeros. With the default-stmt, the server MAY wait until the counter is non-zero before creating the actual state data node. > > > /martin > Andy From root@core3.amsl.com Thu Jan 14 16:00:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 715493A6836; Thu, 14 Jan 2010 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100115000001.715493A6836@core3.amsl.com> Date: Thu, 14 Jan 2010 16:00:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-03.txt Pages : 29 Date : 2010-01-14 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-usage-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-14155638.I-D@ietf.org> --NextPart-- From phil@juniper.net Thu Jan 14 20:26:23 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F563A6A1C for ; Thu, 14 Jan 2010 20:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOYvfJJL-QEp for ; Thu, 14 Jan 2010 20:26:22 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 291533A68D9 for ; Thu, 14 Jan 2010 20:26:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS0/uZ9nuTYDt2CUxZuSFWwldo6vrPU+h@postini.com; Thu, 14 Jan 2010 20:26:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 14 Jan 2010 20:25:29 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 20:25:28 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 20:25:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 20:25:28 -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 o0F4PQj44041; Thu, 14 Jan 2010 20:25:27 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o0F4A5wb083586; Fri, 15 Jan 2010 04:10:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201001150410.o0F4A5wb083586@idle.juniper.net> To: andyb@iwl.com In-Reply-To: <4B4FA966.8040809@iwl.com> Date: Thu, 14 Jan 2010 23:10:05 -0500 From: Phil Shafer X-OriginalArrivalTime: 15 Jan 2010 04:25:28.0115 (UTC) FILETIME=[C41BF830:01CA959A] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 04:26:23 -0000 Andy Bierman writes: >Martin Bjorklund wrote: >> But I don't want to re-re-re-start the debate of what a default is! Amen. >Without the default-stmt, the server MUST return all these zeros. Not unless the leaf is mandatory. Thanks, Phil From andyb@iwl.com Sun Jan 17 09:40:19 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68273A6847 for ; Sun, 17 Jan 2010 09:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBoPdne5GR0m for ; Sun, 17 Jan 2010 09:40:19 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 175CF3A6829 for ; Sun, 17 Jan 2010 09:40:19 -0800 (PST) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 7AB6610CBEA6 for ; Sun, 17 Jan 2010 12:40:15 -0500 (EST) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5B55910CBE90 for ; Sun, 17 Jan 2010 12:40:15 -0500 (EST) Message-ID: <4B534B5C.8090401@iwl.com> Date: Sun, 17 Jan 2010 09:39:40 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 17:40:19 -0000 Hi, I think the 'real' typedef should be added to the ietf-yang-types module. The thread occurred in May 2009, and the final proposal from David Spakes in in this email: http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html I am working on some XPath-based power tools for NETCONF. Now that we got rid of float64, there is no way to expose an XPath number result, which is a double. The 'real' typedef allows decimal64 to be used for this purpose. Andy From j.schoenwaelder@jacobs-university.de Sun Jan 17 11:44:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA593A68A3 for ; Sun, 17 Jan 2010 11:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE6N0KJbQVFL for ; Sun, 17 Jan 2010 11:44:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8B4DC3A69A9 for ; Sun, 17 Jan 2010 11:44:10 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDC7EC000B; Sun, 17 Jan 2010 20:44:06 +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 G02q5hFwmuXV; Sun, 17 Jan 2010 20:44:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46886C000A; Sun, 17 Jan 2010 20:44:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 87783FD4554; Sun, 17 Jan 2010 20:43:58 +0100 (CET) Date: Sun, 17 Jan 2010 20:43:58 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100117194358.GA43296@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4B534B5C.8090401@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B534B5C.8090401@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 19:44:12 -0000 On Sun, Jan 17, 2010 at 06:39:40PM +0100, Andy Bierman wrote: > I think the 'real' typedef should be added to the ietf-yang-types > module. The thread occurred in May 2009, and the final > proposal from David Spakes in in this email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html > > I am working on some XPath-based power tools for NETCONF. > Now that we got rid of float64, there is no way to expose > an XPath number result, which is a double. The 'real' typedef > allows decimal64 to be used for this purpose. As far as I know, XPath uses double-precision 64-bit format IEEE 754 numbers [1] and hence the 'real' typedef won't do it. /js [1] http://www.w3.org/TR/xpath#numbers -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Jan 17 11:49:26 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D21D3A67EE for ; Sun, 17 Jan 2010 11:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubUX9xtNKQRr for ; Sun, 17 Jan 2010 11:49:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B4F5C3A67B7 for ; Sun, 17 Jan 2010 11:49:25 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8529F616006; Sun, 17 Jan 2010 20:49:21 +0100 (CET) Date: Sun, 17 Jan 2010 20:49:20 +0100 (CET) Message-Id: <20100117.204920.242960783.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100117194358.GA43296@elstar.local> References: <4B534B5C.8090401@iwl.com> <20100117194358.GA43296@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 19:49:26 -0000 Juergen Schoenwaelder wrote: > On Sun, Jan 17, 2010 at 06:39:40PM +0100, Andy Bierman wrote: > > > I think the 'real' typedef should be added to the ietf-yang-types > > module. The thread occurred in May 2009, and the final > > proposal from David Spakes in in this email: > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html > > > > I am working on some XPath-based power tools for NETCONF. > > Now that we got rid of float64, there is no way to expose > > an XPath number result, which is a double. The 'real' typedef > > allows decimal64 to be used for this purpose. > > As far as I know, XPath uses double-precision 64-bit format IEEE 754 > numbers [1] and hence the 'real' typedef won't do it. Right. So should we put back float64 into YANG? I agree with Andy that such a datatype is necessary (somehow) when we want to expose the result of an XPath expression in YANG. /martin From mbj@tail-f.com Sun Jan 17 12:44:17 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1699B3A69AE for ; Sun, 17 Jan 2010 12:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj5EkNm7yerD for ; Sun, 17 Jan 2010 12:44:16 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 360F73A67F6 for ; Sun, 17 Jan 2010 12:44:16 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 90547616006; Sun, 17 Jan 2010 21:44:12 +0100 (CET) Date: Sun, 17 Jan 2010 21:44:11 +0100 (CET) Message-Id: <20100117.214411.82790368.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B4FA966.8040809@iwl.com> References: <4B4FA2A1.8090200@iwl.com> <20100115.000935.00628050.mbj@tail-f.com> <4B4FA966.8040809@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 20:44:17 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >> ... > >>> 5. The type zero-based-counter32 has a default statement, I think > >>> it should be removed. (same for zero-based-counter64) > >>> > >> We already established that default-stmt for config=false is OK. > > > > Yes. > > > >> It has meaning wrt/ the with-defaults=trim filtering. > > > > Yes. > > > >> In this case, the default means the server MUST create all > >> instances of the leaf with the value zero. > > > > The YANG spec does not say that default for config false means initial > > value. The description of this typedef says that though, and that is > > correct. > > > > A default on a config false means the same as a default on config > > true, right? I.e. if the instance does not exist, it operationally > > has the default value. > > > > > >> I think the default-stmt text says that default (for a data node) > >> means that the server will create the node with that value. > > > > No it says: > > > > The default value of a leaf is the value that the server uses if the > > leaf does not exist in the data tree. > > > > > > But I don't want to re-re-re-start the debate of what a default is! > > > > Well, this is still the desired behavior, especially for > rare error counters. The default=0 says the server does not > actually have to return all these 'never been incremented' counters. > > Without the default-stmt, the server MUST return all these zeros. > With the default-stmt, the server MAY wait until the counter is non-zero > before creating the actual state data node. Ok, this makes sense. /martin From andyb@iwl.com Sun Jan 17 13:07:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8683A69F2 for ; Sun, 17 Jan 2010 13:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kdm5sTGJ3RP for ; Sun, 17 Jan 2010 13:07:12 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 1C1743A69AE for ; Sun, 17 Jan 2010 13:07:12 -0800 (PST) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 7C9FC17FB65; Sun, 17 Jan 2010 16:07:08 -0500 (EST) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3976A17FB3B; Sun, 17 Jan 2010 16:07:08 -0500 (EST) Message-ID: <4B537BD7.8040109@iwl.com> Date: Sun, 17 Jan 2010 13:06:31 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B534B5C.8090401@iwl.com> <20100117194358.GA43296@elstar.local> <20100117.204920.242960783.mbj@tail-f.com> In-Reply-To: <20100117.204920.242960783.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 21:07:13 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Sun, Jan 17, 2010 at 06:39:40PM +0100, Andy Bierman wrote: >> >>> I think the 'real' typedef should be added to the ietf-yang-types >>> module. The thread occurred in May 2009, and the final >>> proposal from David Spakes in in this email: >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html >>> >>> I am working on some XPath-based power tools for NETCONF. >>> Now that we got rid of float64, there is no way to expose >>> an XPath number result, which is a double. The 'real' typedef >>> allows decimal64 to be used for this purpose. >> As far as I know, XPath uses double-precision 64-bit format IEEE 754 >> numbers [1] and hence the 'real' typedef won't do it. > > Right. So should we put back float64 into YANG? I agree with Andy > that such a datatype is necessary (somehow) when we want to expose the > result of an XPath expression in YANG. > I agree. We lost this important compatibility with XPath. In fact, we only support 1 of the 3 XPath result formats -- string. I have asked many times for a 'varbind' data type, which is the same as a node in an XPath node-set result. list xpath-node { key id; leaf id { description "YANG ID for this node"; type instance-identifier; } leaf yang-type { description "Name of the 'final' YANG base type. If the type is union or leafref, then it is resolved until the base type is not one of these YANG types."; type string; // could be enum to be more exact } leaf value { description "The value of the node indicated by 'id', cast as a 'string'."; type string; } } I think we should support XPath results in our filtering, and I am tired of explaining why NETCONF XPath doesn't work that way. If the client knows it wants an XPath node set result, not a reconstructed element, then the client should be able to ask for that. (Uh-oh, that's a NETCONF comment; not our department!) > > /martin > Andy From mbj@tail-f.com Sun Jan 17 13:15:51 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823DE3A69EC for ; Sun, 17 Jan 2010 13:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-gadRVEThVG for ; Sun, 17 Jan 2010 13:15:50 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A72C63A69CB for ; Sun, 17 Jan 2010 13:15:50 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F13B616006; Sun, 17 Jan 2010 22:15:46 +0100 (CET) Date: Sun, 17 Jan 2010 22:15:45 +0100 (CET) Message-Id: <20100117.221545.245712966.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B537BD7.8040109@iwl.com> References: <20100117194358.GA43296@elstar.local> <20100117.204920.242960783.mbj@tail-f.com> <4B537BD7.8040109@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 21:15:51 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> On Sun, Jan 17, 2010 at 06:39:40PM +0100, Andy Bierman wrote: > >> > >>> I think the 'real' typedef should be added to the ietf-yang-types > >>> module. The thread occurred in May 2009, and the final > >>> proposal from David Spakes in in this email: > >>> > >>> http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html > >>> > >>> I am working on some XPath-based power tools for NETCONF. > >>> Now that we got rid of float64, there is no way to expose > >>> an XPath number result, which is a double. The 'real' typedef > >>> allows decimal64 to be used for this purpose. > >> As far as I know, XPath uses double-precision 64-bit format IEEE 754 > >> numbers [1] and hence the 'real' typedef won't do it. > > > > Right. So should we put back float64 into YANG? I agree with Andy > > that such a datatype is necessary (somehow) when we want to expose the > > result of an XPath expression in YANG. > > > > I agree. We lost this important compatibility with XPath. > > In fact, we only support 1 of the 3 XPath result formats -- string. We support boolean as well. A node-set can be represented as a leaf-list of instance-identifiers (sort-of; it can only refer to the 'node' type, not 'comment' etc, but that doesn't matter). So that's 3 out of 4. /martin From j.schoenwaelder@jacobs-university.de Sun Jan 17 23:21:23 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73BB3A68C9 for ; Sun, 17 Jan 2010 23:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABFPNL1P7Jv7 for ; Sun, 17 Jan 2010 23:21:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1789C3A69FE for ; Sun, 17 Jan 2010 23:21:22 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B5FCC000C; Mon, 18 Jan 2010 08:21:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9S8W-1Rq7Y1a; Mon, 18 Jan 2010 08:21:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA701C000A; Mon, 18 Jan 2010 08:21:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 666D1FD5486; Mon, 18 Jan 2010 08:21:10 +0100 (CET) Date: Mon, 18 Jan 2010 08:21:10 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100118072110.GA44023@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <4B534B5C.8090401@iwl.com> <20100117194358.GA43296@elstar.local> <20100117.204920.242960783.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100117.204920.242960783.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2010 07:21:23 -0000 On Sun, Jan 17, 2010 at 08:49:20PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Sun, Jan 17, 2010 at 06:39:40PM +0100, Andy Bierman wrote: > > > > > I think the 'real' typedef should be added to the ietf-yang-types > > > module. The thread occurred in May 2009, and the final > > > proposal from David Spakes in in this email: > > > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html > > > > > > I am working on some XPath-based power tools for NETCONF. > > > Now that we got rid of float64, there is no way to expose > > > an XPath number result, which is a double. The 'real' typedef > > > allows decimal64 to be used for this purpose. > > > > As far as I know, XPath uses double-precision 64-bit format IEEE 754 > > numbers [1] and hence the 'real' typedef won't do it. > > Right. So should we put back float64 into YANG? I agree with Andy > that such a datatype is necessary (somehow) when we want to expose the > result of an XPath expression in YANG. As far as I am concerned, the introduction of decimal64 was a good thing, the removal of the float types was a bad thing. Giving data modelers the choice is a good thing, denying them the choice because we believe to know better is a bad thing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Jan 17 23:44:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A9C3A6A18 for ; Sun, 17 Jan 2010 23:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-1.645, BAYES_05=-1.11, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTGsXoUlephD for ; Sun, 17 Jan 2010 23:44:25 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 067F83A6A3C for ; Sun, 17 Jan 2010 23:44:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8759761601F; Mon, 18 Jan 2010 08:44:20 +0100 (CET) Date: Mon, 18 Jan 2010 08:44:19 +0100 (CET) Message-Id: <20100118.084419.168780613.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100118072110.GA44023@elstar.local> References: <20100117194358.GA43296@elstar.local> <20100117.204920.242960783.mbj@tail-f.com> <20100118072110.GA44023@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 07:44:25 -0000 Juergen Schoenwaelder wrote: > On Sun, Jan 17, 2010 at 08:49:20PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Sun, Jan 17, 2010 at 06:39:40PM +0100, Andy Bierman wrote: > > > > > > > I think the 'real' typedef should be added to the ietf-yang-types > > > > module. The thread occurred in May 2009, and the final > > > > proposal from David Spakes in in this email: > > > > > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html > > > > > > > > I am working on some XPath-based power tools for NETCONF. > > > > Now that we got rid of float64, there is no way to expose > > > > an XPath number result, which is a double. The 'real' typedef > > > > allows decimal64 to be used for this purpose. > > > > > > As far as I know, XPath uses double-precision 64-bit format IEEE 754 > > > numbers [1] and hence the 'real' typedef won't do it. > > > > Right. So should we put back float64 into YANG? I agree with Andy > > that such a datatype is necessary (somehow) when we want to expose the > > result of an XPath expression in YANG. > > As far as I am concerned, the introduction of decimal64 was a good > thing, the removal of the float types was a bad thing. Giving data > modelers the choice is a good thing, denying them the choice because > we believe to know better is a bad thing. I just re-read the old threads on floating point numbers in the archive. We should probably not re-open this issue... *Maybe* we could avoid some of the problems by adding a type 'xpath1.0-number' instead, for the sole purpose of represeting a number as defined in XPath 1.0. /martin From j.schoenwaelder@jacobs-university.de Mon Jan 18 00:16:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC12E3A68DC for ; Mon, 18 Jan 2010 00:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNRJe5QXVI1L for ; Mon, 18 Jan 2010 00:16:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 635BF3A6A81 for ; Mon, 18 Jan 2010 00:16:12 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA746C000C; Mon, 18 Jan 2010 09:16: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 VbMm5gDb26i3; Mon, 18 Jan 2010 09:16:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F978C000A; Mon, 18 Jan 2010 09:16:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A5727FD56E6; Mon, 18 Jan 2010 09:16:00 +0100 (CET) Date: Mon, 18 Jan 2010 09:16:00 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100118081600.GC44023@elstar.local> Mail-Followup-To: Martin Bjorklund , "andyb@iwl.com" , "netmod@ietf.org" References: <20100117194358.GA43296@elstar.local> <20100117.204920.242960783.mbj@tail-f.com> <20100118072110.GA44023@elstar.local> <20100118.084419.168780613.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100118.084419.168780613.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2010 08:16:13 -0000 On Mon, Jan 18, 2010 at 08:44:19AM +0100, Martin Bjorklund wrote: > I just re-read the old threads on floating point numbers in the > archive. We should probably not re-open this issue... Probably. > *Maybe* we could avoid some of the problems by adding a type > 'xpath1.0-number' instead, for the sole purpose of represeting a > number as defined in XPath 1.0. I am missing the smiley here. Is this meant as a serious proposal? In that case, I will object. How many -number types do we need? Or do we then derive a float typedef from -number to get the basic type we try to avoid to add? Are we repeating the Counter64 story or are we learning form the past? Lets just accept that as of -10, the WG designed YANG such that it can't natively represent the result of an XPATH expression (and lets keep in mind that the original YANG proposal coming from the design team was able to do so). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Jan 18 03:15:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7633D3A6819 for ; Mon, 18 Jan 2010 03:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFpUAwkn3xhI for ; Mon, 18 Jan 2010 03:15:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F10DB3A6803 for ; Mon, 18 Jan 2010 03:15:28 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43CBDC001F; Mon, 18 Jan 2010 12:15:25 +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 QE5jGGPQ4LxJ; Mon, 18 Jan 2010 12:15:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D0EBC000A; Mon, 18 Jan 2010 12:15:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C7C3FD5FD6; Mon, 18 Jan 2010 12:15:14 +0100 (CET) Date: Mon, 18 Jan 2010 12:15:14 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100118111513.GA634@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <201001130807.18538.david.partain@ericsson.com> <20100114.223733.83933084.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100114.223733.83933084.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2010 11:15:30 -0000 On Thu, Jan 14, 2010 at 10:37:33PM +0100, Martin Bjorklund wrote: > I have reviewed this document, and here are my (minor) comments. Thanks for your review. > 1. Section 2. The overview mentions the types and their equivalent > SMIv2 types. It is not clear why the SMIv2 types are listed. Is > it just as information, or something else? And what does > "equivalent" really mean? I propose to add the following sentence: A YANG data type is equivalent to an SMIv2 data type if both data types have the same set of values and the semantics of the values are equivalent. > 2. s/Table 1 list the/Table 1 lists the/ > s/Table 2 list the/Table 2 lists the/ fixed > 3. Some YANG types in table 2 do not have an "equivalent" SMIv2 > type. It seems ip-version should have InetVersion? Or is it not > "equivalent enough"? It seems to be equivalent, despite the text saying "However, the lexical appearance is different from the InetVersion textual convention." I think the proper resolution is to remove this sentence from the description statement and to list ip-version as equivalent to InetVersion in the summary table. > 4. Terminology. The terms "object" and "object instance" are used, > e.g. counter32 says: > > "... as specified in the > description of an object instance using this type" > > (should this be object?) > > The YANG spec does not use the term "object". Shall I use "data node" instead of "object"? > 5. The type zero-based-counter32 has a default statement, I think > it should be removed. (same for zero-based-counter64) I did not really understand the concern and it seems the discussion led to the conclusion that the default clause is OK. So I will not make any edits here. > 6. counter32 says: > > increases until it reaches a > maximum value of 2^32-1 (4294967295 decimal), when it > wraps around and starts increasing again from zero. > > but zero-based-counter32 says: > > wrapping > back to zero(0) when the value 2^32 is reached > > It presumably means the same thing, but looks odd (I understand > that the text is copied from 2578 and 2021...) I will align the wording for both, zero-based-counter32 and zero-based-counter64. > 7. gauge32: s/semantics equivalent to the Counter32/ > s/semantics equivalent to the Gauge32/ fixed > 8. timeticks: s/When objects are defined which use/ > When an object is defined which uses/ fixed > 9. xpath1.0: > > We should add something like: When an object is defined which > uses this type, the description of the object MUST specify the > XPath context in which the XPath expression is evaluated. yes, makes sense > 10. ipv6-address: s/The normalized format/The canonical format/ ? > > (same for ipv6-prefix) fixed > 11. domain-name: The text says: > > The description clause of objects using the domain-name > type MUST describe how (and when) these names are > resolved to IP addresses. > > s/description clause/description/ (or description statement) > > I realize that this text comes from rfc 4001, but I do not quite > understand why this is necessary. I couldn't find many MIBs that > allow dns(16), but some did not follow this MUST, and > DISMAN-NSLOOKUP-MIB has: > > Specification of dns(16) as the value for this object > means that a function such as, for example, getaddrinfo() > or gethostbyname() should be performed to return one or > more numeric addresses. > > Is this necessary (as in MUST)? The key really is the '(and when)' part. The point is that it makes a difference whether you resolve the name when you load a config or whether you resolve the name once the config is being used. I will remove the parenthesis to make the "and when" part clearer. Since the question when you resolve a name matters, I believe a MUST is justified. > 12. uri: s/uri type must be/uri type MUST be/ ? fixed > 13. uri: s/where required/where required./ fixed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Jan 18 13:42:27 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C620C3A67E1 for ; Mon, 18 Jan 2010 13:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hrXPWIfF53P for ; Mon, 18 Jan 2010 13:42:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A46743A67BD for ; Mon, 18 Jan 2010 13:42:26 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id D8602616002; Mon, 18 Jan 2010 22:42:21 +0100 (CET) Date: Mon, 18 Jan 2010 22:42:20 +0100 (CET) Message-Id: <20100118.224220.85116840.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100118111513.GA634@elstar.local> References: <201001130807.18538.david.partain@ericsson.com> <20100114.223733.83933084.mbj@tail-f.com> <20100118111513.GA634@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:42:27 -0000 Juergen Schoenwaelder wrote: > > 1. Section 2. The overview mentions the types and their equivalent > > SMIv2 types. It is not clear why the SMIv2 types are listed. Is > > it just as information, or something else? And what does > > "equivalent" really mean? > > I propose to add the following sentence: > > A YANG data type is equivalent to an SMIv2 data type if both data > types have the same set of values and the semantics of the values > are equivalent. Ok. With this definition, would you say that any other of the inet types are equivalent with the types in INET-ADDRESS-MIB? (e.g. ipv4-address vs. InetAddressIPv4)? > > 4. Terminology. The terms "object" and "object instance" are used, > > e.g. counter32 says: > > > > "... as specified in the > > description of an object instance using this type" > > > > (should this be object?) > > > > The YANG spec does not use the term "object". > > Shall I use "data node" instead of "object"? What do you want to cover with the term "object"? leaf? typedef? > > 5. The type zero-based-counter32 has a default statement, I think > > it should be removed. (same for zero-based-counter64) > > I did not really understand the concern and it seems the discussion > led to the conclusion that the default clause is OK. So I will not > make any edits here. Agreed. > > 11. domain-name: The text says: > > > > The description clause of objects using the domain-name > > type MUST describe how (and when) these names are > > resolved to IP addresses. > > > > s/description clause/description/ (or description statement) > > > > I realize that this text comes from rfc 4001, but I do not quite > > understand why this is necessary. I couldn't find many MIBs that > > allow dns(16), but some did not follow this MUST, and > > DISMAN-NSLOOKUP-MIB has: > > > > Specification of dns(16) as the value for this object > > means that a function such as, for example, getaddrinfo() > > or gethostbyname() should be performed to return one or > > more numeric addresses. > > > > Is this necessary (as in MUST)? > > The key really is the '(and when)' part. The point is that it makes a > difference whether you resolve the name when you load a config or > whether you resolve the name once the config is being used. I will > remove the parenthesis to make the "and when" part clearer. Since the > question when you resolve a name matters, I believe a MUST is > justified. I agree that the 'when part' justifies the MUST. I'm not convinced that the 'how part' MUST be described (does the example description from DISMAN-NSLOOKUP-MIB really say anything? "A function such as ..." seems pretty vague.) /martin From mbj@tail-f.com Mon Jan 18 13:51:02 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44473A67CC for ; Mon, 18 Jan 2010 13:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuERdZMFpLuT for ; Mon, 18 Jan 2010 13:51:01 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 72E503A68AB for ; Mon, 18 Jan 2010 13:51:01 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 96B63616002; Mon, 18 Jan 2010 22:50:57 +0100 (CET) Date: Mon, 18 Jan 2010 22:50:57 +0100 (CET) Message-Id: <20100118.225057.127568672.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100118081600.GC44023@elstar.local> References: <20100118072110.GA44023@elstar.local> <20100118.084419.168780613.mbj@tail-f.com> <20100118081600.GC44023@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:51:02 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 18, 2010 at 08:44:19AM +0100, Martin Bjorklund wrote: > > *Maybe* we could avoid some of the problems by adding a type > > 'xpath1.0-number' instead, for the sole purpose of represeting a > > number as defined in XPath 1.0. > > I am missing the smiley here. Is this meant as a serious proposal? In > that case, I will object. How many -number types do we need? Or > do we then derive a float typedef from -number to get the basic > type we try to avoid to add? Are we repeating the Counter64 story or > are we learning form the past? The reasons we removed the float types were that (i) we believed that a fixed point type was what people really needed and (ii) that we couldn't find a representation that would work for XPath, XSD (RNG) and easily for code. Now maybe we can see a use case for the XPath-flavor. But you are right - if we want to add a float type we should do it right, and since we won't do that now, we should not add anything. > Lets just accept that as of -10, the WG designed YANG such that it > can't natively represent the result of an XPATH expression (and lets > keep in mind that the original YANG proposal coming from the design > team was able to do so). Well, we had a float64 type, but it wasn't properly specified. /martin From andyb@iwl.com Mon Jan 18 14:00:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EB93A680B for ; Mon, 18 Jan 2010 14:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwWOIro26mU2 for ; Mon, 18 Jan 2010 14:00:37 -0800 (PST) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id 0F3343A67B7 for ; Mon, 18 Jan 2010 14:00:37 -0800 (PST) Received: from relay12.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 3B2D420802A0; Mon, 18 Jan 2010 17:00:33 -0500 (EST) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id F1CFC208028D; Mon, 18 Jan 2010 17:00:32 -0500 (EST) Message-ID: <4B54D9D0.5070203@iwl.com> Date: Mon, 18 Jan 2010 13:59:44 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <20100118072110.GA44023@elstar.local> <20100118.084419.168780613.mbj@tail-f.com> <20100118081600.GC44023@elstar.local> <20100118.225057.127568672.mbj@tail-f.com> In-Reply-To: <20100118.225057.127568672.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 22:00:37 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Jan 18, 2010 at 08:44:19AM +0100, Martin Bjorklund wrote: >>> *Maybe* we could avoid some of the problems by adding a type >>> 'xpath1.0-number' instead, for the sole purpose of represeting a >>> number as defined in XPath 1.0. >> I am missing the smiley here. Is this meant as a serious proposal? In >> that case, I will object. How many -number types do we need? Or >> do we then derive a float typedef from -number to get the basic >> type we try to avoid to add? Are we repeating the Counter64 story or >> are we learning form the past? > > The reasons we removed the float types were that (i) we believed that > a fixed point type was what people really needed and (ii) that we > couldn't find a representation that would work for XPath, XSD (RNG) > and easily for code. > > Now maybe we can see a use case for the XPath-flavor. > > But you are right - if we want to add a float type we should do it > right, and since we won't do that now, we should not add anything. > >> Lets just accept that as of -10, the WG designed YANG such that it >> can't natively represent the result of an XPATH expression (and lets >> keep in mind that the original YANG proposal coming from the design >> team was able to do so). > > Well, we had a float64 type, but it wasn't properly specified. > Yet Another content-tagging extension: leaf xpath-number { type string; acme:xpath-number; } That's OK. I don't want to change any more text in either draft, especially if it won't actually fix the problem. > > /martin > Andy From j.schoenwaelder@jacobs-university.de Mon Jan 18 15:14:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7245B3A6826 for ; Mon, 18 Jan 2010 15:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKrWzRp9d1Uu for ; Mon, 18 Jan 2010 15:14:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0F7433A67F6 for ; Mon, 18 Jan 2010 15:14:28 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38EF9C0032; Tue, 19 Jan 2010 00:14:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kZDfjRlJOPMW; Tue, 19 Jan 2010 00:14:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5580C002C; Tue, 19 Jan 2010 00:14:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D6C5BFD78EB; Tue, 19 Jan 2010 00:14:14 +0100 (CET) Date: Tue, 19 Jan 2010 00:14:14 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100118231414.GA2574@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <201001130807.18538.david.partain@ericsson.com> <20100114.223733.83933084.mbj@tail-f.com> <20100118111513.GA634@elstar.local> <20100118.224220.85116840.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100118.224220.85116840.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2010 23:14:30 -0000 On Mon, Jan 18, 2010 at 10:42:20PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > 1. Section 2. The overview mentions the types and their equivalent > > > SMIv2 types. It is not clear why the SMIv2 types are listed. Is > > > it just as information, or something else? And what does > > > "equivalent" really mean? > > > > I propose to add the following sentence: > > > > A YANG data type is equivalent to an SMIv2 data type if both data > > types have the same set of values and the semantics of the values > > are equivalent. > > Ok. With this definition, would you say that any other of the inet > types are equivalent with the types in INET-ADDRESS-MIB? > (e.g. ipv4-address vs. InetAddressIPv4)? ipv4-address and InetAddressIPv4 clearly are not the same since the first allows for an optional zone index and InetAddressIPv4 does not. In other words, ipv4-address is kind of a union of InetAddressIPv4 and InetAddressIPv4z. > > > 4. Terminology. The terms "object" and "object instance" are used, > > > e.g. counter32 says: > > > > > > "... as specified in the > > > description of an object instance using this type" > > > > > > (should this be object?) > > > > > > The YANG spec does not use the term "object". > > > > Shall I use "data node" instead of "object"? > > What do you want to cover with the term "object"? leaf? typedef? The term was carried over from SMIv2 definitions and I think it refers in most cases to leafs or leaf-list definitions. I guess data node covers this best - given the set of defined YANG terms we have. > > > 11. domain-name: The text says: > > > > > > The description clause of objects using the domain-name > > > type MUST describe how (and when) these names are > > > resolved to IP addresses. > > > > > > s/description clause/description/ (or description statement) > > > > > > I realize that this text comes from rfc 4001, but I do not quite > > > understand why this is necessary. I couldn't find many MIBs that > > > allow dns(16), but some did not follow this MUST, and > > > DISMAN-NSLOOKUP-MIB has: > > > > > > Specification of dns(16) as the value for this object > > > means that a function such as, for example, getaddrinfo() > > > or gethostbyname() should be performed to return one or > > > more numeric addresses. > > > > > > Is this necessary (as in MUST)? > > > > The key really is the '(and when)' part. The point is that it makes a > > difference whether you resolve the name when you load a config or > > whether you resolve the name once the config is being used. I will > > remove the parenthesis to make the "and when" part clearer. Since the > > question when you resolve a name matters, I believe a MUST is > > justified. > > I agree that the 'when part' justifies the MUST. I'm not convinced > that the 'how part' MUST be described (does the example description > from DISMAN-NSLOOKUP-MIB really say anything? "A function such as > ..." seems pretty vague.) So is your proposal to replace "MUST describe how (and when)" with "MUST describe when"? The "how" probably came into existence because it can matter whether you resolve AAAA records before trying A records and such things. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jan 19 01:43:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690EF3A69F7 for ; Tue, 19 Jan 2010 01:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svrf2K4sEyV9 for ; Tue, 19 Jan 2010 01:43:04 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5D4F53A69C5 for ; Tue, 19 Jan 2010 01:43:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D3D22616001; Tue, 19 Jan 2010 10:42:58 +0100 (CET) Date: Tue, 19 Jan 2010 10:42:58 +0100 (CET) Message-Id: <20100119.104258.07110030.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100118231414.GA2574@elstar.local> References: <20100118111513.GA634@elstar.local> <20100118.224220.85116840.mbj@tail-f.com> <20100118231414.GA2574@elstar.local> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:43:05 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 18, 2010 at 10:42:20PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > > 4. Terminology. The terms "object" and "object instance" are used, > > > > e.g. counter32 says: > > > > > > > > "... as specified in the > > > > description of an object instance using this type" > > > > > > > > (should this be object?) > > > > > > > > The YANG spec does not use the term "object". > > > > > > Shall I use "data node" instead of "object"? > > > > What do you want to cover with the term "object"? leaf? typedef? > > The term was carried over from SMIv2 definitions and I think it refers > in most cases to leafs or leaf-list definitions. I guess data node > covers this best - given the set of defined YANG terms we have. Agreed. But the term 'data node' sounds a bit strange when it is used here. I don't have a better suggestion though. > > > > 11. domain-name: The text says: > > > > > > > > The description clause of objects using the domain-name > > > > type MUST describe how (and when) these names are > > > > resolved to IP addresses. > > > > > > > > s/description clause/description/ (or description statement) > > > > > > > > I realize that this text comes from rfc 4001, but I do not quite > > > > understand why this is necessary. I couldn't find many MIBs that > > > > allow dns(16), but some did not follow this MUST, and > > > > DISMAN-NSLOOKUP-MIB has: > > > > > > > > Specification of dns(16) as the value for this object > > > > means that a function such as, for example, getaddrinfo() > > > > or gethostbyname() should be performed to return one or > > > > more numeric addresses. > > > > > > > > Is this necessary (as in MUST)? > > > > > > The key really is the '(and when)' part. The point is that it makes a > > > difference whether you resolve the name when you load a config or > > > whether you resolve the name once the config is being used. I will > > > remove the parenthesis to make the "and when" part clearer. Since the > > > question when you resolve a name matters, I believe a MUST is > > > justified. > > > > I agree that the 'when part' justifies the MUST. I'm not convinced > > that the 'how part' MUST be described (does the example description > > from DISMAN-NSLOOKUP-MIB really say anything? "A function such as > > ..." seems pretty vague.) > > So is your proposal to replace "MUST describe how (and when)" with > "MUST describe when"? The "how" probably came into existence because > it can matter whether you resolve AAAA records before trying A records > and such things. Hmm.. I guess this makes sense. Maybe we should add some hints about how 'how and when' should be described. Just saying that getaddrbyinfo() or equivalent is used does not really answer the 'how' question. /martin From j.schoenwaelder@jacobs-university.de Tue Jan 19 03:41:39 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8820E3A68F4 for ; Tue, 19 Jan 2010 03:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD6RxuQR+pQE for ; Tue, 19 Jan 2010 03:41:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EFDCA3A6857 for ; Tue, 19 Jan 2010 03:41:37 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E826BC002F; Tue, 19 Jan 2010 12:41:33 +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 MVoPvz9qN8Qy; Tue, 19 Jan 2010 12:41:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8D52C0031; Tue, 19 Jan 2010 12:41:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7FCBAFD8ED9; Tue, 19 Jan 2010 12:41:12 +0100 (CET) Date: Tue, 19 Jan 2010 12:41:12 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100119114112.GB4271@elstar.local> Mail-Followup-To: Martin Bjorklund , "netmod@ietf.org" References: <20100118111513.GA634@elstar.local> <20100118.224220.85116840.mbj@tail-f.com> <20100118231414.GA2574@elstar.local> <20100119.104258.07110030.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100119.104258.07110030.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2010 11:41:39 -0000 On Tue, Jan 19, 2010 at 10:42:58AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jan 18, 2010 at 10:42:20PM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > > 4. Terminology. The terms "object" and "object instance" are used, > > > > > e.g. counter32 says: > > > > > > > > > > "... as specified in the > > > > > description of an object instance using this type" > > > > > > > > > > (should this be object?) > > > > > > > > > > The YANG spec does not use the term "object". > > > > > > > > Shall I use "data node" instead of "object"? > > > > > > What do you want to cover with the term "object"? leaf? typedef? > > > > The term was carried over from SMIv2 definitions and I think it refers > > in most cases to leafs or leaf-list definitions. I guess data node > > covers this best - given the set of defined YANG terms we have. > > Agreed. But the term 'data node' sounds a bit strange when it is used > here. I don't have a better suggestion though. So unless someone has a better suggestion, I will make the edits to use "data node". > > > > > 11. domain-name: The text says: > > > > > > > > > > The description clause of objects using the domain-name > > > > > type MUST describe how (and when) these names are > > > > > resolved to IP addresses. > > > > > > > > > > s/description clause/description/ (or description statement) > > > > > > > > > > I realize that this text comes from rfc 4001, but I do not quite > > > > > understand why this is necessary. I couldn't find many MIBs that > > > > > allow dns(16), but some did not follow this MUST, and > > > > > DISMAN-NSLOOKUP-MIB has: > > > > > > > > > > Specification of dns(16) as the value for this object > > > > > means that a function such as, for example, getaddrinfo() > > > > > or gethostbyname() should be performed to return one or > > > > > more numeric addresses. > > > > > > > > > > Is this necessary (as in MUST)? > > > > > > > > The key really is the '(and when)' part. The point is that it makes a > > > > difference whether you resolve the name when you load a config or > > > > whether you resolve the name once the config is being used. I will > > > > remove the parenthesis to make the "and when" part clearer. Since the > > > > question when you resolve a name matters, I believe a MUST is > > > > justified. > > > > > > I agree that the 'when part' justifies the MUST. I'm not convinced > > > that the 'how part' MUST be described (does the example description > > > from DISMAN-NSLOOKUP-MIB really say anything? "A function such as > > > ..." seems pretty vague.) > > > > So is your proposal to replace "MUST describe how (and when)" with > > "MUST describe when"? The "how" probably came into existence because > > it can matter whether you resolve AAAA records before trying A records > > and such things. > > Hmm.. I guess this makes sense. Maybe we should add some hints about > how 'how and when' should be described. Just saying that > getaddrbyinfo() or equivalent is used does not really answer the 'how' > question. The good news is that there is already a "note" following the sentence in question" The description clause of objects using the domain-name type MUST describe how and when these names are resolved to IP addresses. Note that the resolution of a domain-name value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS record takes precedence depends on the configuration of the resolver. But then the last sentence kind of confuses things again since the resolution order depends on the resolver config only if the application chooses to not provide resolution hints. A more accurate phrasing might be this: The description clause of objects using the domain-name type MUST describe how and when these names are resolved to IP addresses. Note that the resolution of a domain-name value may require to query multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order of the resolution process and which DNS records take precedence can either be controlled explicitely by the caller of the resolver or it may depend on the configuration of the resolver. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Jan 20 04:33:24 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667E03A6ABD for ; Wed, 20 Jan 2010 04:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-1h6OwczqhZ for ; Wed, 20 Jan 2010 04:33:23 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id C95D03A6AC2 for ; Wed, 20 Jan 2010 04:33:22 -0800 (PST) X-Trace: 320831026/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.204/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.204 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0HABuHVks+vGTM/2dsb2JhbACCUoVYiHm6QgmMGQIIgj+BbQQ X-IronPort-AV: E=Sophos;i="4.49,310,1262563200"; d="scan'208";a="320831026" X-IP-Direction: IN Received: from 1cust204.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.204]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Jan 2010 12:33:14 +0000 Message-ID: <01e501ca99c4$57195c40$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "Martin Bjorklund" References: <20100118111513.GA634@elstar.local><20100118.224220.85116840.mbj@tail-f.com><20100118231414.GA2574@elstar.local><20100119.104258.07110030.mbj@tail-f.com> <20100119114112.GB4271@elstar.local> Date: Wed, 20 Jan 2010 10:41:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:33:24 -0000 Martin You say in item 4 '> > > > > > The YANG spec does not use the term "object". ' but then in item 9 - since elided, implying agreement - you say > 9. xpath1.0: > > We should add something like: When an object is defined which > uses this type, the description of the object MUST specify the > XPath context in which the XPath expression is evaluated. Either object is in or object is out:-) I would take it out but would prefer schema node to data node; I think that that would be less confusing. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Martin Bjorklund" Cc: Sent: Tuesday, January 19, 2010 12:41 PM Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types > On Tue, Jan 19, 2010 at 10:42:58AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Mon, Jan 18, 2010 at 10:42:20PM +0100, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > > 4. Terminology. The terms "object" and "object instance" are used, > > > > > > e.g. counter32 says: > > > > > > > > > > > > "... as specified in the > > > > > > description of an object instance using this type" > > > > > > > > > > > > (should this be object?) > > > > > > > > > > > > The YANG spec does not use the term "object". > > > > > > > > > > Shall I use "data node" instead of "object"? > > > > > > > > What do you want to cover with the term "object"? leaf? typedef? > > > > > > The term was carried over from SMIv2 definitions and I think it refers > > > in most cases to leafs or leaf-list definitions. I guess data node > > > covers this best - given the set of defined YANG terms we have. > > > > Agreed. But the term 'data node' sounds a bit strange when it is used > > here. I don't have a better suggestion though. > > So unless someone has a better suggestion, I will make the edits to use > "data node". > > > > > > > 11. domain-name: The text says: > > > > > > > > > > > > The description clause of objects using the domain-name > > > > > > type MUST describe how (and when) these names are > > > > > > resolved to IP addresses. > > > > > > > > > > > > s/description clause/description/ (or description statement) > > > > > > > > > > > > I realize that this text comes from rfc 4001, but I do not quite > > > > > > understand why this is necessary. I couldn't find many MIBs that > > > > > > allow dns(16), but some did not follow this MUST, and > > > > > > DISMAN-NSLOOKUP-MIB has: > > > > > > > > > > > > Specification of dns(16) as the value for this object > > > > > > means that a function such as, for example, getaddrinfo() > > > > > > or gethostbyname() should be performed to return one or > > > > > > more numeric addresses. > > > > > > > > > > > > Is this necessary (as in MUST)? > > > > > > > > > > The key really is the '(and when)' part. The point is that it makes a > > > > > difference whether you resolve the name when you load a config or > > > > > whether you resolve the name once the config is being used. I will > > > > > remove the parenthesis to make the "and when" part clearer. Since the > > > > > question when you resolve a name matters, I believe a MUST is > > > > > justified. > > > > > > > > I agree that the 'when part' justifies the MUST. I'm not convinced > > > > that the 'how part' MUST be described (does the example description > > > > from DISMAN-NSLOOKUP-MIB really say anything? "A function such as > > > > ..." seems pretty vague.) > > > > > > So is your proposal to replace "MUST describe how (and when)" with > > > "MUST describe when"? The "how" probably came into existence because > > > it can matter whether you resolve AAAA records before trying A records > > > and such things. > > > > Hmm.. I guess this makes sense. Maybe we should add some hints about > > how 'how and when' should be described. Just saying that > > getaddrbyinfo() or equivalent is used does not really answer the 'how' > > question. > > The good news is that there is already a "note" following the sentence > in question" > > The description clause of objects using the domain-name > type MUST describe how and when these names are > resolved to IP addresses. Note that the resolution of a > domain-name value may require to query multiple DNS records > (e.g., A for IPv4 and AAAA for IPv6). The order of the > resolution process and which DNS record takes precedence > depends on the configuration of the resolver. > > But then the last sentence kind of confuses things again since the > resolution order depends on the resolver config only if the > application chooses to not provide resolution hints. A more > accurate phrasing might be this: > > The description clause of objects using the domain-name > type MUST describe how and when these names are > resolved to IP addresses. Note that the resolution of a > domain-name value may require to query multiple DNS records > (e.g., A for IPv4 and AAAA for IPv6). The order of the > resolution process and which DNS records take precedence > can either be controlled explicitely by the caller of the > resolver or it may depend on the configuration of the > resolver. > > /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 j.schoenwaelder@jacobs-university.de Wed Jan 20 04:53:29 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED973A686C for ; Wed, 20 Jan 2010 04:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMMp-zCEnU8y for ; Wed, 20 Jan 2010 04:53:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 84ED73A67AD for ; Wed, 20 Jan 2010 04:53:28 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E4A2C0050; Wed, 20 Jan 2010 13:53:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SVxCEMkPw75w; Wed, 20 Jan 2010 13:53:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44426C0030; Wed, 20 Jan 2010 13:53:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81F341001D94; Wed, 20 Jan 2010 13:53:14 +0100 (CET) Date: Wed, 20 Jan 2010 13:53:14 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100120125314.GC806@elstar.local> Mail-Followup-To: "tom.petch" , Martin Bjorklund , "netmod@ietf.org" References: <20100118111513.GA634@elstar.local> <20100118.224220.85116840.mbj@tail-f.com> <20100118231414.GA2574@elstar.local> <20100119.104258.07110030.mbj@tail-f.com> <20100119114112.GB4271@elstar.local> <01e501ca99c4$57195c40$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01e501ca99c4$57195c40$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jan 2010 12:53:29 -0000 On Wed, Jan 20, 2010 at 10:41:27AM +0100, tom.petch wrote: > Martin > > You say in item 4 > '> > > > > > The YANG spec does not use the term "object". ' > but then in item 9 - since elided, implying agreement - you say > > > 9. xpath1.0: > > > > We should add something like: When an object is defined which > > uses this type, the description of the object MUST specify the > > XPath context in which the XPath expression is evaluated. > > Either object is in or object is out:-) I am not mixing the resolution of different comments. Thats all. > I would take it out but would prefer schema node to data node; I > think that that would be less confusing. I guess you are right since the data tree does not seem to include "data content" passed in notifications and RPCs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Wed Jan 20 08:16:19 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E514B3A6A83 for ; Wed, 20 Jan 2010 08:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb+lqVMUK6pU for ; Wed, 20 Jan 2010 08:16:19 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 9331C3A68A0 for ; Wed, 20 Jan 2010 08:16:16 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA06880; Wed, 20 Jan 2010 11:16:11 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA11823; Wed, 20 Jan 2010 11:16:11 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 20 Jan 2010 11:16:10 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: NETMOD Working Group In-Reply-To: <4B534B5C.8090401@iwl.com> Message-ID: References: <4B534B5C.8090401@iwl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:16:20 -0000 If you want to review the 'real' typedef, use this link instead of the one Andy provided. This message contained the final version of the proposal including the description statement. The description text may be relevant for the discussion. http://www.ietf.org/mail-archive/web/netmod/current/msg02987.html -dss On Sun, 17 Jan 2010, Andy Bierman wrote: > Hi, > > I think the 'real' typedef should be added to the ietf-yang-types > module. The thread occurred in May 2009, and the final > proposal from David Spakes in in this email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html > > I am working on some XPath-based power tools for NETCONF. > Now that we got rid of float64, there is no way to expose > an XPath number result, which is a double. The 'real' typedef > allows decimal64 to be used for this purpose. > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------------------------------------------------------- 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 andyb@iwl.com Wed Jan 20 08:36:38 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DBE73A68DF for ; Wed, 20 Jan 2010 08:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq2dekrFPw+R for ; Wed, 20 Jan 2010 08:36:37 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 476543A694A for ; Wed, 20 Jan 2010 08:36:37 -0800 (PST) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 318E12748178; Wed, 20 Jan 2010 11:36:33 -0500 (EST) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 01FED274895E; Wed, 20 Jan 2010 11:36:32 -0500 (EST) Message-ID: <4B5730CA.5050108@iwl.com> Date: Wed, 20 Jan 2010 08:35:22 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Spakes References: <4B534B5C.8090401@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:36:38 -0000 David Spakes wrote: > If you want to review the 'real' typedef, use this link instead > of the one Andy provided. This message contained the final version > of the proposal including the description statement. The description > text may be relevant for the discussion. > > http://www.ietf.org/mail-archive/web/netmod/current/msg02987.html > Actually, for my needs, using a 'string' works better because it maintains every encoded value that could occur in a float64. Since XML encoding is a string no matter what YANG calls it, the implementation is the same for float64 as it is for string. > -dss Andy > > > > On Sun, 17 Jan 2010, Andy Bierman wrote: > >> Hi, >> >> I think the 'real' typedef should be added to the ietf-yang-types >> module. The thread occurred in May 2009, and the final >> proposal from David Spakes in in this email: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg02682.html >> >> I am working on some XPath-based power tools for NETCONF. >> Now that we got rid of float64, there is no way to expose >> an XPath number result, which is a double. The 'real' typedef >> allows decimal64 to be used for this purpose. >> >> >> Andy >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From spakes@snmp.com Wed Jan 20 08:59:23 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E15C3A6A20 for ; Wed, 20 Jan 2010 08:59:23 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE5sOCcKgY6h for ; Wed, 20 Jan 2010 08:59:22 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id D67233A68DF for ; Wed, 20 Jan 2010 08:59:21 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA11678; Wed, 20 Jan 2010 11:59:08 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA12786; Wed, 20 Jan 2010 11:59:03 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 20 Jan 2010 11:59:03 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: NETMOD Working Group In-Reply-To: <20100118.225057.127568672.mbj@tail-f.com> Message-ID: References: <20100118072110.GA44023@elstar.local> <20100118.084419.168780613.mbj@tail-f.com> <20100118081600.GC44023@elstar.local> <20100118.225057.127568672.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 16:59:23 -0000 When float32 and float64 were replaced with decimal64, YANG document writers lost the ability to represent data having variable-length precision. My entire purpose for creating the 'real' typedef was to give that choice back to YANG document writers. Even if the 'real' typedef can't be used for XPath, is there a compelling argument to leave the 'real' typedef out of yang-types-05? There are probably other applications for it that this working group can't anticipate. I would like to propose one more time that we should add the 'real' typedef to yang-types-05 for the sake of those applications. -dss On Mon, 18 Jan 2010, Martin Bjorklund wrote: > The reasons we removed the float types were that (i) we believed that > a fixed point type was what people really needed and (ii) that we > couldn't find a representation that would work for XPath, XSD (RNG) > and easily for code. On Mon, 18 Jan 2010, Juergen Schoenwaelder wrote: > As far as I am concerned, the introduction of decimal64 was a good > thing, the removal of the float types was a bad thing. Giving data > modelers the choice is a good thing, denying them the choice because > we believe to know better is a bad thing. ------------------------------------------------------------- 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 andyb@iwl.com Wed Jan 20 09:37:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AD33A6943 for ; Wed, 20 Jan 2010 09:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcGAZnh4hjZ2 for ; Wed, 20 Jan 2010 09:37:46 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 253F03A6403 for ; Wed, 20 Jan 2010 09:37:46 -0800 (PST) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9FA9B13D324C; Wed, 20 Jan 2010 12:37:41 -0500 (EST) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 3145B13D3358; Wed, 20 Jan 2010 12:37:41 -0500 (EST) Message-ID: <4B573F1E.5050603@iwl.com> Date: Wed, 20 Jan 2010 09:36:30 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Spakes References: <20100118072110.GA44023@elstar.local> <20100118.084419.168780613.mbj@tail-f.com> <20100118081600.GC44023@elstar.local> <20100118.225057.127568672.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] revisit 'real' typedef in yang-types-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:37:46 -0000 David Spakes wrote: > When float32 and float64 were replaced with decimal64, YANG document > writers lost the ability to represent data having variable-length > precision. My entire purpose for creating the 'real' typedef was to > give that choice back to YANG document writers. > > Even if the 'real' typedef can't be used for XPath, is there a compelling > argument to leave the 'real' typedef out of yang-types-05? There are > probably other applications for it that this working group can't > anticipate. I would like to propose one more time that we should add the > 'real' typedef to yang-types-05 for the sake of those applications. > We can always extend this module, or create a new module later. I prefer that the YANG drafts to go to the IESG ASAP, so we can get started on some content and an access control model. > -dss > Andy From andyb@iwl.com Wed Jan 20 10:50:06 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16703A6948 for ; Wed, 20 Jan 2010 10:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytzWGgUInW-W for ; Wed, 20 Jan 2010 10:50:06 -0800 (PST) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 0AEBA3A6916 for ; Wed, 20 Jan 2010 10:50:06 -0800 (PST) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id EC6313EF3AA for ; Wed, 20 Jan 2010 13:50:01 -0500 (EST) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id CA2233F13FA for ; Wed, 20 Jan 2010 13:50:01 -0500 (EST) Message-ID: <4B575012.40801@iwl.com> Date: Wed, 20 Jan 2010 10:48:50 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: netmod@ietf.org References: <20100115000001.715493A6836@core3.amsl.com> In-Reply-To: <20100115000001.715493A6836@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-usage-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 18:50:06 -0000 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 : Guidelines for Authors and Reviewers of YANG Data Model Documents > Author(s) : A. Bierman > Filename : draft-ietf-netmod-yang-usage-03.txt > Pages : 29 > Date : 2010-01-14 > > This memo provides guidelines for authors and reviewers of standards > track specifications containing YANG data model modules. Applicable > portions may be used as a basis for reviews of other YANG data model > documents. Recommendations and procedures are defined, which are > intended to increase interoperability and usability of NETCONF > implementations which utilize YANG data model modules. > .... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-03.txt > Please review the latest changes to the YANG Usage draft. The previous 2 revisions had very few changes. The -03 draft contains the consensus text on import/include by revision: - if any groupings used, then SHOULD use revision date There is no mention of typedefs anymore. This was the only significant change. Andy From andyb@iwl.com Wed Jan 20 11:56:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2ADC3A681D for ; Wed, 20 Jan 2010 11:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMBG8i-te9iU for ; Wed, 20 Jan 2010 11:56:45 -0800 (PST) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 594553A63EC for ; Wed, 20 Jan 2010 11:56:45 -0800 (PST) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 8106E90819B for ; Wed, 20 Jan 2010 14:56:41 -0500 (EST) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 636B89083BE for ; Wed, 20 Jan 2010 14:56:41 -0500 (EST) Message-ID: <4B575FB1.4040206@iwl.com> Date: Wed, 20 Jan 2010 11:55:29 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-10: ship it X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 19:56:46 -0000 Hi, I have done a detailed review of the diffs between yang-09 and yang-10. I approve of all the changes, and thank Juergen for all these terminology clarifications. I think they make the text better in each case. We should thank Martin for doing an awesome job, and then give this draft to the IESG before anybody can think of more things to change (including me!) Andy From lhotka@cesnet.cz Thu Jan 21 09:16:27 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBE528C171 for ; Thu, 21 Jan 2010 09:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ATfWD7R3ivZ for ; Thu, 21 Jan 2010 09:16:26 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 989BA28C168 for ; Thu, 21 Jan 2010 09:16:19 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id B04902CDE055 for ; Thu, 21 Jan 2010 18:16:14 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 21 Jan 2010 18:16:13 +0100 Message-ID: <1264094173.5406.64.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: [netmod] review of yang-types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:16:27 -0000 Hi, I reviewed the document, especially concentrating on the regular expressions. My comments: 1. In several cases, the expressions use superfluous parentheses which make the expressions longer and less comprehensible. I think they should be removed. For example: OLD typedef object-identifier { type string { pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))' + '(\.(0|([1-9]\d*)))*'; } NEW typedef object-identifier { type string { pattern '([01]\.[1-3]?[0-9]|2\.(0|[1-9]\d*))(\.(0|[1-9]\d*))*'; } 2. In the pattern for object-identifier-128, the dot should be escaped: OLD typedef object-identifier-128 { type object-identifier { pattern '\d*(.\d*){1,127}'; } NEW typedef object-identifier-128 { type object-identifier { pattern '\d*(\.\d*){1,127}'; } 3. Another minor simplification (the sign for timezone): OLD typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|(\+|-)\d{2}:\d{2})'; } ŃEW typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|[\-+]\d{2}:\d{2})'; } (This pattern is rather lax, but I guess it is intentional.) 4. phys-address - is it correct that it is allowed to be empty? 5. The pattern for ipv4-address doesn't allow leading zeros in any of the four octets, for example, this doesn't match: 127.000.000.001. Moreover, the pattern is unnecessarily complicated. I propose to use the same pattern as is used later for ipv4-prefix: OLD typedef ipv4-address { type string { pattern '((0' + '|(1[0-9]{0,2})' + '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))' + '|([3-9][0-9]?)' + ')' + '\.){3}' + '(0' + '|(1[0-9]{0,2})' + '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))' + '|([3-9][0-9]?)' + ')(%[\p{N}\p{L}]+)?'; } NEW typedef ipv4-address { type string { pattern '((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])' + '(%[\p{N}\p{L}]+)?'; } 6. An isolated dot "." matches the pattern for domain-name. I understand it is used e.g. in DNS zone files, but IMO it is the same case as the zero value for port-number and should be handled via a union where appropriate. 7. In the descriptions of gauge32 and gauge64: s/can not/cannot/ Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C