From david.partain@ericsson.com Tue May 4 02:18: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 6E7913A6988 for ; Tue, 4 May 2010 02:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 smbjjlHBEXNJ for ; Tue, 4 May 2010 02:18:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 427A33A697B for ; Tue, 4 May 2010 02:18:05 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-a3-4bdfe63f100d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0D.11.21861.F36EFDB4; Tue, 4 May 2010 11:17:51 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 11:17:51 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 May 2010 11:17:51 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 4 May 2010 11:17:50 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201005041117.50463.david.partain@ericsson.com> X-OriginalArrivalTime: 04 May 2010 09:17:51.0153 (UTC) FILETIME=[AB99E210:01CAEB6A] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Anaheim IETF77 NETMOD minutes of meeting 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, 04 May 2010 09:18:07 -0000 Hi, The _preliminary_ minutes from Anaheim are at http://www.ietf.org/proceedings/10mar/minutes/netmod.txt Please have a look and let me know if you see mistakes that need to be created. Sorry for the delay! And thanks to Andy Bierman and Kent Watsen for taking notes! Cheers, David From dromasca@avaya.com Thu May 6 01:39: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 49AEC3A690E for ; Thu, 6 May 2010 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_50=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 cmJSm+KjkdQQ for ; Thu, 6 May 2010 01:39:41 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 722A83A6844 for ; Thu, 6 May 2010 01:39:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,339,1270440000"; d="scan'208";a="187419795" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 May 2010 04:39:25 -0400 X-IronPort-AV: E=Sophos;i="4.52,339,1270440000"; d="scan'208";a="471459302" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 May 2010 04:39:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 10:39:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] 4th draft for yang module security considerations Thread-Index: AcrmNL2druHAG/TiRb+CX2Zpdd0ziQAAbNeAAbBDW6A= References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop><43447B97F09044418C553FBF37EFB291@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Mark Ellison" Cc: NETMOD Working Group Subject: Re: [netmod] 4th draft for yang module security considerations 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, 06 May 2010 08:39:42 -0000 FYI - this is going out to the Security AD's.=20 Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, April 27, 2010 9:24 PM > To: Bert Wijnen (IETF); Mark Ellison > Cc: NETMOD Working Group > Subject: Re: [netmod] 4th draft for yang module security=20 > considerations >=20 > If there are no major issues I propose that we send this=20 > version to the Security ADs for review (with nits fixed) >=20 > If there still are major issues please jump in in the next two days.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: netmod-bounces@ietf.org > > [mailto:netmod-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > > Sent: Tuesday, April 27, 2010 9:04 PM > > To: Mark Ellison > > Cc: NETMOD Working Group > > Subject: Re: [netmod] 4th draft for yang module security=20 > > considerations > >=20 > > Yep. Thanks Mark. > >=20 > > Bert > > ----- Original Message ----- > > From: "Mark Ellison" > > To: "Bert Wijnen (IETF)" > > Cc: "NETMOD Working Group" > > Sent: Tuesday, April 27, 2010 7:27 PM > > Subject: Re: [netmod] 4th draft for yang module security=20 > > considerations > >=20 > >=20 > > > Bert, > > > > > > One minor editorial nit in the following: > > > > > >> Further, if new RPC operations have been defined, then it the=20 > > >> security considerations of each new RPC operation MUST be=20 > > >> explained. > > > > > > s/then it the/then the/ > > > > > > Regards, > > > > > > Mark > > > > > > On Tue, Apr 27, 2010 at 3:50 AM, Bert Wijnen (IETF) > > > wrote: > > > > > >> We had quite a few discussions on the 3rd revision. > > >> From my reading however, it seems we more or less agree that: > > >> > > >> - security considerations must be listed in the SC=20 > section and not=20 > > >> in a separtely tagged description clause with the > > nodes themselves. > > >> - we cannot do a blanket statement that basically ALL=20 > config data =20 > > >> is sensitive > > >> - it is OK toi list a container or node list if all the=20 > leaves have =20 > > >> the sanme/similar secuirty considereations. > > >> Based on that, I think it is best to make that last point > > more explicit. > > >> I basically had that, but I was still using the MIB term > > of "subtrees". > > >> So the 4th revision (last??) of the template-text would be as > > >> follows: > > >> > > >> ---- > > >> > > >> Each specification that defines one or more YANG modules MUST=20 > > >> contain a section that discusses security=20 > considerations relevant=20 > > >> to those modules. > > >> This section MUST be patterned after the latest =20 > approved template=20 > > >> (available at [ed: URL TBD]). > > >> > > >> In particular, writable data nodes that could be especially=20 > > >> disruptive if abused MUST be explicitly listed by name and the=20 > > >> associated security risks MUST be spelled out. > > >> > > >> Similarly, readable data nodes that contain especially=20 > sensitive=20 > > >> information or that raise significant privacy concerns MUST be=20 > > >> explicitly listed by name and the reasons for the =20 > > >> sensitivity/privacy concerns MUST be explained. > > >> > > >> Further, if new RPC operations have been defined, then it the=20 > > >> security considerations of each new RPC operation MUST be=20 > > >> explained. > > >> > > >> Note: it is best to list a container or list node if all the =20 > > >> leaves in the container or list node share the same or similar=20 > > >> security considerations. > > >> > > >> X. Security Considerations > > >> > > >> -- if you have any writeable data nodes (those are all the > > >> -- "config true" nodes, and remember, that is the default) > > >> -- describe their specific sensitivity or vulnerability. > > >> > > >> There are a number of data nodes defined in this YANG=20 > module which=20 > > >> are writable/creatable/deletable (i.e. config true, which is the=20 > > >> default). These data nodes may be considered sensitive or=20 > > >> vulnerable in some network environments. Write operations (e.g.=20 > > >> edit-config) to these data nodes without proper=20 > protection can have=20 > > >> a negative effect on network operations. These are the=20 > containers,=20 > > >> list nodes and data nodes with their specific > > >> sensitivity/vulnerability: > > >> > > >> > are sensitive> > > >> > > >> -- for all YANG modules you must evaluate whether any=20 > readable data > > >> -- nodes (those are all the "config false" nodes, but also > > all other > > >> -- nodes, because they can also be read via operations=20 > like get or > > >> -- get-config) are sensitive or vulnerable (for instance, if they > > >> -- might reveal customer information or violate personal privacy > > >> -- laws such as those of the European Union if exposed to > > >> -- unauthorized parties) > > >> > > >> Some of the readable data nodes in this YANG module may be=20 > > >> considered sensitive or vulnerable in some network environments. > > >> It is thus important to control read access (e.g. via get,=20 > > >> get-config or notification) to these data nodes. These are the=20 > > >> containers, list nodes and data nodes with their specific > > >> sensitivity/vulnerability: > > >> > > >> > are sensitive> > > >> > > >> -- if your YANG module has defined any rpc operations > > >> -- describe their specific sensitivity or vulnerability. > > >> > > >> Some of the RPC operations in this YANG module may be considered=20 > > >> sensitive or vulnerable in some network environments. =20 > It is thus=20 > > >> important to control access to these operations. These are the=20 > > >> operations and their sensitivity/vulnerability: > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >=20 > >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Thu May 6 02:18: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 1D55E3A696E for ; Thu, 6 May 2010 02:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_50=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 1DO22QMGYPUc for ; Thu, 6 May 2010 02:18:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3BFD23A6968 for ; Thu, 6 May 2010 02:18:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,340,1270440000"; d="scan'208";a="187424307" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 May 2010 05:18:29 -0400 X-IronPort-AV: E=Sophos;i="4.52,340,1270440000"; d="scan'208";a="459031252" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 May 2010 05:18:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 11:18:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-netmod-yang Thread-Index: AcrslKmcSgXvnReBSdyB9bWesfQh+gAaFkOg From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: DISCUSS and COMMENT: draft-ietf-netmod-yang 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, 06 May 2010 09:18:46 -0000 Was this DISCUSS and COMMENT from Peter addressed?=20 Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, May 05, 2010 11:51 PM To: iesg@ietf.org Cc: netmod-chairs@tools.ietf.org; draft-ietf-netmod-yang@tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-netmod-yang=20 Discuss: 1. In Section 7.1.4 and elsewhere, the meaning of the prefix statement is unclear: The "prefix" statement is used to define the prefix associated with the module and its namespace. Does this mean that this prefix is reserved? How shall applications handle conflicts among prefix names asserted by different modules? Does the IANA perhaps need to maintain a registry of prefix names? Do prefix names apply to module names (e.g., in accordance with the "orgprefix-modname" structure that appears to be assumed in this specification)? 2. In Section 7.1.9, the "revision" statement has the structure "YYYY-MM-DD"; this prevents an entity from releasing multiple versions on the same day, although it's not clear if that is serious issue (e.g., an entity might find a significant error or security problem with a released revision and might need to generate a new revision immediately thereafter). 3. In Section 7.19.3, the "description" statement contains a high-level textual description of this definition, which appears to be human-readable. However, no language tagging is provided in accordance with RFC 2277. 5. In Section 9, some of the built-in types (e.g., various integers) can have multiple lexical representations. This is justified as follows: The lexicographic representation of a value of a certain type is used in the NETCONF PDUs, and when specifying default values and numerical ranges in YANG modules. And also justified on the grounds of "convenience" in Section 9.2.1. What is this "convenience"? Is there really a strong reason to have multiple lexical representations? Is it a MUST for all implementations to support all lexical representations? If so, doesn't that increase code complexity? If not, doesn't that harm interoperability? 6. No motivation is provided for the alternate "YIN" syntax. Why is this here? Does it harm interoperability to have more than one syntax? (Perhaps not, given that there is a one-to-one mapping between them.) Does an implementation need to support both YANG and YIN? 7. Protocol versioning is good and seems to be represented here in the namespace names "urn:ietf:params:xml:ns:yang:1" and "urn:ietf:params:xml:ns:yang:yin:1". However, no guidance is provided about possible versioning of the data format, under what circumstances the version number would need to change, how older versions and newer versions can interoperate, etc. 8. The IANA considerations seem to request that the IANA shall enforce the structure "orgprefix-modname", but that structure is not required anywhere else in the document (although it is suggested). The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844] while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams must have a similar suitable prefix. =20 Furthermore, it is not clear what it means for the IANA to maintain a module. The prefix 'iana-' is reserved for modules maintained by IANA. Comment: 1. Throughout the document, change "lexicographic" and "lexicographical" to "lexical" ("lexicographic" means "related to the practice of compiling dictionaries" whereas "lexical" means "related to a vocabulary"). 2. Please expand the acronym PDU (protocol data unit) on first use in Section 4.2.7. (By the way, this term does not seem to be defined in RFC 4741 or any other core NETCONF specification, nor even in RFC 2578, so an explanation might be in order here for the benefit of readers not familiar with NETCONF or SNMP.) 3. In Section 7.1.8, it appears that the "contact" statement has no internal structure and is free-form text. Does this make automated processing more difficult? 4. In Section 8.3.1 (Payload Parsing), the following unmatched constraints both produce an "unknown-element" error-tag... o data for a node tagged with "if-feature" is present, and the feature is not supported by the device o data for a node tagged with "when" is present, and the "when" condition evaluates to "false" It would seem preferable to differentiate between these two case, for example by defining a "feature-not-implemented" error-tag for the first case. 5. Section 10 has the following sentence: Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are encoded in the namespace. Please change "encoded in" to "qualified by". A namespace does not provide an encoding. You might also be consistent about "qualified by", such as here: o If the argument is encoded as an element, it is placed to the same namespace as its parent keyword element. That is, change "placed to" to "qualified by". Perhaps search through the document for other instances (I have not performed a thorough search). 6. Similarly, the term "encoding" is used when talking about how to represent data in XML. As just one example: The argument of a YANG statement is encoded in YIN either as an XML attribute or a subelement of the keyword element. Table 1 defines the encoding for the set of YANG keywords. I would suggest changing "encoded" to "represented" and "encoding" to "mapping" (or choose other words that you find suitable). 7. Editorial nit, change "less" to "fewer" here: o A "min-elements" statement may be removed, or changed to require less elements. 8. In Section 12, the ABNF for "identifier" does not programmatically restrict an entity from specifying an identifier that starts with 'xml' (it is restricted by means of a human-readable comment). It's not clear whether a programmatic restriction is truly necessary, however. identifier-arg =3D identifier ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) identifier =3D (ALPHA / "_")=20 *(ALPHA / DIGIT / "_" / "-" / ".")=20 9. In Section 13, the "unknown-element" referred to under Section 8.3.1 is not defined. From david.partain@ericsson.com Thu May 6 05:59: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 C01913A67B5 for ; Thu, 6 May 2010 05:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_40=-0.185, 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 x8nG+BDkY8pg for ; Thu, 6 May 2010 05:59:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CC99B28C140 for ; Thu, 6 May 2010 05:57:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-52-4be2bca656ff Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 55.CA.08537.6ACB2EB4; Thu, 6 May 2010 14:57:10 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 14:57:10 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 14:57:09 +0200 Content-Language: en-US Content-Disposition: inline From: David Partain Organization: Ericsson AB User-Agent: KMail/1.9.10 MIME-Version: 1.0 Date: Thu, 6 May 2010 14:57:09 +0200 To: netmod@ietf.org Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005061457.09782.david.partain@ericsson.com> X-OriginalArrivalTime: 06 May 2010 12:57:09.0906 (UTC) FILETIME=[A3A7BF20:01CAED1B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 06 May 2010 12:59:06 -0000 Greetings, This is an eleven-day working group last call on the current working group document: Title: An NETCONF- and NETMOD-based Architecture for Network Management URL: http://tools.ietf.org/html/draft-ietf-netmod-arch-05 This WGLC will end on May 17, 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. NOTE: It is very important that the chairs can judge whether the Working Group thinks we're finished or not. As such, please provide your comments, even if it is only to say "It's fine. Ship it!" Thanks. David^2 From david.partain@ericsson.com Thu May 6 05:59:10 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 4637B28C140 for ; Thu, 6 May 2010 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[AWL=1.604, 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 R1hVprQ0emQ9 for ; Thu, 6 May 2010 05:59:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 64C6128C14C for ; Thu, 6 May 2010 05:57:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-67-4be2bca90eb8 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C7.CA.08537.9ACB2EB4; Thu, 6 May 2010 14:57:13 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 14:57:13 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 14:57:13 +0200 Content-Language: en-US Content-Disposition: inline From: David Partain Organization: Ericsson AB Date: Thu, 6 May 2010 14:57:13 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 To: netmod@ietf.org Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005061457.13114.david.partain@ericsson.com> X-OriginalArrivalTime: 06 May 2010 12:57:13.0466 (UTC) FILETIME=[A5C6F5A0:01CAED1B] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: Guidelines for Authors and Reviewers of YANG Data Model Documents 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, 06 May 2010 12:59:10 -0000 Greetings, This is an eleven-day working group last call on the current working group document: Title: Guidelines for Authors and Reviewers of YANG Data Model Documents URL: http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-04 This WGLC will end on May 17, 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. NOTE: It is very important that the chairs can judge whether the Working Group thinks we're finished or not. As such, please provide your comments, even if it is only to say "It's fine. Ship it!" Thanks. David^2 From david.partain@ericsson.com Thu May 6 06:10:03 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 874133A6BE2 for ; Thu, 6 May 2010 06:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=-0.931, 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 mu1yvvla6Z7p for ; Thu, 6 May 2010 06:10:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id ADBD528C159 for ; Thu, 6 May 2010 06:07:37 -0700 (PDT) X-AuditID: c1b4fb39-b7c85ae000005565-1e-4be2bf0bf0fe Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.00.21861.B0FB2EB4; Thu, 6 May 2010 15:07:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 15:07:23 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 15:07:23 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Thu, 6 May 2010 15:07:22 +0200 User-Agent: KMail/1.9.10 References: <201005061457.09782.david.partain@ericsson.com> In-Reply-To: <201005061457.09782.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201005061507.22910.david.partain@ericsson.com> X-OriginalArrivalTime: 06 May 2010 13:07:23.0125 (UTC) FILETIME=[11298A50:01CAED1D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 06 May 2010 13:10:03 -0000 On Thursday 06 May 2010 14.57.09 David Partain wrote: > Greetings, > > This is an eleven-day working group last call on the current working group > document: > > Title: An NETCONF- and NETMOD-based Architecture for Network Management > URL: http://tools.ietf.org/html/draft-ietf-netmod-arch-05 Hi, First comment... Contrib hat on. The title needs to be changed. The current one is gramatically incorrect (/An NETCONF/A NETCONF/ is non-negotiable :-)), but I actually think it should be: A NETCONF- and YANG-based Architecture for Network Management or An Architecture for Network Management using NETCONF and YANG I personally prefer the latter. NETMOD Is not the technology name and I think that's what should be in the title. Cheers, David From phil@juniper.net Thu May 6 07:09:34 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 AD30D28C37A for ; Thu, 6 May 2010 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 lvN72-Br-Tiy for ; Thu, 6 May 2010 07:09:34 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 6711D28C3C9 for ; Thu, 6 May 2010 06:50:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS+LJI2beY1HVOUJwWJLvAuQQmIlb4pQX@postini.com; Thu, 06 May 2010 06:50:30 PDT 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.436.0; Thu, 6 May 2010 06:47:55 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 06:47:55 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 06:47:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 06:47:54 -0700 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 o46DlrD65810; Thu, 6 May 2010 06:47:54 -0700 (PDT) (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 o46DUkou050867; Thu, 6 May 2010 13:30:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005061330.o46DUkou050867@idle.juniper.net> To: David Partain In-Reply-To: <201005061507.22910.david.partain@ericsson.com> Date: Thu, 6 May 2010 09:30:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2010 13:47:54.0679 (UTC) FILETIME=[BA7B3C70:01CAED22] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 06 May 2010 14:09:34 -0000 David Partain writes: >> This is an eleven-day working group last call on the current working group >> document: I like it. Ship it. >An Architecture for Network Management using NETCONF and YANG >I personally prefer the latter. >NETMOD Is not the technology name and I think that's what should be in the >title. +1 Thanks, Phil From hiroto.shibuya@gmail.com Thu May 6 14:05:10 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 C85823A6C60 for ; Thu, 6 May 2010 14:05:10 -0700 (PDT) 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=[AWL=-0.555, BAYES_50=0.001, HTML_MESSAGE=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 rNiDe9Jj3LEE for ; Thu, 6 May 2010 14:05:09 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 9E4A43A6AC0 for ; Thu, 6 May 2010 14:05:09 -0700 (PDT) Received: by iwn27 with SMTP id 27so492883iwn.5 for ; Thu, 06 May 2010 14:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=TtzNt3bDmL3uF+Rz9vs8trliymO1JfzrcMmBUBgpFCw=; b=xKzWJkJqEEVS5TKWA0q0eRAxjjdXy6dGpYZOwsq3O4sM7wp3+0mYt6GVYBIsA5DH/Q hIzV+ZOI6s86Gt+0UslNGc8+xSUv8zBEWNIUGo0gc1taP16y44FQicbXNnREWq+ajwA6 Eoe4ALhBoSQ4p5ifokgvwiy/1xgESMuwNy5Mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sIWqR1X30o+wmRXHprzmTK3roH1GD5R2E6WGxPxa1Ezajg1b9ESfbnS60ioL0k4/VN TYEus1BXlPijVhmVU4hr49594hWdysjfgcs1nMiG/8IiA2xLJC7oq0erwNXdlv2MvNs3 nGRDvRnLcW5qhnwTzoL+n/rKgGFHMgvQYxK/I= MIME-Version: 1.0 Received: by 10.231.183.203 with SMTP id ch11mr488573ibb.47.1273179894313; Thu, 06 May 2010 14:04:54 -0700 (PDT) Received: by 10.231.186.195 with HTTP; Thu, 6 May 2010 14:04:54 -0700 (PDT) Date: Thu, 6 May 2010 17:04:54 -0400 Message-ID: From: Hiroto Shibuya To: netmod@ietf.org Content-Type: multipart/alternative; boundary=0016363b8b3a55f71c0485f34b86 Subject: [netmod] augmenting imported module 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, 06 May 2010 21:11:27 -0000 --0016363b8b3a55f71c0485f34b86 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have recently learned about YANG during my search for data modeling language for my code generation project outside of NETCONF context. One particular aspect I liked about YANG was support for augmentation. -------- 4.2.8. Extending Data Models (augment) YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) or an external module. -------- Now, I interpreted this to mean, that when there is published, complete YANG module, I can import it, augment it with small modification and use the rest of schema AS IS. I also intepreted that the method of doing that is by "import" and "augment". But while playing around with YANG schema with pyang tool, I noticed that the language in the draft is not particulary clear about how this can be achieved. First it says: -------- 4.1. Functional Overview ... A module can import data from other external modules, -------- But later, -------- 5.1. Modules and Submodules A module uses the "include" statement to include its submodules, and the "import" statement to reference external modules. -------- and then, -------- 7.1.5. The import Statement The "import" statement makes definitions from one module available inside another module or submodule. -------- So, when I "import", I can *refer* to things like "group" and "use" it in my module, but as far as I can tell, YANG does not provide mechanism to simply pull in nodes from the external module. You can do that by including submodule, but you cannot do that with external module. So even if you "augment" a node in the external module, "augment" statement have no functionality to pull in node from external module and it simply augment the node in that external module, but have no effect on the current module. Since pyang is implemented to this language, when I define a module to only augment an imported module, pyang will verify everything is ok but when I tried to output the schema, it output an empty schema. I did a local patch to pyang to change the semantics of "import" to actually "include" the contents of the imported module and the result is what I wanted, but I wondered if this is what is originally meant by the statement in "4.2.8. Extending Data Models (augment)". Hiroto --0016363b8b3a55f71c0485f34b86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have recently learned about YANG during my search for data mod= eling
language for my code generation project outside of NETCONF context= .

One particular aspect I liked about YANG was support for augmentat= ion.

--------
4.2.8.=A0 Extending Data Models (augment)

=A0=A0 YAN= G allows a module to insert additional nodes into data models,
=A0=A0 in= cluding both the current module (and its submodules) or an external
=A0= =A0 module.
--------

Now, I interpreted this to mean, that when there is publish= ed,
complete YANG module, I can import it, augment it with small
modi= fication and use the rest of schema AS IS.=A0 I also intepreted that
the= method of doing that is by "import" and "augment".

But while playing around with YANG schema with pyang tool, I noticedthat the language in the draft is not particulary clear about how this
= can be achieved.

First it says:

--------
4.1.=A0 Functiona= l Overview
=A0 ...
=A0=A0 A module can import data from other external modules,
= --------

But later,

--------
5.1.=A0 Modules and Submodule= s

=A0=A0 A module uses the "include" statement to include = its submodules, and
=A0=A0 the "import" statement to reference external modules.
-= -------

and then,

--------
7.1.5.=A0 The import Statement<= br>
=A0=A0 The "import" statement makes definitions from one m= odule available
=A0=A0 inside another module or submodule.
--------

So, when I &q= uot;import", I can *refer* to things like "group" and "= use" it
in my module, but as far as I can tell, YANG does not provi= de
mechanism to simply pull in nodes from the external module.=A0 You can
d= o that by including submodule, but you cannot do that with external
modu= le.

So even if you "augment" a node in the external module= , "augment"
statement have no functionality to pull in node from external module
and= it simply augment the node in that external module, but have no
effect = on the current module.

Since pyang is implemented to this language, = when I define a module to
only augment an imported module, pyang will verify everything is ok
but = when I tried to output the schema, it output an empty schema.

I did = a local patch to pyang to change the semantics of "import" to
actually "include" the contents of the imported module and the re= sult
is what I wanted, but I wondered if this is what is originally mean= t
by the statement in "4.2.8.=A0 Extending Data Models (augment)&qu= ot;.

Hiroto
--0016363b8b3a55f71c0485f34b86-- From j.schoenwaelder@jacobs-university.de Thu May 6 15:06: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 E726C3A6AFF for ; Thu, 6 May 2010 15:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.04 X-Spam-Level: X-Spam-Status: No, score=0.04 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 QhViAj0A1aNO for ; Thu, 6 May 2010 15:06:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 76D0E3A6BC6 for ; Thu, 6 May 2010 15:06:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F4B5C0060; Fri, 7 May 2010 00:05:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GfoDIj31tiK1; Fri, 7 May 2010 00:05:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 520F2C0055; Fri, 7 May 2010 00:05:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 550BD11F48DD; Fri, 7 May 2010 00:05:53 +0200 (CEST) Date: Fri, 7 May 2010 00:05:53 +0200 From: Juergen Schoenwaelder To: Hiroto Shibuya Message-ID: <20100506220552.GA3137@elstar.local> Mail-Followup-To: Hiroto Shibuya , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] augmenting imported module 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, 06 May 2010 22:06:16 -0000 On Thu, May 06, 2010 at 11:04:54PM +0200, Hiroto Shibuya wrote: > So even if you "augment" a node in the external module, "augment" > statement have no functionality to pull in node from external module > and it simply augment the node in that external module, but have no > effect on the current module. Yes, this is how augmentation works. Is section 7.15 not clear enough? > I did a local patch to pyang to change the semantics of "import" to > actually "include" the contents of the imported module and the result > is what I wanted, but I wondered if this is what is originally meant > by the statement in "4.2.8. Extending Data Models (augment)". No, what you want is to use a grouping and to add to it. This of course requires that someone designed a reusable grouping. Copying arbitrary definitions into a new module is not a good idea because this means the copied definitions live in a new namespace and thus there is no interoperability. The augmentation mechanism of YANG preserves interoperability since it avoids copying definitions into a new namespace. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From hiroto.shibuya@gmail.com Thu May 6 15:37: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 2F15D3A688C for ; Thu, 6 May 2010 15:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_50=0.001, HTML_MESSAGE=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 zWvnvdgNfHpV for ; Thu, 6 May 2010 15:37:18 -0700 (PDT) Received: from mail-iw0-f183.google.com (mail-iw0-f183.google.com [209.85.223.183]) by core3.amsl.com (Postfix) with ESMTP id 303EB3A679C for ; Thu, 6 May 2010 15:37:18 -0700 (PDT) Received: by iwn13 with SMTP id 13so591511iwn.17 for ; Thu, 06 May 2010 15:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=C4Kz+pYSM1k4v7679ZQZzSRjonmdl4z5CN8RVkR5H9E=; b=tB6/PKwHYoG7dXGm6GpHSbeIw9rnF4IhLMcZ3WTSLFAp63+yllZD/9kZjcZjwc1U17 LvFDv/97g1TVrbWKGB9scyiUQCtvI+bRh/wULyHic743TIxF75qMKA7hdNsVFAzcSiga l994PKRn9c+jbuIXzypr7Z9PmW82rkWhGz8cY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WAHrNiZ3ZONs2KAOEL2EJ0ETMOLeIDM5ljbA3kV+XUuhE/IUBzRpjMNIwL3UyLb1wN lTSFYlz/EVFoIc80XPnjWnFYc73OyX40iVtf3W2WKjbOccxiD/MnDef/04lx+UTzbfrA bFZ7Q5ZUK9+9BN4WRomuUReNTJE9NveZdXEtI= MIME-Version: 1.0 Received: by 10.231.79.196 with SMTP id q4mr2279033ibk.69.1273185421729; Thu, 06 May 2010 15:37:01 -0700 (PDT) Received: by 10.231.186.195 with HTTP; Thu, 6 May 2010 15:37:01 -0700 (PDT) In-Reply-To: <20100506220552.GA3137@elstar.local> References: <20100506220552.GA3137@elstar.local> Date: Thu, 6 May 2010 18:37:01 -0400 Message-ID: From: Hiroto Shibuya To: Juergen Schoenwaelder , Hiroto Shibuya , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001485eaffd8cba7920485f49483 Subject: Re: [netmod] augmenting imported module 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, 06 May 2010 22:37:19 -0000 --001485eaffd8cba7920485f49483 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 6, 2010 at 6:05 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, May 06, 2010 at 11:04:54PM +0200, Hiroto Shibuya wrote: > > > So even if you "augment" a node in the external module, "augment" > > statement have no functionality to pull in node from external module > > and it simply augment the node in that external module, but have no > > effect on the current module. > > Yes, this is how augmentation works. Is section 7.15 not clear enough? > > > I did a local patch to pyang to change the semantics of "import" to > > actually "include" the contents of the imported module and the result > > is what I wanted, but I wondered if this is what is originally meant > > by the statement in "4.2.8. Extending Data Models (augment)". > > No, what you want is to use a grouping and to add to it. This of > course requires that someone designed a reusable grouping. Copying > arbitrary definitions into a new module is not a good idea because > this means the copied definitions live in a new namespace and thus > there is no interoperability. The augmentation mechanism of YANG > preserves interoperability since it avoids copying definitions into a > new namespace. > > Sounds like I was thinking this backward. So if I create module2 which is augmenting module1, module2 is actually modifying schema within module1 and not creating new schema within module2 which augments module1? So in that situation, if I load module1 and module2 into a tool to munch on then, it should spit out augmented module1, and not spit out module2 (which is empty anyway)? Hiroto --001485eaffd8cba7920485f49483 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 6, 2010 at 6:05 PM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:=
On Thu, May 06, 2010 at 1= 1:04:54PM +0200, Hiroto Shibuya wrote:

> So even if you "augment" a node in the external module, &quo= t;augment"
> statement have no functionality to pull in node from external module > and it simply augment the node in that external module, but have no > effect on the current module.

Yes, this is how augmentation works. Is section 7.15 not clear enough= ?

> I did a local patch to pyang to change the semantics of "import&q= uot; to
> actually "include" the contents of the imported module and t= he result
> is what I wanted, but I wondered if this is what is originally meant > by the statement in "4.2.8. =A0Extending Data Models (augment)&qu= ot;.

No, what you want is to use a grouping and to add to it. This of
course requires that someone designed a reusable grouping. Copying
arbitrary definitions into a new module is not a good idea because
this means the copied definitions live in a new namespace and thus
there is no interoperability. The augmentation mechanism of YANG
preserves interoperability since it avoids copying definitions into a
new namespace.
=

Sounds like I was thinking this backward.= =A0

So if I create module2 which is augmenting module1, mod= ule2 is actually modifying schema within module1 and not creating new schem= a within module2 which augments module1? =A0 =A0So in that situation, if I = load module1 and module2 into a tool to munch on then, it should spit out a= ugmented module1, and not spit out module2 (which is empty anyway)?

Hiroto
=A0
--001485eaffd8cba7920485f49483-- From lhotka@cesnet.cz Thu May 6 23:25: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 D95323A6892 for ; Thu, 6 May 2010 23:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.178 X-Spam-Level: * X-Spam-Status: No, score=1.178 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=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 OC3lUhclRbHN for ; Thu, 6 May 2010 23:25:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D6F013A6883 for ; Thu, 6 May 2010 23:25:00 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 45BC32CDE057; Fri, 7 May 2010 08:24:47 +0200 (CEST) From: Ladislav Lhotka To: Hiroto Shibuya In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 07 May 2010 08:24:46 +0200 Message-ID: <1273213486.31401.15.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] augmenting imported module 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, 07 May 2010 06:25:02 -0000 Hiroto Shibuya píše v Čt 06. 05. 2010 v 17:04 -0400: > So even if you "augment" a node in the external module, "augment" > statement have no functionality to pull in node from external module > and it simply augment the node in that external module, but have no > effect on the current module. What you can do is to set up a data model formed by *both* the external module and the augmenting module. The resulting data tree is then the union of the trees from both modules and the augmenting applies as well. > > Since pyang is implemented to this language, when I define a module to > only augment an imported module, pyang will verify everything is ok > but when I tried to output the schema, it output an empty schema. The DSDL plugin (the code from the Google Code repository) does what you want. For example, you can use the yang2dsdl script with multiple modules to get RELAX NG, Schematron and DSRL schemas for a reply to as follows: $ yang2dsdl -t get-reply foo.yang bar.yang An instance document can also be directly validated using this script. The details are in the manpage. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From hiroto.shibuya@gmail.com Fri May 7 00:07: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 0364E3A6ADE for ; Fri, 7 May 2010 00:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 Gv8odsxWkCNE for ; Fri, 7 May 2010 00:07:42 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 12CF63A67D2 for ; Fri, 7 May 2010 00:07:42 -0700 (PDT) Received: by iwn27 with SMTP id 27so1078885iwn.5 for ; Fri, 07 May 2010 00:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0gFZtTPktrv44JsOSr/beqSLkhhuHwRgl4JtZ6Ts7js=; b=pnpnuKKtlloUZ1A6JYcV6rOZwVMpihuWWxE5sxWW2HFdhCeLoFFmO6DjL4sdzd5Rw0 JozRyFge67rS7rdbm4yLxTZ8xWlariWnNhY18+5DuNQX5Xsg7KTFHy74Mp/+WRnHBn6W 7mF0/uFErv/fy1oRUwRE2084W59yIn5+/FpGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ru3tdkvr+dhd8wD8Y4kjCA/eWRhlz/CeBbCd8VTA3Vm+48ruixxuzDgfmgpiI4TuJ9 xlIg1LX1fBIhL1OsYqF6+ANoDKgpLWRizqO9kgL960KVecyS5F844PMJsf1jFCi3D+aQ rB+M/cR+rO4piMys+vw7QMUBJYxzV8qzCa08Q= MIME-Version: 1.0 Received: by 10.231.191.135 with SMTP id dm7mr635974ibb.76.1273216046905; Fri, 07 May 2010 00:07:26 -0700 (PDT) Received: by 10.231.186.195 with HTTP; Fri, 7 May 2010 00:07:26 -0700 (PDT) In-Reply-To: <1273213486.31401.15.camel@missotis> References: <1273213486.31401.15.camel@missotis> Date: Fri, 7 May 2010 03:07:26 -0400 Message-ID: From: Hiroto Shibuya To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=0016367b6f6a32b8010485fbb64d Cc: netmod@ietf.org Subject: Re: [netmod] augmenting imported module 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, 07 May 2010 07:07:43 -0000 --0016367b6f6a32b8010485fbb64d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lada, Nice to hear from you. Thank you very much for your work on pyang. On Fri, May 7, 2010 at 2:24 AM, Ladislav Lhotka wrote: > Hiroto Shibuya p=C3=AD=C5=A1e v =C4=8Ct 06. 05. 2010 v 17:04 -0400: > > What you can do is to set up a data model formed by *both* the external > module and the augmenting module. The resulting data tree is then the > union of the trees from both modules and the augmenting applies as well. > So, is this "data model" something outside the scope of YANG? In case module1 import and augment module2, neither module1 nor module2 is the unio= n of two models (when all module2 does is to augment)? If that is the case, what was meant by 4.2.8? 4.2.8. Extending Data Models (augment) YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) or an external module. > The DSDL plugin (the code from the Google Code repository) does what you > want. For example, you can use the yang2dsdl script with multiple > modules to get RELAX NG, Schematron and DSRL schemas for a reply to > as follows: > > $ yang2dsdl -t get-reply foo.yang bar.yang > > An instance document can also be directly validated using this script. > The details are in the manpage. > > I looked at dsdl plugin and after receiving multiple modules from pyang, it is doing its own walk through of the tree and merging of augmented nodes. Am I being too lazy to assume that should be handled by the pyang to be in line with 4.2.8? Hiroto --0016367b6f6a32b8010485fbb64d Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi Lada,

Nice to hear from you.=A0 Thank you very much for your wor= k on pyang.

On Fri, May 7, 2010 at 2:24 = AM, Ladislav Lhotka <lhotka@cesnet.cz> wrote:
Hiroto Shibuya p= =ED=B9e v =C8t 06. 05. 2010 v 17:04 -0400:

What you can do is to set up a data model formed by *both* the extern= al
module and the augmenting module. The resulting data tree is then the
union of the trees from both modules and the augmenting applies as well.

So,=A0 is this "data model" something outs= ide the scope of YANG?=A0 In case module1 import and augment module2, neith= er module1 nor module2 is the union of two models (when all module2 does is= to augment)?=A0=A0 If that is the case, what was meant by 4.2.8?=A0

4.2.8.=A0 Extending Data Models (augment)

=A0=A0 YANG allows a m= odule to insert additional nodes into data models,
=A0=A0 including both= the current module (and its submodules) or an external
=A0=A0 module. <= br>
=A0
The DSDL plugin (the code from the Google Code repository) does what you want. For example, you can use the yang2dsdl script with multiple
modules to get RELAX NG, Schematron and DSRL schemas for a reply to
<get> as follows:

$ yang2dsdl -t get-reply foo.yang bar.yang

An instance document can also be directly validated using this script.
The details are in the manpage.


I looked at dsdl plugin and after receiving multiple = modules from pyang, it is doing its own walk through of the tree and mergin= g of augmented nodes.=A0=A0=A0 Am I being too lazy to assume that should be= handled by the pyang to be in line with 4.2.8?=A0

Hiroto

--0016367b6f6a32b8010485fbb64d-- From lhotka@cesnet.cz Fri May 7 00:47:03 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 19A7D3A6AE0 for ; Fri, 7 May 2010 00:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=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 0pQWHKCQJLd4 for ; Fri, 7 May 2010 00:47:02 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D58433A6AD3 for ; Fri, 7 May 2010 00:46:58 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3FA872CDE057; Fri, 7 May 2010 09:46:45 +0200 (CEST) From: Ladislav Lhotka To: Hiroto Shibuya In-Reply-To: References: <1273213486.31401.15.camel@missotis> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 07 May 2010 09:46:44 +0200 Message-ID: <1273218404.31401.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] augmenting imported module 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, 07 May 2010 07:47:03 -0000 Hiroto Shibuya píše v Pá 07. 05. 2010 v 03:07 -0400: > > So, is this "data model" something outside the scope of YANG? In > case module1 import and augment module2, neither module1 nor module2 > is the union of two models (when all module2 does is to augment)? If > that is the case, what was meant by 4.2.8? Yes, this is supposed to be handled outside of YANG. In NETCONF terms it means that both modules should be advertized in . I agree with you that this part is somewhat confusing. > > > 4.2.8. Extending Data Models (augment) > > YANG allows a module to insert additional nodes into data models, > including both the current module (and its submodules) or an > external > module. > > > > The DSDL plugin (the code from the Google Code repository) > does what you > want. For example, you can use the yang2dsdl script with > multiple > modules to get RELAX NG, Schematron and DSRL schemas for a > reply to > as follows: > > $ yang2dsdl -t get-reply foo.yang bar.yang > > An instance document can also be directly validated using this > script. > The details are in the manpage. > > > I looked at dsdl plugin and after receiving multiple modules from > pyang, it is doing its own walk through of the tree and merging of > augmented nodes. Am I being too lazy to assume that should be > handled by the pyang to be in line with 4.2.8? I am afraid I don't understand what you mean by the last sentence. But yes, the DSDL plugin grafts the augmenting nodes to the original tree, because RELAX NG has no such mechanism as 'augment' in YANG. The result can be demonstrated quite nicely by mapping the "ietf-netconf" module from 4741bis together with "ietf-netconf-with-defaults", which augments some RPC operations from the former module: $ yang2dsdl -t rpc ietf-netconf.yang ietf-netconf-with-defaults.yang Lada > > Hiroto > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri May 7 00: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 3E0523A6AE0 for ; Fri, 7 May 2010 00:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_50=0.001, HELO_EQ_DE=0.35, MANGLED_STOP=2.3] 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 EbSEQVIjc6Lr for ; Fri, 7 May 2010 00:50:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DAABD3A6C7A for ; Fri, 7 May 2010 00:50:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC7F8806E for ; Fri, 7 May 2010 09:49:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gkQ1Ic3V0SLg; Fri, 7 May 2010 09:49:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0194E8076; Fri, 7 May 2010 09:49:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1EB1811F4D83; Fri, 7 May 2010 09:49:56 +0200 (CEST) Date: Fri, 7 May 2010 09:49:55 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20100507074954.GB236@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 draft-ietf-netmod-yang-usage-04 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: Fri, 07 May 2010 07:50:30 -0000 Hi, here is my WG last call review of draft-ietf-netmod-yang-usage-04. The document is in a good shape; I only have a number of minor, mostly editorial and terminology related, comments. - p4: This sounds odd: "MIB usage guidelines specification [RFC 4181]" since RFC 4181 is not about the usage of MIBs; its about the usage of SMIv2 - YANG is sometimes Yang - capitalization should perhaps be made consistent - p7: What is this "YANG data model boilerplate section" that must be present? Should there be a URL, similar to the URL for the security template? - p7: Should section 3.1 explain the file "ietf-yang-types@2010-04-24.yang" convention we have adopted lately? - p8: s/interpretations of objects in other modules/interpretations of definitions in other modules/ - p8: http://www.ops.ietf.org/yang-security.html does not exist yet... - p8: s/writable module objects/writable data nodes/ - p8: s/readable module objects/readable data nodes/ - p8: Should section 3.5 have a reference to RFC 5226? - p9: I am not sure why all references statements appearing in YANG module are normative. OK, this guideline is a SHOULD, but even this seems rather strong - I do not recall we have this requirement in RFC 4181. - p10: Rewrite section 4.2 to avoid talking about "data objects" since this is not a defined term. Should we talk about schema nodes instead (and import that term in section 2.3)? Or was there a reason to not establish length restrictions for identifiers of say choices? - p11: s/Objects SHOULD NOT/Data definition SHOULD NOT/ - p11: Section 4.4 puts up requirements for XPATH expressions without first making it clear that the text starts talking about XPATH expressions. Since XPATH expressions are also used in must statements, perhaps this discussion should be factored out into a separate section "4.X XPATH Expressions". - p11: I do not understand this guideline: The 'position' and 'last' functions MAY be used with caution, within a single server implementation. What is a single server implementation? - p12: The term "header" is not well defined. In YANG, module-header statements just include yang version, namespace and prefix statements. The organization and description statements belong to meta statements and revision statements to well revision statements. OK, it seems YANG itself is not very consistent here. One way out could be to label 4.6 "Module Header, Meta, and Revision Statements". - p14: s/Top Level Database Objects/Top Level Data Nodes/ - p15: s/Top-level database objects/Top-level data nodes/ - p15: s/object semantics SHOULD NOT/data node semantics SHOULD NOT/ - p16: I am not sure "Object Definitions" is the right heading, unless we define somewhere what an object is. - p16: I also do not follow the distinction between body statements and data definition statements. In the YANG spec, data definition statements seem to be part of the body statements. I suggest to collapse the two lists into one and to have the sentence before the list changed to: The description statement MUST be present in the statements: - p17: s/If the object semantics/If semantics/ - p19: The security considerations could mention that the document establishes guidelines what needs to be covered in the security considerations of documents containing YANG modules. - p23: There should be a concrete URL replacing "[YANG tool URL TBD]". /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 Fri May 7 00:54: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 C4E943A6C96 for ; Fri, 7 May 2010 00:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-0.278, 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 gKo93sZBNtCL for ; Fri, 7 May 2010 00:54:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C0F6B3A6C86 for ; Fri, 7 May 2010 00:53:58 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0C080E2; Fri, 7 May 2010 09:53:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N7swPyqrzL-n; Fri, 7 May 2010 09:53:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2A2F80DF; Fri, 7 May 2010 09:53:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D4B711F4E14; Fri, 7 May 2010 09:53:44 +0200 (CEST) Date: Fri, 7 May 2010 09:53:43 +0200 From: Juergen Schoenwaelder To: Hiroto Shibuya Message-ID: <20100507075342.GC236@elstar.local> Mail-Followup-To: Hiroto Shibuya , "netmod@ietf.org" References: <20100506220552.GA3137@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] augmenting imported module 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: Fri, 07 May 2010 07:54:07 -0000 On Fri, May 07, 2010 at 12:37:01AM +0200, Hiroto Shibuya wrote: > So if I create module2 which is augmenting module1, module2 is > actually modifying schema within module1 and not creating new schema > within module2 which augments module1? No, module 2 is defining something that appears at a place in the instance tree defined by module 1. Look at the example in the YANG spec - I think this makes it clear how it works. > So in that situation, if I load module1 and module2 into a tool to > munch on then, it should spit out augmented module1, and not spit > out module2 (which is empty anyway)? Depends on the muching your tool wants to do. I can only explain how YANG works. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From hiroto.shibuya@gmail.com Fri May 7 01:39: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 D03F03A6AF4 for ; Fri, 7 May 2010 01:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, HTML_MESSAGE=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 r1qVp1qOxVE0 for ; Fri, 7 May 2010 01:39:04 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 041FD3A6AD3 for ; Fri, 7 May 2010 01:39:03 -0700 (PDT) Received: by iwn27 with SMTP id 27so1150563iwn.5 for ; Fri, 07 May 2010 01:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=len6wPo73ERfYlPvwY6newpczi0bcc6Sqbld39eh+DE=; b=jB8uK0E6w4pYyRsbQSWP3Qw0GEx7tXStaWRaRxLDZtjaL+KFe4x5tu+x1HMolPEmJ7 5JDiTuMttS8+veXf/JsP3v8YmJqJzBgszx6Oj36n2T/ho2sCGALKj42v/N9jPIV50rZX REdgzHtU/jv8Gjb91+anxjzOj+sKOxPBSOoP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eNp4Eds4beGlglQ/7zBFhI8XG4L/u4XbxTtMXKMtyHdmli5gORc9DvyMZp22+pvEys 0WvMQOGLDcWAKs1PIdVMAoNPH/Rhtlv2vNrnhGMPiP3Q9nYPfaE1vgxpdRwddaEeoqLO vgqc7H9ErCaLxchMkZyoO8glyO16K2XDLmofQ= MIME-Version: 1.0 Received: by 10.231.183.133 with SMTP id cg5mr1118758ibb.12.1273221528772; Fri, 07 May 2010 01:38:48 -0700 (PDT) Received: by 10.231.186.195 with HTTP; Fri, 7 May 2010 01:38:48 -0700 (PDT) In-Reply-To: <1273218404.31401.43.camel@missotis> References: <1273213486.31401.15.camel@missotis> <1273218404.31401.43.camel@missotis> Date: Fri, 7 May 2010 04:38:48 -0400 Message-ID: From: Hiroto Shibuya To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001636285212f166d00485fcfc23 Cc: netmod@ietf.org Subject: Re: [netmod] augmenting imported module 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, 07 May 2010 08:39:04 -0000 --001636285212f166d00485fcfc23 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 7, 2010 at 3:46 AM, Ladislav Lhotka wrote: > > > $ yang2dsdl -t rpc ietf-netconf.yang ietf-netconf-with-defaults.yang > Interesting. I tried pyang ietf-netconf.yang ietf-netconf-with-defaults.yang -f tree and output result did contained properly augmented tree as I expected. Hiroto --001636285212f166d00485fcfc23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 7, 2010 at 3:46 AM, Ladislav= Lhotka <lhotka@ce= snet.cz> wrote:=A0
=A0
$ yang2dsdl -t rpc ietf-netconf.yang ietf-netconf-with-defaults.yang

=A0Interesting. =A0 I tried

pyang=A0ietf-netconf.yang ietf-netconf-with-defaults.yang -f tree

=A0and output result did contained properly augmented t= ree as I expected. =A0

Hiroto
--001636285212f166d00485fcfc23-- From hiroto.shibuya@gmail.com Fri May 7 01:47: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 70AD33A6894 for ; Fri, 7 May 2010 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, HTML_MESSAGE=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 LrCWmm8JvEbp for ; Fri, 7 May 2010 01:47:23 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 53F203A67CF for ; Fri, 7 May 2010 01:47:23 -0700 (PDT) Received: by iwn27 with SMTP id 27so1157100iwn.5 for ; Fri, 07 May 2010 01:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=AoZwD7Yg05p5j6FfjHWkPBe4DZ0JoukPMUGah5ahyfg=; b=imuCa28Vjev2yUQkirKOx5TyzetQojWcWiaWilcwweKSMLQ/9+hHpJvhNzu8Lj1cwg 0FRGYVxayV7302fLNLbQJtitkZ1zP/4sC5mx6+/IjaUFyrmI9/0IwAA7FbJ8JDfV9Cpy PtunKboseChgX9ZJxtyCGnaTJ1zc1AMln7o1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BTivVgl2ETDJsYOCm/BjA85E7yZWa9EsyxNaQCgJWJnL42mX3yj/FK7ZOyiUSJ7kHm h3QVtWkTUX5IsLTglvmJ1UoaEiEqIuot7BX8fDye8Cjg0nRw1dPhXnj21lbH40CTG8cy IU/MBw2IC9A2I7PG0rJtd9ag7Bq2wC3kDNFr4= MIME-Version: 1.0 Received: by 10.231.191.145 with SMTP id dm17mr1338702ibb.17.1273221994026; Fri, 07 May 2010 01:46:34 -0700 (PDT) Received: by 10.231.186.195 with HTTP; Fri, 7 May 2010 01:46:33 -0700 (PDT) In-Reply-To: <20100507075342.GC236@elstar.local> References: <20100506220552.GA3137@elstar.local> <20100507075342.GC236@elstar.local> Date: Fri, 7 May 2010 04:46:33 -0400 Message-ID: From: Hiroto Shibuya To: Juergen Schoenwaelder , Hiroto Shibuya , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=0016367d6e32ac96820485fd18c7 Subject: Re: [netmod] augmenting imported module 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, 07 May 2010 08:47:24 -0000 --0016367d6e32ac96820485fd18c7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 7, 2010 at 3:53 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, May 07, 2010 at 12:37:01AM +0200, Hiroto Shibuya wrote: > > > So if I create module2 which is augmenting module1, module2 is > > actually modifying schema within module1 and not creating new schema > > within module2 which augments module1? > > No, module 2 is defining something that appears at a place in the > instance tree defined by module 1. Look at the example in the YANG > spec - I think this makes it clear how it works. > > Ok, thanks. Now it is making more sense to me. It is still mighty confusing to to state that module2 modifies module1 by importing it. It is confusing because you can actually "import" groups from module1 and use it in module2, so importing is kind of bidirectional and could produce modified trees in both modules. Hiroto --0016367d6e32ac96820485fd18c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 7, 2010 at 3:53 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:=
On Fri, May 07, 2010 at 1= 2:37:01AM +0200, Hiroto Shibuya wrote:

> So if I create module2 which is augmenting module1, module2 is
> actually modifying schema within module1 and not creating new schema > within module2 which augments module1?

No, module 2 is defining something that appears at a place in the
instance tree defined by module 1. Look at the example in the YANG
spec - I think this makes it clear how it works.


Ok, thanks. = =A0Now it is making more sense to me. =A0It is still mighty confusing to to= state that module2 modifies module1 by importing it. =A0 It is confusing b= ecause you can actually "import" groups from module1 and use it i= n module2, so importing is kind of bidirectional and could produce modified= trees in both modules. =A0=A0

Hiroto
--0016367d6e32ac96820485fd18c7-- From j.schoenwaelder@jacobs-university.de Fri May 7 02:01: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 27A483A67F4 for ; Fri, 7 May 2010 02:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 FFWqT7wTIDp8 for ; Fri, 7 May 2010 02:01:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 69BED3A63EC for ; Fri, 7 May 2010 02:01:36 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A061FC00B1; Fri, 7 May 2010 11:01:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Dgwad-CmDuCg; Fri, 7 May 2010 11:01:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D4B3C008F; Fri, 7 May 2010 11:01:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CFB6B11F5489; Fri, 7 May 2010 11:01:20 +0200 (CEST) Date: Fri, 7 May 2010 11:01:20 +0200 From: Juergen Schoenwaelder To: Hiroto Shibuya Message-ID: <20100507090120.GC706@elstar.local> Mail-Followup-To: Hiroto Shibuya , "netmod@ietf.org" References: <20100506220552.GA3137@elstar.local> <20100507075342.GC236@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] augmenting imported module 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: Fri, 07 May 2010 09:01:41 -0000 On Fri, May 07, 2010 at 10:46:33AM +0200, Hiroto Shibuya wrote: > Ok, thanks. Now it is making more sense to me. It is still mighty > confusing to to state that module2 modifies module1 by importing it. > It is confusing because you can actually "import" groups from > module1 and use it in module2, so importing is kind of bidirectional > and could produce modified trees in both modules. Its not bidirectional. You don't modify a module by importing from it. Your problem is that you assume that a module exclusively owns the data tree it creates, but that assumption is not correct in YANG because we allow augmentations. This might be surprising at first sight if you are only familiar with schema languages that can't do this. But it is an incredible feature in order to let vendors extend standard definition and keeping related data organized closely together. /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 Fri May 7 02:04: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 19CA63A685E for ; Fri, 7 May 2010 02:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_40=-0.185, 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 F6USxZp7w1th for ; Fri, 7 May 2010 02:03:59 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4B8213A67F4 for ; Fri, 7 May 2010 02:03:59 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id C2F1D76C062; Fri, 7 May 2010 11:03:45 +0200 (CEST) Date: Fri, 07 May 2010 11:03:44 +0200 (CEST) Message-Id: <20100507.110344.237304131.mbj@tail-f.com> To: hiroto.shibuya@gmail.com From: Martin Bjorklund In-Reply-To: References: <20100507075342.GC236@elstar.local> X-Mailer: Mew version 7.0.50 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] augmenting imported module 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, 07 May 2010 09:04:00 -0000 Hiroto Shibuya wrote: > On Fri, May 7, 2010 at 3:53 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Fri, May 07, 2010 at 12:37:01AM +0200, Hiroto Shibuya wrote: > > > > > So if I create module2 which is augmenting module1, module2 is > > > actually modifying schema within module1 and not creating new schema > > > within module2 which augments module1? > > > > No, module 2 is defining something that appears at a place in the > > instance tree defined by module 1. Look at the example in the YANG > > spec - I think this makes it clear how it works. > > > > > Ok, thanks. Now it is making more sense to me. It is still mighty > confusing to to state that module2 modifies module1 by importing it. No, 'import' does not modify the imported module. In YANG, all containers and lists can have nodes from other namespaces. 'augment' defines such nodes. /martin From dromasca@avaya.com Fri May 7 03:34: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 7F0E13A6A5D for ; Fri, 7 May 2010 03:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_50=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 WpwONp2yhMMG for ; Fri, 7 May 2010 03:34:53 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 382383A6A1D for ; Fri, 7 May 2010 03:34:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,347,1270440000"; d="scan'208";a="187610302" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 May 2010 06:34:36 -0400 X-IronPort-AV: E=Sophos;i="4.52,347,1270440000"; d="scan'208";a="459697995" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 May 2010 06:34:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 May 2010 12:34:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of draft-ietf-netmod-yang Thread-Index: Acrt0NywMiDOuj6oRByDiTvgE9ZI7Q== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] Status of draft-ietf-netmod-yang 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, 07 May 2010 10:34:54 -0000 As expected, the I-D was not approved in the IESG telechat yesterday. It is in status 'Revised-ID needed', which means that the editors and the chairs need to continue to work with the ADs and clarify the issues raised in their DISCUSSes, confirm the necessary edits, and then issue a revised I-D that will include the edits that will allow the AD's to clear the DISCUSSes.=20 The issue that was mostly discussed in the call was the perceived extra-flexibility of the deviation mechanism. To the concerns expressed by Robert, Tim and other AD's added their own which made Robert move the issue from a non-blocking COMMENT to the blocking list of issues in the DISCUSS. =20 (Moved this to a discuss based on telechat conversation Tim plans to enter support when the tracker works for him) The deviation mechanism seems too flexible to me. As defined, someone could claim to implement standard X, but use deviation statements to completely replace the contents of X with something proprietary. Discussions with Dan indicate that this was explicitly considered by the group and deemed acceptable. Is there any text that could be added to more strongly discourage this kind of abuse of the mechanism? In particular, what would help a client implementor defend against a statement like=20 "No, the spec says I can deviate this way, and you're at non-interoperability-fault for not conforming to my deviations" when the deviations are more extreme than the simple policy and limit deviations shown as examples? Please look carefully at this issue which (all other DISCUSS level issues) needs to be clarified before the document is approved.=20 We are very close. Thanks to all for the tremendous work done until now. Dan From lhotka@cesnet.cz Fri May 7 03:44: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 1560E3A69A6 for ; Fri, 7 May 2010 03:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_50=0.001, 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 WFmYtxuwF9lm for ; Fri, 7 May 2010 03:44:22 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 134C83A6893 for ; Fri, 7 May 2010 03:44:22 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id DBD2C2CDE058 for ; Fri, 7 May 2010 12:44:08 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 07 May 2010 12:44:07 +0200 Message-ID: <1273229047.31401.67.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] mandatory augmenting nodes 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, 07 May 2010 10:44:23 -0000 Hi, YANG draft says in section 7.15: If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes (see Section 3.1). Why is this CLR necessary? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri May 7 03:44: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 CEBC63A6893 for ; Fri, 7 May 2010 03:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.212 X-Spam-Level: X-Spam-Status: No, score=0.212 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_50=0.001, 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 Bsy-KA+8NwVX for ; Fri, 7 May 2010 03:44:23 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EC1DC3A6971 for ; Fri, 7 May 2010 03:44:22 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 750B676C062; Fri, 7 May 2010 12:44:09 +0200 (CEST) Date: Fri, 07 May 2010 12:44:08 +0200 (CEST) Message-Id: <20100507.124408.98291911.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 7.0.50 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] Status of draft-ietf-netmod-yang 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, 07 May 2010 10:44:23 -0000 "Romascanu, Dan (Dan)" wrote: > As expected, the I-D was not approved in the IESG telechat yesterday. It > is in status 'Revised-ID needed', which means that the editors and the > chairs need to continue to work with the ADs and clarify the issues > raised in their DISCUSSes, confirm the necessary edits, and then issue a > revised I-D that will include the edits that will allow the AD's to > clear the DISCUSSes. > > The issue that was mostly discussed in the call was the perceived > extra-flexibility of the deviation mechanism. To the concerns expressed > by Robert, Tim and other AD's added their own which made Robert move the > issue from a non-blocking COMMENT to the blocking list of issues in the > DISCUSS. > > (Moved this to a discuss based on telechat conversation > Tim plans to enter support when the tracker works for him) > The deviation mechanism seems too flexible to me. As > defined, someone could claim to implement standard X, but > use deviation statements to completely replace the contents > of X with something proprietary. Discussions with Dan > indicate that this was explicitly considered by the group > and deemed acceptable. Is there any text that could be > added to more strongly discourage this kind of abuse of the > mechanism? In particular, what would help a client > implementor defend against a statement like > "No, the spec says I can deviate this way, and you're at > non-interoperability-fault for not conforming to my > deviations" when the deviations are more extreme than the > simple policy and limit deviations shown as examples? > > Please look carefully at this issue which (all other DISCUSS level > issues) needs to be clarified before the document is approved. Sean Turner suggested that we change the SHOULD to a MUST in the text below: Device deviations are strongly discouraged and SHOULD only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. Was this not good enough? /martin From j.schoenwaelder@jacobs-university.de Fri May 7 03:55: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 D28383A6AF2 for ; Fri, 7 May 2010 03:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 8IKnB+6bB+aH for ; Fri, 7 May 2010 03:55:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BE6DA3A6AE2 for ; Fri, 7 May 2010 03:55:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17F4DC00BB; Fri, 7 May 2010 12:54:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sssZcbGb+61c; Fri, 7 May 2010 12:54:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8126C00D3; Fri, 7 May 2010 12:54:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5EBF411F59E1; Fri, 7 May 2010 12:54:50 +0200 (CEST) Date: Fri, 7 May 2010 12:54:50 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100507105450.GB1463@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , NETMOD Working Group References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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: Fri, 07 May 2010 10:55:05 -0000 On Fri, May 07, 2010 at 12:34:24PM +0200, Romascanu, Dan (Dan) wrote: > The issue that was mostly discussed in the call was the perceived > extra-flexibility of the deviation mechanism. To the concerns expressed > by Robert, Tim and other AD's added their own which made Robert move the > issue from a non-blocking COMMENT to the blocking list of issues in the > DISCUSS. > > (Moved this to a discuss based on telechat conversation > Tim plans to enter support when the tracker works for him) > The deviation mechanism seems too flexible to me. As > defined, someone could claim to implement standard X, but > use deviation statements to completely replace the contents > of X with something proprietary. Discussions with Dan > indicate that this was explicitly considered by the group > and deemed acceptable. Is there any text that could be > added to more strongly discourage this kind of abuse of the > mechanism? In particular, what would help a client > implementor defend against a statement like > "No, the spec says I can deviate this way, and you're at > non-interoperability-fault for not conforming to my > deviations" when the deviations are more extreme than the > simple policy and limit deviations shown as examples? Does the IESG feel this is worse than AGENT-CAPABILITIES in STD 58? If so, why? Or is it that it is not deemed acceptable anymore what was acceptable back in 1999? The phrase "completely replace the contents of X with something proprietary" is also not very accurate. A vendor following that approach would _formally_declare_ that he does not implement any of the definitions of standard X. It does not matter whether the vendor has proprietary replacement definitions since deviations only document deviations, not replacements. Please note that with SMIv2 AGENT-CAPABILITIES, I can list all objects of a MIB module as "not-implemented". So if there is going to be abuse of such a mechanism, we should have meanwhile some experience with it. (Note that AGENT-CAPABILITIES were first introduced in 1993 if I recall correctly - thats 17 years ago.) /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 Fri May 7 03:57: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 180733A68C2 for ; Fri, 7 May 2010 03:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.086 X-Spam-Level: X-Spam-Status: No, score=0.086 tagged_above=-999 required=5 tests=[AWL=-0.265, 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 WiTdWvGkAZ95 for ; Fri, 7 May 2010 03:57:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0DC2B3A676A for ; Fri, 7 May 2010 03:57:40 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A14EC00E0; Fri, 7 May 2010 12:57:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bsOYf1sL09WI; Fri, 7 May 2010 12:57:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A5FDC00E2; Fri, 7 May 2010 12:57:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C999E11F5A38; Fri, 7 May 2010 12:57:25 +0200 (CEST) Date: Fri, 7 May 2010 12:57:25 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100507105725.GC1463@elstar.local> Mail-Followup-To: Martin Bjorklund , "dromasca@avaya.com" , "netmod@ietf.org" References: <20100507.124408.98291911.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100507.124408.98291911.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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: Fri, 07 May 2010 10:57:41 -0000 On Fri, May 07, 2010 at 12:44:08PM +0200, Martin Bjorklund wrote: > Sean Turner suggested that we change the SHOULD to a MUST in the text > below: > > Device deviations are strongly discouraged and SHOULD only be used > as a last resort. Telling the application how a device fails to > follow a standard is no substitute for implementing the standard > correctly. > > Was this not good enough? How do I implement this "MUST only as a last resort" - isn't the complete phrase then equivalent to a SHOULD? But if it makes the IESG happy, I am in favour of this change. ;-) /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 Fri May 7 04:00: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 35E383A6AF5 for ; Fri, 7 May 2010 04:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Fib7TBnm8Rmo for ; Fri, 7 May 2010 04:00:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7D85A3A6A12 for ; Fri, 7 May 2010 04:00:37 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id B5BF5616001; Fri, 7 May 2010 13:00:24 +0200 (CEST) Date: Fri, 07 May 2010 13:00:23 +0200 (CEST) Message-Id: <20100507.130023.233516908.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100507105725.GC1463@elstar.local> References: <20100507.124408.98291911.mbj@tail-f.com> <20100507105725.GC1463@elstar.local> X-Mailer: Mew version 7.0.50 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] Status of draft-ietf-netmod-yang 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, 07 May 2010 11:00:46 -0000 Juergen Schoenwaelder wrote: > On Fri, May 07, 2010 at 12:44:08PM +0200, Martin Bjorklund wrote: > > > Sean Turner suggested that we change the SHOULD to a MUST in the text > > below: > > > > Device deviations are strongly discouraged and SHOULD only be used > > as a last resort. Telling the application how a device fails to > > follow a standard is no substitute for implementing the standard > > correctly. > > > > Was this not good enough? > > How do I implement this "MUST only as a last resort" - isn't the > complete phrase then equivalent to a SHOULD? Right. Not even "SHOULD" is really possible to implement. But maybe MUST makes the statement seem more serious. /martin From lhotka@cesnet.cz Fri May 7 04:07: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 7D5A33A676A for ; Fri, 7 May 2010 04:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_50=0.001, 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 5mGnTl3vJp8I for ; Fri, 7 May 2010 04:07:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 9634E3A6AB6 for ; Fri, 7 May 2010 04:07:56 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 96B062CDE058; Fri, 7 May 2010 13:07:43 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100507.130023.233516908.mbj@tail-f.com> References: <20100507.124408.98291911.mbj@tail-f.com> <20100507105725.GC1463@elstar.local> <20100507.130023.233516908.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 07 May 2010 13:07:42 +0200 Message-ID: <1273230462.31401.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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, 07 May 2010 11:07:59 -0000 Martin Bjorklund píše v Pá 07. 05. 2010 v 13:00 +0200: > Juergen Schoenwaelder wrote: > > On Fri, May 07, 2010 at 12:44:08PM +0200, Martin Bjorklund wrote: > > > > > Sean Turner suggested that we change the SHOULD to a MUST in the text > > > below: > > > > > > Device deviations are strongly discouraged and SHOULD only be used > > > as a last resort. Telling the application how a device fails to > > > follow a standard is no substitute for implementing the standard > > > correctly. > > > > > > Was this not good enough? > > > > How do I implement this "MUST only as a last resort" - isn't the > > complete phrase then equivalent to a SHOULD? > > Right. Not even "SHOULD" is really possible to implement. > > But maybe MUST makes the statement seem more serious. After looking at RFC 2119, I'd say the best formulation might be Device deviations are strongly discouraged and SHALL only be used as a last resort. Lada > > > /martin > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Fri May 7 05:01: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 23D973A6877 for ; Fri, 7 May 2010 05:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, 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 BBcUD7q4e6Gw for ; Fri, 7 May 2010 05:01:37 -0700 (PDT) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 52C633A6851 for ; Fri, 7 May 2010 05:01:37 -0700 (PDT) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 6733F17FEF9; Fri, 7 May 2010 08:01:24 -0400 (EDT) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 338C717FBD8; Fri, 7 May 2010 08:01:24 -0400 (EDT) Message-ID: <4BE40116.3030405@iwl.com> Date: Fri, 07 May 2010 05:01:26 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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: Fri, 07 May 2010 12:01:38 -0000 Romascanu, Dan (Dan) wrote: > As expected, the I-D was not approved in the IESG telechat yesterday. It > is in status 'Revised-ID needed', which means that the editors and the > chairs need to continue to work with the ADs and clarify the issues > raised in their DISCUSSes, confirm the necessary edits, and then issue a > revised I-D that will include the edits that will allow the AD's to > clear the DISCUSSes. > > The issue that was mostly discussed in the call was the perceived > extra-flexibility of the deviation mechanism. To the concerns expressed > by Robert, Tim and other AD's added their own which made Robert move the > issue from a non-blocking COMMENT to the blocking list of issues in the > DISCUSS. > > (Moved this to a discuss based on telechat conversation > Tim plans to enter support when the tracker works for him) > The deviation mechanism seems too flexible to me. As > defined, someone could claim to implement standard X, but > use deviation statements to completely replace the contents > of X with something proprietary. Discussions with Dan > indicate that this was explicitly considered by the group > and deemed acceptable. Is there any text that could be > added to more strongly discourage this kind of abuse of the > mechanism? In particular, what would help a client > implementor defend against a statement like > "No, the spec says I can deviate this way, and you're at > non-interoperability-fault for not conforming to my > deviations" when the deviations are more extreme than the > simple policy and limit deviations shown as examples? > > I've said this about the deviation-stmt all along. There seems to be a delusional fantasy that some level of interoperability is maintained, even if deviations are used by the server. There is none. You cannot arbitrarily change data node definitions and expect all clients to adjust correctly. On the contrary, simply using deviations at all is admitting that your implementation is non-compliant and non-interoperable. That's why I have concerns the will not contain the deviations -- the server will just lie about implementing the full YANG module. > Please look carefully at this issue which (all other DISCUSS level > issues) needs to be clarified before the document is approved. > > We are very close. Thanks to all for the tremendous work done until now. > > > Dan > Andy From mbj@tail-f.com Fri May 7 05:10: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 3C9DA3A6AB2 for ; Fri, 7 May 2010 05:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_50=0.001, 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 kZguKFu7yc+M for ; Fri, 7 May 2010 05:10:42 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 465163A6A64 for ; Fri, 7 May 2010 05:10:42 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id D0CD9616001; Fri, 7 May 2010 14:10:28 +0200 (CEST) Date: Fri, 07 May 2010 14:10:27 +0200 (CEST) Message-Id: <20100507.141027.163340855.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BE40116.3030405@iwl.com> References: <4BE40116.3030405@iwl.com> X-Mailer: Mew version 7.0.50 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] Status of draft-ietf-netmod-yang 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, 07 May 2010 12:10:50 -0000 Andy Bierman wrote: > I've said this about the deviation-stmt all along. > There seems to be a delusional fantasy that some level > of interoperability is maintained, even if deviations > are used by the server. The spec clearly states: Device deviations are strongly discouraged and SHOULD only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. > There is none. You cannot > arbitrarily change data node definitions and expect > all clients to adjust correctly. Correct. > On the contrary, simply using deviations at all is admitting that > your implementation is non-compliant and non-interoperable. > That's why I have concerns the > will not contain the deviations -- the server will > just lie about implementing the full YANG module. Suppose server A implements parts of module foo, but not all mandatory parts. Such a server is non-compliant. Now, suppose we didn't have deviations. Server A advertises module foo. Server A is still non-compliant, and it is impossible for clients to even know this. Next, suppose we have deviations. Server A advertises module foo, but no deviations. Server A is still non-compliant and makes it impossible for clients to adapt. Or, the server can advertise module foo plus deviations. Such a server is still non-compliant, BUT it makes it possible for clients to adapt. /martin From randy_presuhn@mindspring.com Fri May 7 07:03:44 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 213C63A6B35 for ; Fri, 7 May 2010 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Tcm83BhLcJgQ for ; Fri, 7 May 2010 07:03:43 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 16BDB3A6B33 for ; Fri, 7 May 2010 07:03:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Sm3K+xBeTqmhSUnZsDZXFTcbPpxr9fE95Xsqmt2GiN5xzq0fcJJgXeKNUbAymhYv; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OAO9J-0007aE-JK for netmod@ietf.org; Fri, 07 May 2010 10:03:29 -0400 Received: from 71.9.108.66 by webmail.earthlink.net with HTTP; Fri, 7 May 2010 10:03:29 -0400 Message-ID: <3450082.1273241009613.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Fri, 7 May 2010 07:03:29 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780350f7cbac462799ea8356e2a188ab4dfad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Subject: Re: [netmod] augmenting imported module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:03:44 -0000 Hi - >From: Ladislav Lhotka >Sent: May 7, 2010 12:46 AM >To: Hiroto Shibuya >Cc: netmod@ietf.org >Subject: Re: [netmod] augmenting imported module ... >> 4.2.8. Extending Data Models (augment) >> >> YANG allows a module to insert additional nodes into data models, >> including both the current module (and its submodules) or an >> external >> module. ... >From the discussion that ensued, it seems to me that the word "insert" here is at least partially responsible for the confusion. The phrase "into data models" doesn't help, since that would be read as "into *other* data models" rather than "into *its* *own* data model." It's made even worse by the ambiguity of of the phrase "including both ..." which may be read as the nerdish "#INCLUDE-ing both", but which also be read in the normal English sense of saying that additional nodes are inserted into the current module and into the exernal module. I think this sentence should be replaced with something less misleading. Randy From randy_presuhn@mindspring.com Fri May 7 07:24:10 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 D85FC3A69DB for ; Fri, 7 May 2010 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] 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 FscKb00p+ulG for ; Fri, 7 May 2010 07:24:10 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 842653A6B2A for ; Fri, 7 May 2010 07:24:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=b57ERFe/GATZtVvs/XSAo0UGzrS77oen+X9dT8IDYZMGSvGU9Afbxj65DyjFx4oH; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OAOT5-0007cA-7g for netmod@ietf.org; Fri, 07 May 2010 10:23:55 -0400 Received: from 71.9.108.66 by webmail.earthlink.net with HTTP; Fri, 7 May 2010 10:23:55 -0400 Message-ID: <9371587.1273242235187.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Fri, 7 May 2010 07:23:55 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780351f082410fe2c20fba2009a69b91be991350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Subject: Re: [netmod] Status of draft-ietf-netmod-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:24:11 -0000 Hi - >From: Juergen Schoenwaelder >Sent: May 7, 2010 3:54 AM >To: "Romascanu, Dan (Dan)" >Cc: NETMOD Working Group >Subject: Re: [netmod] Status of draft-ietf-netmod-yang ... >Please note that with SMIv2 AGENT-CAPABILITIES, I can list all objects >of a MIB module as "not-implemented". So if there is going to be abuse >of such a mechanism, we should have meanwhile some experience with >it. (Note that AGENT-CAPABILITIES were first introduced in 1993 if I >recall correctly - thats 17 years ago.) ... RFC 2580 says Practical experience has demonstrated a need for concisely describing the capabilities of an agent with respect to one or more MIB modules. The AGENT-CAPABILITIES macro allows an agent implementor to describe the precise level of support which an agent claims in regards to a MIB group, and to bind that description to the value of an instance of sysORID [3]. In particular, some objects may have restricted or augmented syntax or access-levels. The question of conformance is answered by looking at the relevant MODULE-COMPLIANCE statement(s) and verifying whether the implementation actually meets those requirements. At most, AGENT-CAPABILITIES will tell you why the implementation in question can't be legitimately claimed to conform. I think the issue is making it clear whether (and how) an implementation with deviations could still legitimately claim to *conformantly* implement a particular model. Randy From andyb@iwl.com Fri May 7 07:59:36 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 1A93A3A6B55 for ; Fri, 7 May 2010 07:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_50=0.001, 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 qphEFco-b+zC for ; Fri, 7 May 2010 07:59:35 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id 5D56E3A6B48 for ; Fri, 7 May 2010 07:59:35 -0700 (PDT) Received: from relay22.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C7D92C086B1; Fri, 7 May 2010 10:59:22 -0400 (EDT) Received: by relay22.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8896CC0823B; Fri, 7 May 2010 10:59:22 -0400 (EDT) Message-ID: <4BE42ACD.80207@iwl.com> Date: Fri, 07 May 2010 07:59:25 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BE40116.3030405@iwl.com> <20100507.141027.163340855.mbj@tail-f.com> In-Reply-To: <20100507.141027.163340855.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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: Fri, 07 May 2010 14:59:36 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> I've said this about the deviation-stmt all along. >> There seems to be a delusional fantasy that some level >> of interoperability is maintained, even if deviations >> are used by the server. >> > > The spec clearly states: > > Device deviations are strongly discouraged and SHOULD only be used > as a last resort. Telling the application how a device fails to > follow a standard is no substitute for implementing the standard > correctly. > > >> There is none. You cannot >> arbitrarily change data node definitions and expect >> all clients to adjust correctly. >> > > Correct. > > >> On the contrary, simply using deviations at all is admitting that >> your implementation is non-compliant and non-interoperable. >> That's why I have concerns the >> will not contain the deviations -- the server will >> just lie about implementing the full YANG module. >> > > Suppose server A implements parts of module foo, but not all mandatory > parts. Such a server is non-compliant. > > Now, suppose we didn't have deviations. Server A advertises module > foo. Server A is still non-compliant, and it is impossible for > clients to even know this. > > Next, suppose we have deviations. Server A advertises module foo, but > no deviations. Server A is still non-compliant and makes it > impossible for clients to adapt. > > Or, the server can advertise module foo plus deviations. Such a > server is still non-compliant, BUT it makes it possible for clients to > adapt. > > Even for the cleanest mechanism in deviations (not-supported), it depends on the data model what impact omitting some of the nodes will have. For serious deviations, like changing mandatory to optional, or changing an inet-address to a boolean, there is no predictability. It is a case-by-case problem. 1) Does the same deviation on 2 different servers insure that the 2 servers behave in the exact same way? 2) Will 2 different clients always handle a deviation the same way? It is obvious how to convert an inet-address to a boolean? 3) What are the reasonable expectations for a client application's ability to adapt to arbitrary deviations? > /martin > > Andy From j.schoenwaelder@jacobs-university.de Fri May 7 10:13: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 397693A67C2 for ; Fri, 7 May 2010 10:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=-0.261, 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 mr6sLoRE7Orp for ; Fri, 7 May 2010 10:13:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 07E9A3A6826 for ; Fri, 7 May 2010 10:13:14 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44A9BC0058; Fri, 7 May 2010 19:13:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N8xtRiTFCkaH; Fri, 7 May 2010 19:13:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08972C0006; Fri, 7 May 2010 19:12:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5998611F693D; Fri, 7 May 2010 19:12:59 +0200 (CEST) Date: Fri, 7 May 2010 19:12:59 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100507171259.GB2196@elstar.local> Mail-Followup-To: Andy Bierman , "Romascanu, Dan (Dan)" , NETMOD Working Group References: <4BE40116.3030405@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE40116.3030405@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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: Fri, 07 May 2010 17:13:19 -0000 On Fri, May 07, 2010 at 02:01:26PM +0200, Andy Bierman wrote: > > I've said this about the deviation-stmt all along. > There seems to be a delusional fantasy that some level > of interoperability is maintained, even if deviations > are used by the server. There is none. You cannot > arbitrarily change data node definitions and expect > all clients to adjust correctly. With deviations, a client can decide whether the deviation impacts the client or not. Deviation in data nodes that are not used by this particular client can be very well tolerated. > On the contrary, simply using deviations at all is admitting that > your implementation is non-compliant and non-interoperable. Yes, non-compliant. The client can decide whether the deviations can cause problems or not. > That's why I have concerns the > will not contain the deviations -- the server will > just lie about implementing the full YANG module. So we need an RFC stating "you MUST not lie" and then by making this a normative reference, we make this a better world. ;-) /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 May 7 10:48: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 1AC1B3A68D7 for ; Fri, 7 May 2010 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_50=0.001, 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 B4Z60olB5289 for ; Fri, 7 May 2010 10:48:07 -0700 (PDT) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 51EA73A65A5 for ; Fri, 7 May 2010 10:48:07 -0700 (PDT) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BEE042748A97; Fri, 7 May 2010 13:47:54 -0400 (EDT) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 90F462748261; Fri, 7 May 2010 13:47:54 -0400 (EDT) Message-ID: <4BE4524D.4000608@iwl.com> Date: Fri, 07 May 2010 10:47:57 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , NETMOD Working Group References: <4BE40116.3030405@iwl.com> <20100507171259.GB2196@elstar.local> In-Reply-To: <20100507171259.GB2196@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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: Fri, 07 May 2010 17:48:08 -0000 Juergen Schoenwaelder wrote: > On Fri, May 07, 2010 at 02:01:26PM +0200, Andy Bierman wrote: > >> I've said this about the deviation-stmt all along. >> There seems to be a delusional fantasy that some level >> of interoperability is maintained, even if deviations >> are used by the server. There is none. You cannot >> arbitrarily change data node definitions and expect >> all clients to adjust correctly. >> > > With deviations, a client can decide whether the deviation impacts the > client or not. Deviation in data nodes that are not used by this > particular client can be very well tolerated. > Of course -- changes to anything the client does not use can be well tolerated. > > >> On the contrary, simply using deviations at all is admitting that >> your implementation is non-compliant and non-interoperable. >> > > Yes, non-compliant. The client can decide whether the deviations can > cause problems or not. > Yes, and a YANG-aware CLI can present the operator with a tailored input form for each specific server. It may be semantic nonsense, and certainly scripts will not deal with deviations well. I am not arguing for removing them. I am just pointing out that simply patching the YANG syntax does little to solve the problem of vendors who do not implement standards correctly. It will still be a very labor-intensive 1-at-a-time problem. > >> That's why I have concerns the >> will not contain the deviations -- the server will >> just lie about implementing the full YANG module. >> > > So we need an RFC stating "you MUST not lie" and then by making this a > normative reference, we make this a better world. ;-) > > No -- I am not arguing for changes. Time will tell if this experiment works or not. How many vendors bothered with AGENT-CAPABILITIES? How many vendors want to advertise their lack-of-standards every message, instead of burying it in user docs somewhere? There is a certain leap-of-faith with the whole plan, but the YANG spec is well-intentioned, so if vendors do not follow the rules for not following the rules, it's not our fault. ;-) > /js > > Andy From phil@juniper.net Fri May 7 12:13: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 BEF453A6923 for ; Fri, 7 May 2010 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_05=-1.11, 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 qEob3RxPRiRV for ; Fri, 7 May 2010 12:13:51 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id C67A53A6994 for ; Fri, 7 May 2010 12:13:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS+RmWImUhPRhVoh5o4viRJDj6B1GNkwX@postini.com; Fri, 07 May 2010 12:13:30 PDT 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.436.0; Fri, 7 May 2010 12:01:01 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 07:07:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 07:07:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 07:07:14 -0700 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 o47E7DD41960; Fri, 7 May 2010 07:07:14 -0700 (PDT) (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 o47Do5qr008243; Fri, 7 May 2010 13:50:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005071350.o47Do5qr008243@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <1273229047.31401.67.camel@missotis> Date: Fri, 7 May 2010 09:50:05 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2010 14:07:14.0604 (UTC) FILETIME=[98437EC0:01CAEDEE] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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, 07 May 2010 19:13:52 -0000 Ladislav Lhotka writes: >Hi, > >YANG draft says in section 7.15: > > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). > >Why is this CLR necessary? So keep from breaking the contract of the original module. If module B augments A with a mandatory leaf, then only B-speaking clients can talk to servers that implement B, since a A-only client will not provide the mandatory node and will fail. Thanks, Phil From phil@juniper.net Fri May 7 12:13: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 887013A6923 for ; Fri, 7 May 2010 12:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.506 X-Spam-Level: X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_05=-1.11, 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 kIzdz5SrKIHS for ; Fri, 7 May 2010 12:13:51 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 191743A69A1 for ; Fri, 7 May 2010 12:13:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS+RmWaUDleaeOmbKd69d1oSUVmfFjwFG@postini.com; Fri, 07 May 2010 12:13:33 PDT 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.436.0; Fri, 7 May 2010 12:01:01 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 07:14:26 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 07:14:25 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 May 2010 07:14:25 -0700 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 o47EEOD44301; Fri, 7 May 2010 07:14:24 -0700 (PDT) (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 o47DvFiY008328; Fri, 7 May 2010 13:57:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005071357.o47DvFiY008328@idle.juniper.net> To: In-Reply-To: <4BE40116.3030405@iwl.com> Date: Fri, 7 May 2010 09:57:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2010 14:14:25.0411 (UTC) FILETIME=[990B6D30:01CAEDEF] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] Status of draft-ietf-netmod-yang 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, 07 May 2010 19:13:52 -0000 Andy Bierman writes: >On the contrary, simply using deviations at all is admitting that >your implementation is non-compliant and non-interoperable. Exactly. Deviations say "I am not compliant with the spec and here is exactly the places where I am misbehaving". It's not a magic wand to make broken implementations compliant, but a means of declaring how broken they are. >That's why I have concerns the >will not contain the deviations -- the server will >just lie about implementing the full YANG module. Sure, and I'm sure public repositories will appear that will list (in deviation format) how broken different implementations are. Even having a means of listing these gives operators that power to go to their vendors and give details about what's broken and MUST be fixed (before the gear is even purchased). Thanks, Phil From lhotka@cesnet.cz Sat May 8 00:33: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 91F9A3A689B for ; Sat, 8 May 2010 00:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.003 X-Spam-Level: * X-Spam-Status: No, score=1.003 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_50=0.001, 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 gvdUQDTeiBM0 for ; Sat, 8 May 2010 00:33:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id BD78A3A683E for ; Sat, 8 May 2010 00:33:07 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id CDBE92CDE058; Sat, 8 May 2010 09:32:54 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201005071350.o47Do5qr008243@idle.juniper.net> References: <201005071350.o47Do5qr008243@idle.juniper.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 09:32:53 +0200 Message-ID: <1273303973.7078.24.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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, 08 May 2010 07:33:08 -0000 Phil Shafer píše v Pá 07. 05. 2010 v 09:50 -0400: > Ladislav Lhotka writes: > >Hi, > > > >YANG draft says in section 7.15: > > > > If the target node is in another module, then nodes added by the > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > >Why is this CLR necessary? > > So keep from breaking the contract of the original module. If > module B augments A with a mandatory leaf, then only B-speaking > clients can talk to servers that implement B, since a A-only > client will not provide the mandatory node and will fail. The server advertizes both A and B and this is now the new contract. The client cannot simply ignore B, that would be error-prone. For example, the augmented nodes may contain some 'must' constraints addressing nodes in module A which the client has to observe, otherwise the A-only configuration would be invalid. Also, what if the server's initial configuration contains nodes added by B? Lada > > Thanks, > Phil -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat May 8 00:54:21 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 CA1F03A6920 for ; Sat, 8 May 2010 00:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[AWL=-0.257, 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 IJ-6BAivENgm for ; Sat, 8 May 2010 00:54:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B2AE33A681F for ; Sat, 8 May 2010 00:54:20 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 567F6C0002; Sat, 8 May 2010 09:54:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AqickaMuNodq; Sat, 8 May 2010 09:54:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0934C0058; Sat, 8 May 2010 09:54:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2269111FEAB2; Sat, 8 May 2010 09:54:06 +0200 (CEST) Date: Sat, 8 May 2010 09:54:06 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100508075406.GA92559@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273303973.7078.24.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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: Sat, 08 May 2010 07:54:21 -0000 On Sat, May 08, 2010 at 09:32:53AM +0200, Ladislav Lhotka wrote: > Phil Shafer p????e v P?? 07. 05. 2010 v 09:50 -0400: > > Ladislav Lhotka writes: > > >Hi, > > > > > >YANG draft says in section 7.15: > > > > > > If the target node is in another module, then nodes added by the > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > >Why is this CLR necessary? > > > > So keep from breaking the contract of the original module. If > > module B augments A with a mandatory leaf, then only B-speaking > > clients can talk to servers that implement B, since a A-only > > client will not provide the mandatory node and will fail. > > The server advertizes both A and B and this is now the new contract. The > client cannot simply ignore B, that would be error-prone. For example, > the augmented nodes may contain some 'must' constraints addressing nodes > in module A which the client has to observe, otherwise the A-only > configuration would be invalid. Also, what if the server's initial > configuration contains nodes added by B? Lada, we would fundamentally change the semantics of advertisements if they would require that a client has to understand _all_ advertised modules. This is flawed idea since vendors will have vendor specific extensions to standard modules and thus we would require that every client understands all vendor specific extensions. Hence, a data model design that contraints other definitions such that they do not work anymore in isolation is broken. And yes, with must expressions, you can do lots of harm if you are not extremely careful. They are a very sharp and thus potentially dangerous tool. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Sat May 8 01:40:44 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 C91C83A68DC for ; Sat, 8 May 2010 01:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, 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 I5MXOoIridX3 for ; Sat, 8 May 2010 01:40:44 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E1D793A68EE for ; Sat, 8 May 2010 01:40:43 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id AE2702CDE057; Sat, 8 May 2010 10:40:30 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100508075406.GA92559@elstar.local> References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> <20100508075406.GA92559@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 10:40:29 +0200 Message-ID: <1273308029.7078.57.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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, 08 May 2010 08:40:44 -0000 Juergen Schoenwaelder píše v So 08. 05. 2010 v 09:54 +0200: > On Sat, May 08, 2010 at 09:32:53AM +0200, Ladislav Lhotka wrote: > > Phil Shafer p????e v P?? 07. 05. 2010 v 09:50 -0400: > > > Ladislav Lhotka writes: > > > >Hi, > > > > > > > >YANG draft says in section 7.15: > > > > > > > > If the target node is in another module, then nodes added by the > > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > > > >Why is this CLR necessary? > > > > > > So keep from breaking the contract of the original module. If > > > module B augments A with a mandatory leaf, then only B-speaking > > > clients can talk to servers that implement B, since a A-only > > > client will not provide the mandatory node and will fail. > > > > The server advertizes both A and B and this is now the new contract. The > > client cannot simply ignore B, that would be error-prone. For example, > > the augmented nodes may contain some 'must' constraints addressing nodes > > in module A which the client has to observe, otherwise the A-only > > configuration would be invalid. Also, what if the server's initial > > configuration contains nodes added by B? > > Lada, we would fundamentally change the semantics of advertisements if > they would require that a client has to understand _all_ advertised > modules. This is flawed idea since vendors will have vendor specific > extensions to standard modules and thus we would require that every > client understands all vendor specific extensions. Hmm, so what happens if such a client receives a configuration containing nodes it doesn't know about? Is it supposed to ignore them or keep them unchanged? This seems very tricky and may open security holes. IMO both parties should work with an identical schema. > > Hence, a data model design that contraints other definitions such that > they do not work anymore in isolation is broken. And yes, with must > expressions, you can do lots of harm if you are not extremely careful. > They are a very sharp and thus potentially dangerous tool. Very true. That's probably why asserts proposed for XML Schema 1.1, which are a direct analogy to YANG's 'must', may only address the subtree of the node where they appear. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat May 8 01:45: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 48B4C3A68EE for ; Sat, 8 May 2010 01:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 BzXxZ0j+oOxG for ; Sat, 8 May 2010 01:45:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 242073A6889 for ; Sat, 8 May 2010 01:45:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5529C0036; Sat, 8 May 2010 10:45:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DFwewTW7yJZn; Sat, 8 May 2010 10:45:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BFE8C0002; Sat, 8 May 2010 10:45:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5C5611FEC40; Sat, 8 May 2010 10:45:14 +0200 (CEST) Date: Sat, 8 May 2010 10:45:14 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100508084514.GA92724@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> <20100508075406.GA92559@elstar.local> <1273308029.7078.57.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273308029.7078.57.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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: Sat, 08 May 2010 08:45:30 -0000 On Sat, May 08, 2010 at 10:40:29AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v So 08. 05. 2010 v 09:54 +0200: > > On Sat, May 08, 2010 at 09:32:53AM +0200, Ladislav Lhotka wrote: > > > Phil Shafer p????e v P?? 07. 05. 2010 v 09:50 -0400: > > > > Ladislav Lhotka writes: > > > > >Hi, > > > > > > > > > >YANG draft says in section 7.15: > > > > > > > > > > If the target node is in another module, then nodes added by the > > > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > > > > > >Why is this CLR necessary? > > > > > > > > So keep from breaking the contract of the original module. If > > > > module B augments A with a mandatory leaf, then only B-speaking > > > > clients can talk to servers that implement B, since a A-only > > > > client will not provide the mandatory node and will fail. > > > > > > The server advertizes both A and B and this is now the new contract. The > > > client cannot simply ignore B, that would be error-prone. For example, > > > the augmented nodes may contain some 'must' constraints addressing nodes > > > in module A which the client has to observe, otherwise the A-only > > > configuration would be invalid. Also, what if the server's initial > > > configuration contains nodes added by B? > > > > Lada, we would fundamentally change the semantics of advertisements if > > they would require that a client has to understand _all_ advertised > > modules. This is flawed idea since vendors will have vendor specific > > extensions to standard modules and thus we would require that every > > client understands all vendor specific extensions. > > Hmm, so what happens if such a client receives a configuration > containing nodes it doesn't know about? Is it supposed to ignore them or > keep them unchanged? This seems very tricky and may open security holes. > IMO both parties should work with an identical schema. You must be dreaming. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Sat May 8 02:46: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 6C23C3A67CF for ; Sat, 8 May 2010 02:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.06 X-Spam-Level: * X-Spam-Status: No, score=1.06 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_50=0.001, 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 zzTG8mlwlaG9 for ; Sat, 8 May 2010 02:46:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id A80FF3A693E for ; Sat, 8 May 2010 02:46:31 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id B13B92CDE057; Sat, 8 May 2010 11:46:18 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100508084514.GA92724@elstar.local> References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> <20100508075406.GA92559@elstar.local> <1273308029.7078.57.camel@missotis> <20100508084514.GA92724@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 11:46:17 +0200 Message-ID: <1273311977.7078.67.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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, 08 May 2010 09:46:47 -0000 Juergen Schoenwaelder píše v So 08. 05. 2010 v 10:45 +0200: > On Sat, May 08, 2010 at 10:40:29AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder p????e v So 08. 05. 2010 v 09:54 +0200: > > > On Sat, May 08, 2010 at 09:32:53AM +0200, Ladislav Lhotka wrote: > > > > Phil Shafer p????e v P?? 07. 05. 2010 v 09:50 -0400: > > > > > Ladislav Lhotka writes: > > > > > >Hi, > > > > > > > > > > > >YANG draft says in section 7.15: > > > > > > > > > > > > If the target node is in another module, then nodes added by the > > > > > > augmentation MUST NOT be mandatory nodes (see Section 3.1). > > > > > > > > > > > >Why is this CLR necessary? > > > > > > > > > > So keep from breaking the contract of the original module. If > > > > > module B augments A with a mandatory leaf, then only B-speaking > > > > > clients can talk to servers that implement B, since a A-only > > > > > client will not provide the mandatory node and will fail. > > > > > > > > The server advertizes both A and B and this is now the new contract. The > > > > client cannot simply ignore B, that would be error-prone. For example, > > > > the augmented nodes may contain some 'must' constraints addressing nodes > > > > in module A which the client has to observe, otherwise the A-only > > > > configuration would be invalid. Also, what if the server's initial > > > > configuration contains nodes added by B? > > > > > > Lada, we would fundamentally change the semantics of advertisements if > > > they would require that a client has to understand _all_ advertised > > > modules. This is flawed idea since vendors will have vendor specific > > > extensions to standard modules and thus we would require that every > > > client understands all vendor specific extensions. > > > > Hmm, so what happens if such a client receives a configuration > > containing nodes it doesn't know about? Is it supposed to ignore them or > > keep them unchanged? This seems very tricky and may open security holes. > > IMO both parties should work with an identical schema. > > You must be dreaming. The situation where the server uses some vendor-specific extensions that the client has no idea about is essentially just a special form of deviation, with all the consequences. I don't believe, dreaming or not, that this can ever work. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat May 8 02:57: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 2950D3A69E4 for ; Sat, 8 May 2010 02:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 t71Oh7VxiuGr for ; Sat, 8 May 2010 02:57:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F22023A6935 for ; Sat, 8 May 2010 02:57:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B78BCC0036; Sat, 8 May 2010 11:57:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z8ZZGLDeM10F; Sat, 8 May 2010 11:57:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD43FC0002; Sat, 8 May 2010 11:57:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2127211FEE1E; Sat, 8 May 2010 11:57:44 +0200 (CEST) Date: Sat, 8 May 2010 11:57:44 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100508095744.GB92838@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> <20100508075406.GA92559@elstar.local> <1273308029.7078.57.camel@missotis> <20100508084514.GA92724@elstar.local> <1273311977.7078.67.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273311977.7078.67.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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: Sat, 08 May 2010 09:57:59 -0000 On Sat, May 08, 2010 at 11:46:17AM +0200, Ladislav Lhotka wrote: > > > > You must be dreaming. > > The situation where the server uses some vendor-specific extensions that > the client has no idea about is essentially just a special form of > deviation, with all the consequences. I don't believe, dreaming or not, > that this can ever work. It is only a deviation if the extension changes the semantics of the module the client knows about. And this is why augmenting mandatory nodes is not allowed. If you assume that every client needs to be aware of all modules announced by a server, than that is just completely unrealistic, unless the client is shipped by whoever shipped the server. If we are talking about open standards, then assuming every client understands all modules announced by all servers does not seem to reflect my reality when I look at my heterogenous zoo of network devices. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Sat May 8 04:02: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 80C373A6452 for ; Sat, 8 May 2010 04:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.072 X-Spam-Level: * X-Spam-Status: No, score=1.072 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, 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 p2CD5QmL500s for ; Sat, 8 May 2010 04:02:01 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7D99A3A68AA for ; Sat, 8 May 2010 04:02:01 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id A9F6E2CDE057; Sat, 8 May 2010 13:01:48 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100508095744.GB92838@elstar.local> References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> <20100508075406.GA92559@elstar.local> <1273308029.7078.57.camel@missotis> <20100508084514.GA92724@elstar.local> <1273311977.7078.67.camel@missotis> <20100508095744.GB92838@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 08 May 2010 13:01:47 +0200 Message-ID: <1273316507.7078.95.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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, 08 May 2010 11:02:02 -0000 Juergen Schoenwaelder píše v So 08. 05. 2010 v 11:57 +0200: > On Sat, May 08, 2010 at 11:46:17AM +0200, Ladislav Lhotka wrote: > > > > > > You must be dreaming. > > > > The situation where the server uses some vendor-specific extensions that > > the client has no idea about is essentially just a special form of > > deviation, with all the consequences. I don't believe, dreaming or not, > > that this can ever work. > > It is only a deviation if the extension changes the semantics of the > module the client knows about. And this is why augmenting mandatory > nodes is not allowed. The extensions can change the semantics in many different ways. After the recent fuss concerning deviations, consider the following example: A standard module defines something this: module standard { ... prefix std; container outer { leaf crucial { mandatory true; ... } ... } Now, vendor Foo, Ltd. decides they don't like the "crucial" leaf. They can do either module foo { ... deviation "/std:outer/std:crucial" { deviate not-supported; } ... } or (if, say, deviations were banned) module foo { ... augment "/std:outer" { leaf ignore-crucial { description 'If true, completely ignore the "crucial" leaf.' type boolean; default true; } ... } Semantically, both versions are the same for the server, so why the deviation is bad and the augment isn't? Lada > > If you assume that every client needs to be aware of all modules > announced by a server, than that is just completely unrealistic, > unless the client is shipped by whoever shipped the server. If we are > talking about open standards, then assuming every client understands > all modules announced by all servers does not seem to reflect my > reality when I look at my heterogenous zoo of network devices. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat May 8 05:18: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 B429E3A67F0 for ; Sat, 8 May 2010 05:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.112 X-Spam-Level: X-Spam-Status: No, score=0.112 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 uHT6M+myGtvp for ; Sat, 8 May 2010 05:18:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A24323A69C6 for ; Sat, 8 May 2010 05:18:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CB9AC0002; Sat, 8 May 2010 14:18:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JRF8tcRjmGEP; Sat, 8 May 2010 14:18:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF6F3C003E; Sat, 8 May 2010 14:18:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B81A11FF128; Sat, 8 May 2010 14:18:10 +0200 (CEST) Date: Sat, 8 May 2010 14:18:10 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100508121810.GA93093@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , NETMOD Working Group References: <201005071350.o47Do5qr008243@idle.juniper.net> <1273303973.7078.24.camel@missotis> <20100508075406.GA92559@elstar.local> <1273308029.7078.57.camel@missotis> <20100508084514.GA92724@elstar.local> <1273311977.7078.67.camel@missotis> <20100508095744.GB92838@elstar.local> <1273316507.7078.95.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273316507.7078.95.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] mandatory augmenting nodes 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: Sat, 08 May 2010 12:18:27 -0000 On Sat, May 08, 2010 at 01:01:47PM +0200, Ladislav Lhotka wrote: > Semantically, both versions are the same for the server, so why the > deviation is bad and the augment isn't? I never said deviations are bad. /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 Sat May 8 15:40: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 DD47E3A6929 for ; Sat, 8 May 2010 15:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, 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 dhU-+4XRkBSK for ; Sat, 8 May 2010 15:40:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 83C6E3A6924 for ; Sat, 8 May 2010 15:40:43 -0700 (PDT) Received: from localhost (213-65-184-138-no181.tbcn.telia.com [213.65.184.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 59852616001 for ; Sun, 9 May 2010 00:40:31 +0200 (CEST) Date: Sun, 09 May 2010 00:40:30 +0200 (CEST) Message-Id: <20100509.004030.221759968.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] review of draft-ietf-netmod-usage-04 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, 08 May 2010 22:40:49 -0000 Hi, I have revied this document, and I have implemented the things that can be checked automatically in a plugin to pyang (see the --ietf parameter). Here are my comments: 3.1 Each YANG module or submodule contained within an Internet Draft or RFC MUST be identified as a 'Code Component' What does this mean? http://www.ietf.org/iesg/statement/copyright.html and http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt together says that a YANG module is a code component. Should the quoted sentence above be removed? I agree with the next sentence though: The strings '' and '' SHOULD be used to identify each Code Component. 3.1 The module description statement MUST contain the latest approved IETF Trust Copyright statement, which is available on-line, in section 4 of the Trust Legal Provisions (TLP) document, at: Does this mean that a YANG module MUST contain the simplified BSD license? Is ietf-yang-types not compliant with this guideline (it contains a reference to the license). 3.2 particularly to standards containing other module modules s/module modules/YANG modules/ ? 3.7 Is this section a duplicate of 3.1? Should 3.7 be removed? 4.3 In general, it is suggested that sub-statements containing default values SHOULD NOT be present. For example: I think we should explicitly list the stmts: 'status', 'mandatory','min-elements' , 'max-elements', 'config', 'yin-element'. 4.4. The text: Objects SHOULD NOT directly reference NETCONF capabilities, in order to specify optional behavior. Instead, a 'feature' statement SHOULD be defined instead of a NETCONF capability, and the 'if-feature' statement SHOULD be used within the optional object definition. is not clear. Specifically "instead of a NETCONF capability". Did you mean that a feture SHOULD be define which references a NETCONF capability? 4.4 If the condition associated with the desired semantics is not dependent on any particular instance value within the database, then an 'if-feature' statement SHOULD be used instead of a 'when' statement. Ok, but this is a tautology - if it is not dependent on a database value, it will be impossible to use a when statement. 4.4 You should say that you talk about XPath, e.g.: The 'attribute' and 'namespace' axis SHOULD NOT be used *in XPath expressions* 4.4 Implicit 'position' function calls within predicates SHOULD NOT be used. (e.g., //chapter[42]). What is the rationale for this? 4.5 The status statement SHOULD NOT be present if its value is 'current'. It MUST be present if its value is 'deprecated' or 'obsolete'. The second sentence is redundant. The revision-date sub-statement (within the imports statement) The revision-date sub-statement (within the include statement) Remove the parenthesis. 4.6. should we add that a revision stmt MUST have a description? 4.6 The text says: Modules are often extracted from their original documents and it is useful for developers and operators to know how to find the original source document in a consistent manner. which is a nice motivation for ...? I think the recommendation is to include a reference substatement to the original document in the revision statement. (Ok, this is actually what another paragraph says, further down, maybe reorder the paragraphs?) 4.7. Do we still recommend a *temporary* namespace? The examples aren't temporary, are they? 4.8. Top-level database objects MUST NOT be mandatory. I suggest SHOULD NOT. The argument seems to be that mandatory top-level object can never work. If that was true, they should be illegal in YANG. But we've had this debate before... 4.11 Minor: The 'anyxml' construct MAY be used with caution within configuration data. This may be useful to represent an HTML banner for example. Is this really an appropriate use case of anyxml? I think a string would be better. 4.12. The description statement MUST be present in 'rpc' statements defining new operations. Ok, but redundant (already specified in 4.11) -- In my code, I also check that the statements are in the canonical order, but I don't know if we want to make that a MUST in this document. /martin From mark.scott@ericsson.com Tue May 11 11:03: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 0385D3A6A82 for ; Tue, 11 May 2010 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 dIH2Wz3F0gQj for ; Tue, 11 May 2010 11:03:18 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B1B483A6A74 for ; Tue, 11 May 2010 11:03:05 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o4BI8D0I013191; Tue, 11 May 2010 13:08:26 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 11 May 2010 14:02:44 -0400 From: Mark Scott To: ext Martin Bjorklund , "andyb@iwl.com" Date: Tue, 11 May 2010 14:02:43 -0400 Thread-Topic: yang namespace suggestion Thread-Index: AcrxNCeOKpFFdoH5R+ukh04gYQ6prw== Message-ID: <75C89D709A9670428520E1CF8DD1344F2087FB3749@EUSAACMS0714.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_75C89D709A9670428520E1CF8DD1344F2087FB3749EUSAACMS0714e_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: [netmod] yang namespace suggestion 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, 11 May 2010 18:03:23 -0000 --_000_75C89D709A9670428520E1CF8DD1344F2087FB3749EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy and Martin, During the Gen-ART review of the monitoring draft some comments related to = yang namespace came up which I thought I'd raise to the attention of this M= L. Please advise if any updates are warranted in the yang guidelines to addres= s these, or what netmod's current response to each is: 1. Section 8 (IANA). The registration fails to explicitly mention that the= YANG Module Names registry is established by draft-ietf-netmod-yang. With= out this information, it might be difficult to IANA to find that registry, = because it does not exist yet. Question: What is the recommended means to refer to the Yang module regist= ry at this point? 2. draft-ietf-netmod-yang proposes a namespace prefix for registering modu= les, but I would suggest, if possible, to include the term "modules" in the= namespace name. This would easily differentiate namespaces of modules from= other YANG parameters different than modules. In your case, this namespace would be: urn:ietf.params.xml:ns:yang:modules:ietf-netconf-monitoring:rfcXXXX ^^^^^^^^ Question: What is netmod view on including this in the namespace? Another comment was made suggesting the removal of ":rfcXXX". I see that w= as agreed earlier so plan to update the remove this from the monitoring nam= espace and yang module. cheers, Mark --_000_75C89D709A9670428520E1CF8DD1344F2087FB3749EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy and Martin,

 

During the Gen-ART review of the monitoring draft some c= omments related to yang namespace came up which I thought I’d raise to the attention of this ML.

 

Please advise if any updates are warranted in the yang guidelines to address these, or what netmod’s current response to eac= h is:

 

1.  = Section 8 (IANA). The registration fails to explicitly mention that the YANG Module Names registry is established by draft-ietf-netmod-yang.  Without this information, it might be difficult to IANA to find that registry, because i= t does not exist yet.

&nbs= p;

Question:=   What is the recommended means to refer to the Yang module registry at this = point?

&nbs= p;

&nbs= p;

2.  = draft-ietf-netmod-yang proposes a namespace prefix for registering modules, but I would suggest, i= f possible, to include the term "modules" in the namespace name. Th= is would easily differentiate namespaces of modules from other YANG parameters different than modules.

In your c= ase, this namespace would be:

urn:ietf.= params.xml:ns:yang:modules:ietf-netconf-monitoring:rfcXXXX

 &nb= sp;            =              ^^^^^^^^

Question:=   What is netmod view on including this in the namespace?=

 

Another comment was made suggesting the removal of ̶= 0;:rfcXXX”.  I see that was agreed earlier so plan to update the remove this from the monitoring namespace and yang module.

 

cheers,

Mark

--_000_75C89D709A9670428520E1CF8DD1344F2087FB3749EUSAACMS0714e_-- From andyb@iwl.com Tue May 11 12:39:44 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 19C1A28C15F for ; Tue, 11 May 2010 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, 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 Vo8791PKAycS for ; Tue, 11 May 2010 12:39:43 -0700 (PDT) Received: from smtp125.iad.emailsrvr.com (smtp125.iad.emailsrvr.com [207.97.245.125]) by core3.amsl.com (Postfix) with ESMTP id 4B6183A6D2E for ; Tue, 11 May 2010 12:37:21 -0700 (PDT) Received: from relay32.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay32.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id F29A51B423F; Tue, 11 May 2010 15:37:09 -0400 (EDT) Received: by relay32.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8B7311B4207; Tue, 11 May 2010 15:37:09 -0400 (EDT) Message-ID: <4BE9B204.5060101@iwl.com> Date: Tue, 11 May 2010 12:37:40 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Mark Scott References: <75C89D709A9670428520E1CF8DD1344F2087FB3749@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <75C89D709A9670428520E1CF8DD1344F2087FB3749@EUSAACMS0714.eamcs.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] yang namespace suggestion 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, 11 May 2010 19:39:44 -0000 Mark Scott wrote: > > Andy and Martin, > > > > During the Gen-ART review of the monitoring draft some comments > related to yang namespace came up which I thought I’d raise to the > attention of this ML. > > > > Please advise if any updates are warranted in the yang guidelines to > address these, or what netmod’s current response to each is: > > > > 1. Section 8 (IANA). The registration fails to explicitly mention > that the YANG Module Names registry is established by > draft-ietf-netmod-yang. Without this information, it might be > difficult to IANA to find that registry, because it does not exist yet. > > > > Question: What is the recommended means to refer to the Yang module > registry at this point? > The YANG draft says this registry must be used. > > > > > 2. draft-ietf-netmod-yang proposes a namespace prefix for registering > modules, but I would suggest, if possible, to include the term > "modules" in the namespace name. This would easily differentiate > namespaces of modules from other YANG parameters different than modules. > > In your case, this namespace would be: > > urn:ietf.params.xml:ns:yang:modules:ietf-netconf-monitoring:rfcXXXX > > ^^^^^^^^ > > Question: What is netmod view on including this in the namespace? > > > > Another comment was made suggesting the removal of “:rfcXXX”. I see > that was agreed earlier so plan to update the remove this from the > monitoring namespace and yang module. > Yes, you should remove :rfcXXXX. The URI string is defined in the YANG draft, not this draft. I do not think we need to make the YANG base URI string longer. It is already in use. The term 'modules' is sort of redundant. This is the XML namespace YANG uses for the XML attributes it adds to the NETCONF protocol: urn:ietf:params:xml:ns:yang:1 Note that '1' is not a valid YANG module name, so there it no chance a valid module will be confused with the YANG XML namespace (yang-12, sec. 5.3.1). > > > cheers, > > Mark > Andy From david.partain@ericsson.com Wed May 12 04:25:56 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 398273A6783 for ; Wed, 12 May 2010 04:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_40=-0.185, 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 MnkKFC4s8TMV for ; Wed, 12 May 2010 04:25:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0A7843A6950 for ; Wed, 12 May 2010 04:25:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-e3-4bea903785ac Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 28.66.08537.7309AEB4; Wed, 12 May 2010 13:25:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 13:25:43 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 13:25:43 +0200 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 12 May 2010 13:25:42 +0200 User-Agent: KMail/1.9.10 References: <201005061457.09782.david.partain@ericsson.com> In-Reply-To: <201005061457.09782.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201005121325.42241.david.partain@ericsson.com> X-OriginalArrivalTime: 12 May 2010 11:25:43.0405 (UTC) FILETIME=[DBECA1D0:01CAF1C5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 12 May 2010 11:25:56 -0000 Greetings, So far, there have been very few comments on this WGLC for the architecture draft. The same is true of the usage draft (not going to send separate mail for that). The chairs would be very grateful if folks would read and react to this documents by Monday. Again, "It's fine. Ship it!" is much better than silence. Cheers, David On Thursday 06 May 2010 14.57.09 David Partain wrote: > Greetings, > > This is an eleven-day working group last call on the current working group > document: > > Title: An NETCONF- and NETMOD-based Architecture for Network Management > URL: http://tools.ietf.org/html/draft-ietf-netmod-arch-05 > > This WGLC will end on May 17, 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. > > NOTE: It is very important that the chairs can judge whether the Working > Group thinks we're finished or not. As such, please provide your comments, > even if it is only to say "It's fine. Ship it!" > > Thanks. > > David^2 From dromasca@avaya.com Wed May 12 12:28:09 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 1AFBC3A6932 for ; Wed, 12 May 2010 12:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_20=-0.74] 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 muhIoRTDRb16 for ; Wed, 12 May 2010 12:28:08 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id BD61828C152 for ; Wed, 12 May 2010 12:16:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="15632851" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 12 May 2010 15:16:13 -0400 X-IronPort-AV: E=Sophos;i="4.53,217,1272859200"; d="scan'208";a="474408404" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2010 15:16:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 21:16:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-netmod-yang Thread-Index: AcryB0YTvcLYPVn3RjuEDkMn1aiEuwAAEf7Q From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: DISCUSS: draft-ietf-netmod-yang 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, 12 May 2010 19:28:09 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Tim Polk Sent: Wednesday, May 12, 2010 10:14 PM To: iesg@ietf.org Cc: netmod-chairs@tools.ietf.org; draft-ietf-netmod-yang@tools.ietf.org Subject: DISCUSS: draft-ietf-netmod-yang=20 Discuss: [Sorry about the late discuss text. I encountered a tracker bug that prevented entry before the telechat.] (1) I believe that Roberts comment on deviation merits a discuss because of interoperability and conformance concerns. I would like to understand the intent of the wg, since this seems to create a large loophole. (2) I believe this document should note that specifications using yang can indicate that a deviation of "not supported" is not allowed for a particular object. This feature should be used to ensure that a minimum level of interoperability is achieved. From ray@iijlab.net Sun May 16 21:33: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 CC6553A6CAC for ; Sun, 16 May 2010 21:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 z3bDSHut9B86 for ; Sun, 16 May 2010 21:33:52 -0700 (PDT) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by core3.amsl.com (Postfix) with ESMTP id 7737C3A6B74 for ; Sun, 16 May 2010 21:33:51 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iijlab.net;h=Message-ID: Date:From:MIME-Version:To:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; i=ray@iijlab.net; s=omgo1; t=1274070822; x=1275280422; bh=5GOH0Xtl73bShaEMwRmeGamKcegkzsf2YYkSkaukl1c=; b=oSRO1zBr49tOe4DtgcTkVpLkmbw kG2RxI24fzsrK5Y28rvxMw0Fpc2DVBvVXA0oSY5/zT6Xs4chh6oTmet1VCddQeQFcvGoitnTUbZVh WSh8XiLqwmOMbBtlBUi4PNO+8UCwtj/UoQoyV0Zrb42f6ksk/H5t6RxTpuomtU9TzXc=; Received: by omgo.iij.ad.jp (mo30) id o4H4Xguk002966; Mon, 17 May 2010 13:33:42 +0900 Message-ID: <4BF0C716.8010600@iijlab.net> Date: Mon, 17 May 2010 13:33:26 +0900 From: "Ray S. Atarashi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: netmod@ietf.org References: <201005061457.09782.david.partain@ericsson.com> <201005121325.42241.david.partain@ericsson.com> In-Reply-To: <201005121325.42241.david.partain@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 04:33:53 -0000 Hi, I read the architecture draft. It's fine for me. Section 3.1 is useful to understand the architecture. Ray (2010/05/12 20:25), David Partain wrote: > Greetings, > > So far, there have been very few comments on this WGLC for the architecture > draft. The same is true of the usage draft (not going to send separate mail > for that). > > The chairs would be very grateful if folks would read and react to this > documents by Monday. Again, "It's fine. Ship it!" is much better than > silence. > > Cheers, > > David > > On Thursday 06 May 2010 14.57.09 David Partain wrote: >> Greetings, >> >> This is an eleven-day working group last call on the current working group >> document: >> >> Title: An NETCONF- and NETMOD-based Architecture for Network Management >> URL: http://tools.ietf.org/html/draft-ietf-netmod-arch-05 >> >> This WGLC will end on May 17, 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. >> >> NOTE: It is very important that the chairs can judge whether the Working >> Group thinks we're finished or not. As such, please provide your comments, >> even if it is only to say "It's fine. Ship it!" >> >> Thanks. >> >> David^2 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Mon May 17 02:05: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 9DFF23A67F7 for ; Mon, 17 May 2010 02:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.823 X-Spam-Level: * X-Spam-Status: No, score=1.823 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_95=3, 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 BJGCKXYX10Fo for ; Mon, 17 May 2010 02:05:04 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 00EE23A684A for ; Mon, 17 May 2010 02:05:01 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 72DFB76C098 for ; Mon, 17 May 2010 11:04:52 +0200 (CEST) Date: Mon, 17 May 2010 11:04:52 +0200 (CEST) Message-Id: <20100517.110452.185315649.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <201005121325.42241.david.partain@ericsson.com> References: <201005061457.09782.david.partain@ericsson.com> <201005121325.42241.david.partain@ericsson.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 09:05:05 -0000 Hi, I have reviewed this document, and I think it is fine. I have some mostly minor editorial comments, and some YANG/XML corrections. ------------------------------ 1. Since the title is being changed to "An Architecture for Network Management using NETCONF and YANG", and this section also talks about NETCONF, shouldn't this section be called "Origins of NETCONF and YANG"? BTW, you may want to expand NETCONF. ------------------------------ 2.2 namespace http://example.org/netconf/ospf; The argument must be quoted, otherwise the // marks a line comment: namespace "http://example.org/netconf/ospf"; The same namespace issue exists in the model in 2.2.3. ------------------------------ 2.2 A leaf node that can appear as multiple times s/as// s/Define a/Defines a/ s/Incorporate the/Incorporates the/ (to match the other entries in the table) ------------------------------ 2.2.2 s/The "deviation" give/The "deviation" statement gives/ ------------------------------ 2.2.3 Remove the element from the XML. It doesn't match the data models. ------------------------------ 3.4 The modeler's role constructing a model based on their in-depth knowledge of the problem domain being modeled. s/role constructing/role is constructing/ ? ------------------------------ 3.5 The reviewer role is perhaps the more important most important? I assume the idea that the XSLT script runs on the YIN module? Maybe you should make this clear. ------------------------------ 3.7.3 You shoudn't use the ietf- prefix for an example model, so s/ietf-bgpvpn/example-bgpvpn/ ------------------------------ 4.1 s/behave as is if the/behave as if the/ (I realized that this text was quoated from the YANG spec, and the same error was there as well; now fixed). ------------------------------ 4.1 If a data value is given as part of those instructions is the default value, s/value is given/value that is given/ ------------------------------ 4.2 s/describes it a state data/describes it as state data/ ------------------------------ 4.2 An implementation that emits an integer leaf as "cow" would be difficult to manage, but applications must expect to encounter such misbehaving devices in the field. I think you should remove the last part. I think it says that applications should not crash if given invalid data. ------------------------------ 4.3.3.2 and 4.3.3.3 I am not too happy with these sections - they document the discussion we had, but is the intention that readers of this spec should take these options into account and create their own rpcs etc? I would prefer these sections to be removed, but if the WG wants to keep them I can live with that. /martin From phil@juniper.net Mon May 17 07:02: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 F351C3A68CE for ; Mon, 17 May 2010 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_50=0.001, 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 aOYHVHODpRhR for ; Mon, 17 May 2010 07:02:49 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id AD7063A68CB for ; Mon, 17 May 2010 07:02:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS/FMeK2fALh1rDML2iKOUzkV6LD3EoR+@postini.com; Mon, 17 May 2010 07:02:40 PDT 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.436.0; Mon, 17 May 2010 07:01:34 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 May 2010 07:01:34 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 07:01:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 May 2010 07:01:33 -0700 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 o4HE1WD16826; Mon, 17 May 2010 07:01:32 -0700 (PDT) (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 o4HDiDF0099965; Mon, 17 May 2010 13:44:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005171344.o4HDiDF0099965@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100517.110452.185315649.mbj@tail-f.com> Date: Mon, 17 May 2010 09:44:13 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 May 2010 14:01:33.0485 (UTC) FILETIME=[75125DD0:01CAF5C9] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 14:02:51 -0000 Martin Bjorklund writes: >I have reviewed this document, and I think it is fine. I have some >mostly minor editorial comments, and some YANG/XML corrections. Thank you for the review. I have made all corrections, except where indicated below. >BTW, you may want to expand NETCONF. Expand in what way? "The Network Configuration Protocol (NETCONF)"? Or do you mean expand the section/contents? >2.2.2 > >s/The "deviation" give/The "deviation" statement gives/ >------------------------------ This sentence uses the word "flexibility" in a bad way, so I changed it to: The "deviation" statement allows the device, to indicate parts of a YANG module which the device does not faithfully implement. >4.2 > > An implementation that emits an integer leaf as > "cow" would be difficult to manage, but applications must expect to > encounter such misbehaving devices in the field. > >I think you should remove the last part. I think it says that >applications should not crash if given invalid data. I think this is more than just "should not crash". I think an app needs to think about how it will deal with devices that do not toe the line. If some developer writes "none" were the spec says it's a number, then having your app throw an exception when it sees that data is a valid implementation choice. If you app store the value in an integer field in a database, that may be your only choice. But if the meaning of this field is not vital to your app, then using a string to hold the value may be sufficient to allow you to continue to perform the apps job in the face of a non-compliant device. Basically when the device emits a clearly bad value, the app writer can choose between purity and functionality, and it's a grey scale. Should I add some of these words to make the point more plain? >4.3.3.2 and 4.3.3.3 >I would prefer these sections to be removed, but if the WG wants to >keep them I can live with that. The sections were added at the specific request of the WG. IMHO this is still an open problem and we do not have a reasonable answer. The section presents (if briefly) the unreasonable ones, why they aren't reasonable, and why we're not really concerned. Thanks, Phil From andyb@iwl.com Mon May 17 08:27: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 6DA6528C0DE for ; Mon, 17 May 2010 08:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_50=0.001, 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 m3BP4sJQi6Zh for ; Mon, 17 May 2010 08:27:04 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 174DD3A6A75 for ; Mon, 17 May 2010 08:22:18 -0700 (PDT) Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 13CFF30B0125; Mon, 17 May 2010 11:22:10 -0400 (EDT) Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AB67530B0121; Mon, 17 May 2010 11:22:09 -0400 (EDT) Message-ID: <4BF15F23.9010403@iwl.com> Date: Mon, 17 May 2010 08:22:11 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005171344.o4HDiDF0099965@idle.juniper.net> In-Reply-To: <201005171344.o4HDiDF0099965@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 15:27:05 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >> I have reviewed this document, and I think it is fine. I have some >> mostly minor editorial comments, and some YANG/XML corrections. >> > > Thank you for the review. I have made all corrections, except > where indicated below. > > >> BTW, you may want to expand NETCONF. >> > > Expand in what way? "The Network Configuration Protocol (NETCONF)"? > Or do you mean expand the section/contents? > > >> 2.2.2 >> >> s/The "deviation" give/The "deviation" statement gives/ >> ------------------------------ >> > > This sentence uses the word "flexibility" in a bad way, so I > changed it to: > > The "deviation" statement allows the device, to indicate parts > of a YANG module which the device does not faithfully implement. > > >> 4.2 >> >> An implementation that emits an integer leaf as >> "cow" would be difficult to manage, but applications must expect to >> encounter such misbehaving devices in the field. >> >> I think you should remove the last part. I think it says that >> applications should not crash if given invalid data. >> > > I think this is more than just "should not crash". I think an app > needs to think about how it will deal with devices that do not toe > the line. If some developer writes "none" were the spec says it's > a number, then having your app throw an exception when it sees that > data is a valid implementation choice. If you app store the value > in an integer field in a database, that may be your only choice. > But if the meaning of this field is not vital to your app, then > using a string to hold the value may be sufficient to allow you to > continue to perform the apps job in the face of a non-compliant > device. > > Basically when the device emits a clearly bad value, the app writer > can choose between purity and functionality, and it's a grey scale. > > Should I add some of these words to make the point more plain? > > I do not agree with the idea of classifying the type of non-conformance in sec. 4.2: o [strict compliance] behavior that follow the model completely o [modeled deviations] behavior that follows within deviations allowed by the model o [allowable deviations] behavior that falls outside the model, but can still be handled o [unacceptable deviations] behavior that is not at all consistent with the model The YANG and NETCONF WGs have not agreed on such a classification. IMO, this list is misleading. It suggests that the client can automatically make reasonable decisions based on the syntax patches that deviations represent. There is no explanation how they are standard or why they are needed. If the server makes arbitrary changes to the syntax and or semantics of a YANG data model, then it has already broken the contract. I strongly object to the notion that the deviations represent a new contract. They exist in YANG to describe how the contract has been broken. Especially bullet 2. There are no deviations allowed by the model. That is the empty set. If you mean if-feature or when-stmt is 'false', then that is part of the model, but deviations are never part of the data model. There are only 2 bullets: o [strict compliance] behavior that follows the model completely o [non-compliance] behavior that includes any deviation-stmts applied to the model >> 4.3.3.2 and 4.3.3.3 >> I would prefer these sections to be removed, but if the WG wants to >> keep them I can live with that. >> > > The sections were added at the specific request of the WG. IMHO > this is still an open problem and we do not have a reasonable answer. > The section presents (if briefly) the unreasonable ones, why they > aren't reasonable, and why we're not really concerned. > > I agree with Martin. This is an informational overview. Sec. 4.3.2 (named 'Definitions') goes beyond the scope of this draft and should be removed. The WG has not agreed to 1 view of the NETCONF server. That is why there are :candidate, :writable-running, :startup, and :with-defaults capabilities. > Thanks, > Phil > Andy From phil@juniper.net Mon May 17 08:42: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 11BF53A6A8E for ; Mon, 17 May 2010 08:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.328 X-Spam-Level: X-Spam-Status: No, score=-5.328 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_20=-0.74, 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 Ju7fMp5-59x2 for ; Mon, 17 May 2010 08:42:41 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 4B66E28C1AA for ; Mon, 17 May 2010 08:39:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS/FjQ4/EiEBhayKIPNcuTRBXFmtFUx2R@postini.com; Mon, 17 May 2010 08:39:52 PDT 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.436.0; Mon, 17 May 2010 08:36:05 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 May 2010 08:36:05 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 08:36:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 May 2010 08:36:04 -0700 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 o4HFa3D61780; Mon, 17 May 2010 08:36:03 -0700 (PDT) (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 o4HFIiXa000645; Mon, 17 May 2010 15:18:44 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005171518.o4HFIiXa000645@idle.juniper.net> To: In-Reply-To: <4BF15F23.9010403@iwl.com> Date: Mon, 17 May 2010 11:18:44 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 May 2010 15:36:04.0459 (UTC) FILETIME=[A93C53B0:01CAF5D6] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 15:42:42 -0000 Andy Bierman writes: >The YANG and NETCONF WGs have not agreed on such a classification. This is from email on the mailing list, and represents my impression of the WG thought. If anyone else disagrees, please speak up. >If the server makes arbitrary changes to the syntax and or >semantics of a YANG data model, then it has already broken >the contract. Yup, that's what the draft says. >I strongly object to the notion that the deviations represent >a new contract. The draft does not say this. >This is an informational overview. >Sec. 4.3.2 (named 'Definitions') goes beyond >the scope of this draft and should be removed. The WG asked this section be added, and I've added it. If the WG votes to remove it, I'll remove it. Thanks, Phil From andyb@iwl.com Mon May 17 09:09: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 E220028C1A1 for ; Mon, 17 May 2010 09:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_50=0.001, 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 syxSaeHYgZuf for ; Mon, 17 May 2010 09:09:42 -0700 (PDT) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 99AA93A68A3 for ; Mon, 17 May 2010 09:06:21 -0700 (PDT) Received: from relay21.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay21.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 8BC9A2E406BF; Mon, 17 May 2010 12:06:13 -0400 (EDT) Received: by relay21.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4676F2E4049D; Mon, 17 May 2010 12:06:13 -0400 (EDT) Message-ID: <4BF16976.9040206@iwl.com> Date: Mon, 17 May 2010 09:06:14 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005171518.o4HFIiXa000645@idle.juniper.net> In-Reply-To: <201005171518.o4HFIiXa000645@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 16:09:43 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> The YANG and NETCONF WGs have not agreed on such a classification. >> > > This is from email on the mailing list, and represents my impression > of the WG thought. If anyone else disagrees, please speak up. > > >> If the server makes arbitrary changes to the syntax and or >> semantics of a YANG data model, then it has already broken >> the contract. >> > > Yup, that's what the draft says. > > >> I strongly object to the notion that the deviations represent >> a new contract. >> > > The draft does not say this. > o [modeled deviations] behavior that follows within deviations allowed by the model This bullet does imply that there are deviations that somehow fall within the model. This will confuse people learning YANG, because YANG defines a deviation as being outside the model. They are being presented in this section as if some deviations are part of the model. This bullet is wrong. There are never any deviations allowed by the model. The excuse 'well, maybe the client implementation will not care about that specific object' is not relevant because the YANG module is a representation of the conceptual data model, not any particular implementation. There are no examples of any of these classifications either, making the section even less helpful. Rarely, implementations may make decisions that prevent compliance with the standard. Such occasions are regrettable, but they remain a part of reality, and modelers and application writers ignore them at their own risk. An implementation that emits an integer leaf as "cow" would be difficult to manage, but applications must expect to encounter such misbehaving devices in the field. This entire section seems to be suggesting that YANG module compliance is a nice goal, but here is a different view of compliance -- the 'close enough for jazz' architecture. I do not agree that the IETF should be suggesting that servers which implement the string 'cow' instead of a number are acceptable, and client applications need to work with servers that demonstrate a blatant disregard for interoperability. I think the entire section 4.2 should be removed. It is actually harmful to interoperability and contradicts information in the YANG spec. > >> This is an informational overview. >> Sec. 4.3.2 (named 'Definitions') goes beyond >> the scope of this draft and should be removed. >> > > The WG asked this section be added, and I've added it. If > the WG votes to remove it, I'll remove it. > > I am voting to remove it. > Thanks, > Phil > > Andy From phil@juniper.net Mon May 17 09:34: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 5420B3A6D3B for ; Mon, 17 May 2010 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 NRA7Tw9mT4dy for ; Mon, 17 May 2010 09:34:41 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 75ADD28C195 for ; Mon, 17 May 2010 09:30:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKS/FvA8ApUFVpL+URpOQXxnAMvCSgZBYV@postini.com; Mon, 17 May 2010 09:30:07 PDT 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.436.0; Mon, 17 May 2010 09:29:35 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 May 2010 09:29:35 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 09:29:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 May 2010 09:29:34 -0700 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 o4HGTXD85466; Mon, 17 May 2010 09:29:33 -0700 (PDT) (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 o4HGCEo4001251; Mon, 17 May 2010 16:12:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201005171612.o4HGCEo4001251@idle.juniper.net> To: In-Reply-To: <4BF16976.9040206@iwl.com> Date: Mon, 17 May 2010 12:12:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 May 2010 16:29:34.0163 (UTC) FILETIME=[225E4A30:01CAF5DE] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 16:34:42 -0000 Andy Bierman writes: > o [modeled deviations] behavior that follows within deviations > allowed by the model Overloaded the word "deviations", since the predated the statement's creation. This refers to "features", since that's a mechanism for the modeler to describe how the contract can vary. I'll choose a better word. Thanks, Phil From andyb@iwl.com Mon May 17 09:42: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 6FA113A699F for ; Mon, 17 May 2010 09:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_50=0.001, 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 WuJY34Ifx851 for ; Mon, 17 May 2010 09:42:42 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id B4BDA3A6A4D for ; Mon, 17 May 2010 09:41:44 -0700 (PDT) Received: from relay24.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id AF4F934E868C; Mon, 17 May 2010 12:41:36 -0400 (EDT) Received: by relay24.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6F34334E85AF; Mon, 17 May 2010 12:41:36 -0400 (EDT) Message-ID: <4BF171C2.40102@iwl.com> Date: Mon, 17 May 2010 09:41:38 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Phil Shafer References: <201005171612.o4HGCEo4001251@idle.juniper.net> In-Reply-To: <201005171612.o4HGCEo4001251@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 16:42:43 -0000 Phil Shafer wrote: > Andy Bierman writes: > >> o [modeled deviations] behavior that follows within deviations >> allowed by the model >> > > Overloaded the word "deviations", since the predated the statement's > creation. This refers to "features", since that's a mechanism for > the modeler to describe how the contract can vary. I'll choose a > better word. > IMO, this section needs more than a 1 word fix. I would not be surprised if the IESG thinks so as well. YANG deviations are good because they can describe the way a server is non-compliant. It is completely data-model dependent how relevant a particular deviation will be to implementations of that data model. For example, for something like a standard MTU value, changing the default by even a few bytes could have a big impact on the network. For a ping retry interval, changing the default by a few seconds may not have any impact at all on operations. This is what this section should say about deviations: Deviations describe non-compliant behavior. It is up to the client application developer to examine each deviation on a case-by-case basis, to determine if and how the deviation can be tolerated within the application. > Thanks, > Phil > > Andy From mbj@tail-f.com Mon May 17 13:20: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 92FAD3A6A0A for ; Mon, 17 May 2010 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_50=0.001, 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 OcaKfM8LOFKe for ; Mon, 17 May 2010 13:20:32 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AE6853A6B38 for ; Mon, 17 May 2010 13:20:05 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C68576C098; Mon, 17 May 2010 22:19:56 +0200 (CEST) Date: Mon, 17 May 2010 22:19:55 +0200 (CEST) Message-Id: <20100517.221955.235020516.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201005171344.o4HDiDF0099965@idle.juniper.net> References: <20100517.110452.185315649.mbj@tail-f.com> <201005171344.o4HDiDF0099965@idle.juniper.net> X-Mailer: Mew version 7.0.50 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: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 20:20:34 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >BTW, you may want to expand NETCONF. > > Expand in what way? "The Network Configuration Protocol (NETCONF)"? Yes. > >2.2.2 > > > >s/The "deviation" give/The "deviation" statement gives/ > >------------------------------ > > This sentence uses the word "flexibility" in a bad way, so I > changed it to: > > The "deviation" statement allows the device, to indicate parts > of a YANG module which the device does not faithfully implement. Ok. > >4.2 > > > > An implementation that emits an integer leaf as > > "cow" would be difficult to manage, but applications must expect to > > encounter such misbehaving devices in the field. > > > >I think you should remove the last part. I think it says that > >applications should not crash if given invalid data. > > I think this is more than just "should not crash". I think an app > needs to think about how it will deal with devices that do not toe > the line. If some developer writes "none" were the spec says it's > a number, then having your app throw an exception when it sees that > data is a valid implementation choice. If you app store the value > in an integer field in a database, that may be your only choice. > But if the meaning of this field is not vital to your app, then > using a string to hold the value may be sufficient to allow you to > continue to perform the apps job in the face of a non-compliant > device. > > Basically when the device emits a clearly bad value, the app writer > can choose between purity and functionality, and it's a grey scale. > > Should I add some of these words to make the point more plain? I still would prefer if the part from "but applications..." was removed. Ok, you do not say "MUST expect ..." but then what does the "must" mean? I agree with Andy that we should not encourage people to ignore the contract that the YANG module is. /martin From andyb@iwl.com Mon May 17 14:27: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 160873A68C7 for ; Mon, 17 May 2010 14:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_50=0.001, J_CHICKENPOX_65=0.6, 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 IywTceTMjAYP for ; Mon, 17 May 2010 14:27:51 -0700 (PDT) Received: from smtp165.iad.emailsrvr.com (smtp165.iad.emailsrvr.com [207.97.245.165]) by core3.amsl.com (Postfix) with ESMTP id 2DE293A680A for ; Mon, 17 May 2010 14:27:48 -0700 (PDT) Received: from relay16.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 297A71B406C; Mon, 17 May 2010 17:27:40 -0400 (EDT) Received: by relay16.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9C5A31B405E; Mon, 17 May 2010 17:27:39 -0400 (EDT) Message-ID: <4BF1B4CD.80903@iwl.com> Date: Mon, 17 May 2010 14:27:41 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <20100517.110452.185315649.mbj@tail-f.com> <201005171344.o4HDiDF0099965@idle.juniper.net> <20100517.221955.235020516.mbj@tail-f.com> In-Reply-To: <20100517.221955.235020516.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: An NETCONF- and NETMOD-based Architecture for Network Management 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, 17 May 2010 21:27:53 -0000 Martin Bjorklund wrote: > Phil Shafer wrote: > >> Martin Bjorklund writes: >> >>> BTW, you may want to expand NETCONF. >>> >> Expand in what way? "The Network Configuration Protocol (NETCONF)"? >> > > Yes. > > >>> 2.2.2 >>> >>> s/The "deviation" give/The "deviation" statement gives/ >>> ------------------------------ >>> >> This sentence uses the word "flexibility" in a bad way, so I >> changed it to: >> >> The "deviation" statement allows the device, to indicate parts >> of a YANG module which the device does not faithfully implement. >> > > Ok. > > >>> 4.2 >>> >>> An implementation that emits an integer leaf as >>> "cow" would be difficult to manage, but applications must expect to >>> encounter such misbehaving devices in the field. >>> >>> I think you should remove the last part. I think it says that >>> applications should not crash if given invalid data. >>> >> I think this is more than just "should not crash". I think an app >> needs to think about how it will deal with devices that do not toe >> the line. If some developer writes "none" were the spec says it's >> a number, then having your app throw an exception when it sees that >> data is a valid implementation choice. If you app store the value >> in an integer field in a database, that may be your only choice. >> But if the meaning of this field is not vital to your app, then >> using a string to hold the value may be sufficient to allow you to >> continue to perform the apps job in the face of a non-compliant >> device. >> >> Basically when the device emits a clearly bad value, the app writer >> can choose between purity and functionality, and it's a grey scale. >> >> Should I add some of these words to make the point more plain? >> > > I still would prefer if the part from "but applications..." was > removed. Ok, you do not say "MUST expect ..." but then what does the > "must" mean? I agree with Andy that we should not encourage people to > ignore the contract that the YANG module is. > I support deviations. I fully implemented them, and the NETCONF/YANG based 'server view customization' is 1000 times better than SNMP or CLI ever had. It works fine for interactive CLI by showing the operator the exact data model the server claims it supports. Not so much for scripts so far, but not impossible, just way harder. But I strongly object to the characterization of the YANG deviation statement as having anything to do with altering YANG module conformance. YANG has only 2 actual conformance mechanisms. The starting point for conformance is everything included in the module, except: - any data-def-stmt covered by an if-feature-stmt - any data-def-stmt that is config=false and mandatory=false Those 2 classifications are optional-to-implement for the server. I prefer to have text like the preceding paragraph in the conformance section of the ARCH spec, and have a separate section called 'Deviations', that gives actual examples, and explains that the developer must evaluate each deviation impact on the client implementation (not the model!). IMO, my example about MTU vs. retry-interval is a good example of why just altering 'default 1500' to 'default 1497' is just pure syntax, devoid of semantics. The '4 degrees of deviation conformance' are totally unacceptable. > > > /martin > Andy From j.schoenwaelder@jacobs-university.de Tue May 18 00:40:14 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 CD7C53A6767 for ; Tue, 18 May 2010 00:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.167 X-Spam-Level: * X-Spam-Status: No, score=1.167 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_80=2, 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 W0TPM9d+oSMr for ; Tue, 18 May 2010 00:40:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 394553A6852 for ; Tue, 18 May 2010 00:40:03 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66DF2C0009 for ; Tue, 18 May 2010 09:39:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PN1v0TAmsI96; Tue, 18 May 2010 09:39:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A78BDC000C; Tue, 18 May 2010 09:39:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 94811123D627; Tue, 18 May 2010 09:39:50 +0200 (CEST) Date: Tue, 18 May 2010 09:39:50 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20100518073950.GB11495@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 draft-ietf-netmod-arch-05.txt 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, 18 May 2010 07:40:14 -0000 Hi, this is my WG last call review of . The document has made very good progress since I reviewed it the last time but I think there is still some minor work left to be done before it is ready to go to the IESG. My comments are in document order, not ordered by significance. a) p1: s/operational data/state data/ This aligns with RFC 4741 terminology. b) p1: The abstract should IMHO also mention notifications, they are mentioned later on anyway. c) p4: s/Origins of YANG/Origins of NETCONF and YANG/ d) p4: Did operators really ask for "low implementation costs"? I would understand if they ask for "low deployment costs" - low implementation costs is something vendors usually worry about. e) p4: s/Existing data modeling/Existing general purpose data modeling/ f) p4: s/70 and 71/70/ If you leave IETF 71 there, then the chronologic sequence breaks apart since the design team formed after IETF 70 produced results presented at IETF 71 as far as I recall. g) p5: s/that easily/that is easily/ h) p5: s/brings NETCONF/brings NETCONF and YANG/ i) p6: s/Elements of YANG/Elements of the Architecture/ j) p6: Remove the following one sentence paragraph: YANG is focused on creating data models for NETCONF, and any understanding of the former must begin with the latter. Since the scope of the architecture document was broadened, this sentence is pretty much useless. k) p7: I find section 2.1 a bit terse compared to section 2.2 I think it would not hurt to explain the different datastores NETCONF provides in one paragraph. It might also be helpful to explain the notion of capabilities in one paragraph. Furthermore, it might be useful to summarize the operations NETCONF provides, e.g. by creating a table with columns Operation Description, much like we do for YANG statements in section 2.2. l) p8: I suggest to add a new section 2.2 "NETCONF Transport Mappings" that briefly reviews the transport mappings available. I think it is useful if this document provides a complete overview and the relevant pointers to related documents (not just RFC 4741). m) p8: Similarily, I suggest to add a new 2.3 talking about NETCONF notifications. Perhaps we should also mention the NETCONF monitoring data model somewhere. n) p8: s/data model nodes/data nodes/ To be consistent with the YANG terminology (where the term "data node" is defined). o) p8: s/data instances/data nodes/ p) p8: s/leaf data values/data nodes forming leafs of the data tree/ q) p9: I suggest to put the statements into canonical order (see section 12 of the YANG specification). r) p9: I would replace the import with two imports since that is a more likely organization import ospf-types { prefix ospf-types; } import interface-types { prefix if-types; } and then use ospf-types:area-id and if-types:interface-name. s) p10: s/keys leafs/key leafs/ t) p10: s/as multiple/multiple/ u) p10: s/layer of hierarchy/hierarchy/ v) p10: s/rpc/input and output parameters of RPC operations/ w) p11: If you put YANG statements in quotes, be consistent: s/choice gives/"choice" statement defines/ s/The feature/The "feature" statement/ s/The "deviation" give/The "deviation" statement gives/ x) p11: s/this problem, rather than ignoring it/this limitation, rather than leaving it to be discovered via runtime errors/ y) p13: s/YANG Technology/YANG Translations/ z) p14: Add a new section "2.X Usage Guidelines" that briefly points to the usage guidelines document and explains that these guidelines must be followed by (IETF) standard data models. A) p15: s/Building YANG-based Solutions/Building NETCONF- and YANG-based Solutions/ B) p16: s/against the data defined/against the data model defined/ C) p16: s/XML payload/XML payload template/ D) p16: s/Addressing Operation Problems/Addressing Operator Requirements/ E) p17: s/a the/the/ F) p17: This text does not make much sense to me: o Network-wide configuration: A standard YANG module can be implemented in all devices, giving a common view of configuration data. I think operators associate with the term "network-wide configuration" the support to run network-wide configuration changes; instead of configuring individual boxes you concentrate on configuring the network. NETCONF kind of supports this kind of network wide configuration changes via the confirmed-commit capability. So perhaps the text should be: o Network-wide configuration: NETCONF supports robust network-wide configuration transactions via the confirmed-commit capability. G) p17: s/as rpc methods/as RPC operations/ H) p17: s/the rpc or/the RPC operation or/ I) p17: s|CLI/Expect|command line interface/ J) p17: s/CLI operations/command line interface/ K) p17: s/should allow simpler modules/enables modules/ L) p17: s/DDL/data definition language/ M) p17: s/UTF-8 data/UTF-8 encoded unicode characters/ N) p17: s/YANG integrated rpc, notification, operational and configuration data to make internal references./YANG integrates RPC operations, notifications, configuration and state data, enabling internal references./ O) p18: "NETCONF runs as an SSH service" is not quite correct since SSH is just one of several possible transports. This might need some rephrasing, e.g. NETCONF runs over transport protocols secured by SSH or TLS, allowing secure communications and authentication using well-trusted technology. The secure transports use the existing key and credential management infrastructure, reducing deployment costs. P) p18: s/new NETCONF RPCs/new RPC operations/ Q) p18: s/RPC's input and output data/input and output parameters of RPC operations/ R) p18: s/Building YANG-based Solutions/Building NETCONF- and YANG-based Solutions/ S) p19: I suggest to restructure section headers as follows (since the text is organized according to the various roles involved in building solutions: 3.3 Building NETCONF- and YANG-based Solutions 3.3.1 Modeler 3.3.2 Reviewer 3.3.3 Device Developer 3.3.4 Application Developer 3.3.4.1 Hard Coded 3.3.4.2 Bottom Up 3.3.4.3 Top Down To keep things simple, I suggest to remove the current section titles 3.6.1 and 3.6.2 - they do not seem to be necessary. T) p19: s/modeler's role constructing a model/modeler defines a data model/ U) p19: I suggest to remove this example: In addition, reviewers can encode review policies in scripts, such as XSLT. A policy that leaf names can't have underscores can be coded as: Error: leaf name contains underscore The reason is that I do not understand how this example works (is this XSLT snippet applied to YIN?) nor is this the only way of doing things nor is this in particular NETCONF or YANG specific (you can always automate some review policies). V) p19: s/, absorbs the zen of the model,// W) p19: Should the section describing the device modeler not mention that the developer should write deviation statements in cases where his implementation puts restrictions on the data model? X) p21: s/modules allows/modules allow/ Y) p22: s/ietf-bgpvpn/bgpvpn/ I do not think we want to encourage people to put ietf- prefixes on data nodes. Z) p22: s/uses either/using either/ 0) p23: s/if it not/if it is not/ 1) p24: I found section 4.2 confusing, mostly because the term deviation seems to be used with a meaning different from YANG's notion of a deviation. I would prefer if this text would talk about features and deviations in the YANG sense. At first reading, I thought "modeled deviations" refers to YANG features but then that later turned out to be not true. It is also not clear what makes an acceptable deviation, an unacceptable deviation, an allowed deviation etc. Are the words allowed and acceptable synonymous? I believe the simplest fix is to remove the bulleted list from section 4.2. 2) p24: s/it a state/it as state/ 3) p26: s/interfaces usually comes/interfaces usually come/ 4) p27: s/provide explicitly/explicitly/ 5) p27: Add the following section: 4.3.3.4 Introduction of Meta-Data Tags The NETCONF protocol might be extended to carry meta-data tags (for example encoded in XML attributes) that identify whether an XML element carries configuration data, operational state data, or statistical data. This approach allows responses to operations to contain mixed data, making it easy for clients to separate configuration data from operational state data. Servers may be allowed to skip over any non-config data supplied by clients in or operations. 6) p27: Does section 4.3 belong into this document? Unfortunately, as long as the WGs have not converged to a solution, I believe it is necessary to keep this text since we right now leave it to the data modelers to figure out what to do. I believe this is actually a bad idea but lets be honest about it. 7) p28: Here is a rewrite of the security considerations: This document discusses an architecture for network management using NETCONF and YANG. It has no security impact on the Internet. /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 Tue May 18 10:22: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 CEA0628C1C4 for ; Tue, 18 May 2010 10:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 YTiZYz-Z20MY for ; Tue, 18 May 2010 10:22:05 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id BBAC13A6A1B for ; Tue, 18 May 2010 10:17:40 -0700 (PDT) Received: from relay2.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay2.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 593A8E214CD; Tue, 18 May 2010 13:17:33 -0400 (EDT) Received: by relay2.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2A841E21652; Tue, 18 May 2010 13:17:33 -0400 (EDT) Message-ID: <4BF2CBB0.2090300@iwl.com> Date: Tue, 18 May 2010 10:17:36 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <20100509.004030.221759968.mbj@tail-f.com> In-Reply-To: <20100509.004030.221759968.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-usage-04 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, 18 May 2010 17:22:07 -0000 Martin Bjorklund wrote: > Hi, > > .... > [any deleted comment was added.] > 4.6. > > should we add that a revision stmt MUST have a description? > > no -- I put MAY have. > ... > 4.7. > > Do we still recommend a *temporary* namespace? > > The examples aren't temporary, are they? > > No -- we still need a value assigned. I added text that any values already in the YANG Module Registry MUST NOT be used. > 4.8. > > Top-level database objects MUST NOT be mandatory. > > I suggest SHOULD NOT. The argument seems to be that mandatory > top-level object can never work. If that was true, they should be > illegal in YANG. But we've had this debate before... > > > No. Our guidelines are based on what a client developers can expect for all NETCONF servers. Since no NETCONF is allowed to boot with an invalid must-stmt, and no server is actually required to provide a value for a mandatory node, a standard YANG data model cannot contain any top-level mandatory nodes. Standard YANG modules can only use YANG mechanisms that MUST be supported by all implementations. > ... > -- > > In my code, I also check that the statements are in the canonical > order, but I don't know if we want to make that a MUST in this > document. > > No -- all YANG tools MUST support arbitrary statement ordering, within the rules of the ABNF. It is too hard to remember the canonical sub-statement order. > > /martin > Andy From andyb@iwl.com Tue May 18 11:43: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 1FF633A6909 for ; Tue, 18 May 2010 11:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_50=0.001, 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 fV2Hx7vr4CR9 for ; Tue, 18 May 2010 11:43:55 -0700 (PDT) Received: from smtp185.iad.emailsrvr.com (smtp185.iad.emailsrvr.com [207.97.245.185]) by core3.amsl.com (Postfix) with ESMTP id CC5003A6884 for ; Tue, 18 May 2010 11:43:55 -0700 (PDT) Received: from relay8.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 37B9E20941A for ; Tue, 18 May 2010 14:43:48 -0400 (EDT) Received: by relay8.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 07FC920378B for ; Tue, 18 May 2010 14:43:47 -0400 (EDT) Message-ID: <4BF2DFE6.7030606@iwl.com> Date: Tue, 18 May 2010 11:43:50 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: netmod@ietf.org References: <20100507074954.GB236@elstar.local> In-Reply-To: <20100507074954.GB236@elstar.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] js review of draft-ietf-netmod-yang-usage-04 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, 18 May 2010 18:43:57 -0000 Juergen Schoenwaelder wrote: > Hi, > ... > [all comments addressed in new version, except...] > - p23: There should be a concrete URL replacing "[YANG tool URL TBD]". > > Not sure what to do about this, because there is no ietf.org tool to point at. I could include this: http://www.netconfcentral.org/run_yangdump but I doubt the IESG wants that, since I cannot insure this URL will be around forever. The plan was to run pyang or yangdump on an ietf.org site, but that requires a lot of programming work. My code is Turbogears-1 based Python and the IETF uses Django, so there has been no progress at all to run yangdump on an ietf.org WEB page. I could remove the section and YANG authors can figure it out on their own without any IETF help. > /js > > Andy From root@core3.amsl.com Tue May 18 13: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 E2FF63A6C36; Tue, 18 May 2010 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100518200001.E2FF63A6C36@core3.amsl.com> Date: Tue, 18 May 2010 13:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-05.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, 18 May 2010 20:00:02 -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-05.txt Pages : 31 Date : 2010-05-18 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-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-18125022.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Tue May 18 14:19: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 8A7633A6AF0 for ; Tue, 18 May 2010 14:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.313 X-Spam-Level: X-Spam-Status: No, score=0.313 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_50=0.001, 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 ut9OA+P5u08m for ; Tue, 18 May 2010 14:19:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 2355F3A6AF1 for ; Tue, 18 May 2010 14:18:58 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F2AF76C07F; Tue, 18 May 2010 23:18:49 +0200 (CEST) Date: Tue, 18 May 2010 23:18:48 +0200 (CEST) Message-Id: <20100518.231848.20400604.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BF2CBB0.2090300@iwl.com> References: <20100509.004030.221759968.mbj@tail-f.com> <4BF2CBB0.2090300@iwl.com> X-Mailer: Mew version 7.0.50 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 draft-ietf-netmod-usage-04 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, 18 May 2010 21:19:23 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > .... > > > [any deleted comment was added.] > > > 4.6. > > > > should we add that a revision stmt MUST have a description? > > > > > > no -- I put MAY have. Ok. > > 4.7. > > > > Do we still recommend a *temporary* namespace? > > > > The examples aren't temporary, are they? > > > > > > > No -- we still need a value assigned. > I added text that any values already in > the YANG Module Registry MUST NOT be used. Ok. > > 4.8. > > > > Top-level database objects MUST NOT be mandatory. > > > > I suggest SHOULD NOT. The argument seems to be that mandatory > > top-level object can never work. If that was true, they should be > > illegal in YANG. But we've had this debate before... > > > > > > > > No. > Our guidelines are based on what a client developers > can expect for all NETCONF servers. Since no NETCONF > is allowed to boot with an invalid must-stmt, and no server > is actually required to provide a value for a mandatory node, > a standard YANG data model cannot contain any top-level > mandatory nodes. > > Standard YANG modules can only use YANG mechanisms > that MUST be supported by all implementations. Yes, that is obvious. But YANG doesn't say that mandatory top-level nodes are optional to support. > > In my code, I also check that the statements are in the canonical > > order, but I don't know if we want to make that a MUST in this > > document. > > > > > > No -- all YANG tools MUST support arbitrary statement ordering, > within the rules of the ABNF. That's not a good argument. All YANG tools MUST support modules w/o a description statement in all typedefs, yet we say that typedefs MUST have a description statement. This rule is there in order to make better data models. Using the canonical statement order makes a module easier to read. (subjective, I know). > It is too hard to remember > the canonical sub-statement order. Fortunately, we have tools to help us remember all the guidelines we define. /martin From andyb@iwl.com Tue May 18 14:50:21 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 DC3203A6A77 for ; Tue, 18 May 2010 14:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_50=0.001, 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 zsEmX3DdYT-4 for ; Tue, 18 May 2010 14:50:20 -0700 (PDT) Received: from smtp135.dfw.emailsrvr.com (smtp135.dfw.emailsrvr.com [67.192.241.135]) by core3.amsl.com (Postfix) with ESMTP id 09ACB3A69B7 for ; Tue, 18 May 2010 14:50:20 -0700 (PDT) Received: from relay23.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 9E5521568984; Tue, 18 May 2010 17:50:12 -0400 (EDT) Received: by relay23.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 66B90156899B; Tue, 18 May 2010 17:50:12 -0400 (EDT) Message-ID: <4BF30B93.8010601@iwl.com> Date: Tue, 18 May 2010 14:50:11 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <20100509.004030.221759968.mbj@tail-f.com> <4BF2CBB0.2090300@iwl.com> <20100518.231848.20400604.mbj@tail-f.com> In-Reply-To: <20100518.231848.20400604.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-usage-04 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, 18 May 2010 21:50:21 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > >> Martin Bjorklund wrote: >> >> .... >> No. >> Our guidelines are based on what a client developers >> can expect for all NETCONF servers. Since no NETCONF >> is allowed to boot with an invalid must-stmt, and no server >> is actually required to provide a value for a mandatory node, >> a standard YANG data model cannot contain any top-level >> mandatory nodes. >> >> Standard YANG modules can only use YANG mechanisms >> that MUST be supported by all implementations. >> > > Yes, that is obvious. But YANG doesn't say that mandatory > top-level nodes are optional to support. > > Yes, just like we say identifier lengths above 64 chars are optional to support. Therefore, standard YANG modules MUST NOT use identifier lengths > 64 chars. Same guideline applies here. >>> In my code, I also check that the statements are in the canonical >>> order, but I don't know if we want to make that a MUST in this >>> document. >>> >>> >>> >> No -- all YANG tools MUST support arbitrary statement ordering, >> within the rules of the ABNF. >> > > That's not a good argument. All YANG tools MUST support modules w/o a > description statement in all typedefs, yet we say that typedefs MUST > have a description statement. This rule is there in order to make > better data models. Using the canonical statement order makes a > module easier to read. (subjective, I know). > > IMO, it is way too fussy to require a rigid statement order. Humans do not remember or agree on any particular 'best canonical order'. We do not have rigid sub-clause ordering like SMIv2. People always hated that. YANG is more flexible than that. We just picked an arbitrary order in the ABNF. If I knew IETFers would have to follow that order then I would have reviewed much more carefully. However, my yangdump program (--format=yang), will pretty-print a YANG module in canonical order. It is not complete yet (e.g., comments and string fragmentation not preserved), but it will be available online soon. (already in the yuma-client package). I don't even want to say SHOULD be in canonical order. That means everyone has to follow it anyway. Another option is to get nit-picky about properties vs. child data-def-stmts. E.g., all 'key', 'unique', 'presence', 'min-elements', 'max-elements',, 'description', 'reference', etc. statements SHOULD be present before any child data-def-stmts. I agree that scattering these properties amongst the child nodes would harm readability. >> It is too hard to remember >> the canonical sub-statement order. >> > > Fortunately, we have tools to help us remember all the guidelines we > define. > > > /martin > > Andy