From mbj@tail-f.com Wed Dec 8 08:31: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 C0EA43A696E for ; Wed, 8 Dec 2010 08:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcDyfC34YmKz for ; Wed, 8 Dec 2010 08:31:55 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E44143A6803 for ; Wed, 8 Dec 2010 08:31:54 -0800 (PST) Received: from localhost (212-181-100-8.customer.telia.com [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id 594B976C211 for ; Wed, 8 Dec 2010 17:33:21 +0100 (CET) Date: Wed, 08 Dec 2010 17:33:19 +0100 (CET) Message-Id: <20101208.173319.37127102.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] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 08 Dec 2010 16:31:57 -0000 Hi, I have posted an I-D for interface configuration: http://www.ietf.org/id/draft-bjorklund-netmod-interfaces-cfg-00.txt Please send comments to the list. /martin A new version of I-D, draft-bjorklund-netmod-interfaces-cfg-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Filename: draft-bjorklund-netmod-interfaces-cfg Revision: 00 Title: A YANG Data Model for Interface Configuration Creation_date: 2010-12-08 WG ID: Independent Submission Number_of_pages: 22 Abstract: This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. The IETF Secretariat. From dromasca@avaya.com Wed Dec 8 09:07: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 B5E933A6817 for ; Wed, 8 Dec 2010 09:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rbItBJB8Cm7a for ; Wed, 8 Dec 2010 09:07:52 -0800 (PST) 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 29F5E3A6808 for ; Wed, 8 Dec 2010 09:07:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsCAHtK/0zGmAcF/2dsb2JhbACUfIMpizp4pw4CmSqFSQSOH4JY X-IronPort-AV: E=Sophos;i="4.59,316,1288584000"; d="scan'208";a="222247761" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Dec 2010 12:09:18 -0500 X-IronPort-AV: E=Sophos;i="4.59,316,1288584000"; d="scan'208";a="552416647" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Dec 2010 12:09:17 -0500 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, 8 Dec 2010 18:09:06 +0100 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401484452@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-linowski-netmod-yang-abstract-04 Thread-Index: Act8C9FOIofpI/MZTfybBASmG4+nKgRSOWNwAmly4kA= References: <80A0822C5E9A4440A5117C2F4CD36A6401484452@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" Cc: s.kuryla@gmail.com, netmod@ietf.org Subject: Re: [netmod] AD review of draft-linowski-netmod-yang-abstract-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: Wed, 08 Dec 2010 17:07:53 -0000 These look OK to me.=20 Please make sure that the explanations that you provided on T2 and T3 get clarified in text.=20 Dan =20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 > Sent: Friday, November 26, 2010 12:34 PM > To: Romascanu, Dan (Dan) > Cc: netmod@ietf.org; s.kuryla@gmail.com; Linowski, Bernd=20 > (EXT-Other - DE) > Subject: RE: AD review of draft-linowski-netmod-yang-abstract-04 >=20 > Hi Dan, >=20 > please find below our attempt to fix the issues you raised. >=20 > Mehmet >=20 >=20 > > -----Original Message----- > > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, November 04, 2010 11:34 AM > > To: bernd.linowski@www.nokiasiemensnetworks.com; Ersue,=20 > Mehmet (NSN -=20 > > DE/Munich); s.kuryla@gmail.com > > Cc: netmod@ietf.org > > Subject: AD review of draft-linowski-netmod-yang-abstract-04 > >=20 > > I have reviewed draft-linowski-netmod-yang-abstract-04. I=20 > think that=20 > > this document is in good shape and I will proceed to sending it to > IETF > > Last Call. Please consider the comments below together with=20 > other IETF=20 > > Last Call comments. > >=20 > > The comments are marked with T for Technical and E for Editorial. > >=20 > >=20 > > T1. As the intended status is Experimental, I believe that=20 > it would be=20 > > useful to add in the introduction some text that describes=20 > the purpose=20 > > of the experiment, and the fact that the language=20 > extensions described=20 > > in this document may become (if the experimental usage succeeds) > either > > a proposed standard or part of a future version of NETCONF. >=20 > We agree, we should add a sentence into the introduction=20 > section stating, e.g.:=20 > "After successful usage this experimental specification can=20 > be republished at IETF either as a proposed standard or as=20 > part of a future version of YANG." > =20 > > T2. section 2.10 - I do not understand the concept of=20 > equimentHolder > - > > is it the same as the vendor or manufacturer of a physical=20 > entity? Why=20 > > is it called differently? >=20 > The idea of making a distinction between "Equipment" and=20 > "EquipmentHolders" > was taken over from SID. To my understanding, an equipment=20 > holder is a piece of equipment with the primary purpose of=20 > containing other equipment. > The description in SID V8 says: > "This class is based on the M.3100 specification, and is a=20 > base class that represents physical objects that are both=20 > manageable as well as able to host, hold, or contain other=20 > physical objects. > Examples of physical objects that can be represented by=20 > instances of this object class are Racks, Chassis, Cards, and Slots." > =20 > > T3. In the example in section 3.3 > >=20 > > F-7786828 > >=20 > > What does a serial number mean for a physical link? >=20 > "serial number" could be the part number of a fiber link cable.=20 > The SID describes serial number as "manufacturer-allocated=20 > part number", so in some cases this might also apply to=20 > physical links. > =20 > >=20 > > T4. In the IANA considerations section: > >=20 > > > Registrant Contact: The NETMOD WG of the IETF. > >=20 > > This is not a WG document. Did the WG formally agree to=20 > take upon this=20 > > role? >=20 > We will note the document authors as Registrant Contact. > =20 > > E1. idnits complains: > >=20 > > =3D=3D Unused Reference: 'RFC5226' is defined on line 1364, but no=20 > > explicit reference was found in the text >=20 > The reference will be deleted. > =20 > > E2. It would be good to mention explicitly relative to what are=20 > > referred the 'improvements' described in section 1.3 >=20 > We will note in section 1.3 that the improvements are=20 > compared to languages without language abstractions. > =20 > > E3. I suggest that you reorder appendices and make the=20 > change log the=20 > > last one - paying attention to make changes in the places where the=20 > > other appendices are referred in the text. As the change=20 > log will be=20 > > taken out of the final version (I assume) this can avoid > complications. >=20 > OK. > =20 > > E4. Section 1.5.1: > >=20 > > > It is > > important to notice that this kind of relationships do not=20 > > mandate > > any particular location of the two connected hardware=20 > instances=20 > > in > > any MIB. > >=20 > > Clarify what 'MIB' means here - MIB module, instance of MIB module? >=20 > It was meant to be the instances of a MIB module. > =20 > > E5. T3. In the example in section 3.3 > >=20 > > F-7786828 > >=20 > > s/serialNumeber/serial/Number/ >=20 > Thanks for the hint. > =20 > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 >=20 >=20 From lhotka@cesnet.cz Thu Dec 9 02:41:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D5F3A68AC for ; Thu, 9 Dec 2010 02:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 bgEWQUsH5rJn for ; Thu, 9 Dec 2010 02:41:12 -0800 (PST) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [IPv6:2001:718:1a02:6::a2]) by core3.amsl.com (Postfix) with ESMTP id 3F14E3A687E for ; Thu, 9 Dec 2010 02:41:11 -0800 (PST) Received: from localhost (stardust-w.lhotkovi.cz [172.29.2.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id D99B03E0072; Thu, 9 Dec 2010 11:42:38 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20101208.173319.37127102.mbj@tail-f.com> References: <20101208.173319.37127102.mbj@tail-f.com> User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Thu, 09 Dec 2010 11:41:23 +0100 Message-ID: <87d3pb9qjw.fsf@stardust-w.lhotkovi.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 10:41:13 -0000 Hi Martin, my question is a follow-up to our private discussion about whether HW interfaces appear automagically in the configuration: In the Ethernet bonding example, the slave Ethernet interfaces have to be manually entered together with their type, location and name, even if I don't want to configure them in any way, right? Because otherwise they won't be in the configuration and "slave-if" leafrefs would point to nowhere. Lada On Wed, 08 Dec 2010 17:33:19 +0100 (CET), Martin Bjorklund wrote: > Hi, > > I have posted an I-D for interface configuration: > http://www.ietf.org/id/draft-bjorklund-netmod-interfaces-cfg-00.txt > > Please send comments to the list. > > > /martin > > > > A new version of I-D, draft-bjorklund-netmod-interfaces-cfg-00.txt has > been successfully submitted by Martin Bjorklund and posted to the IETF > repository. > > Filename: draft-bjorklund-netmod-interfaces-cfg > Revision: 00 > Title: A YANG Data Model for Interface Configuration > Creation_date: 2010-12-08 > WG ID: Independent Submission > Number_of_pages: 22 > > Abstract: > This document defines a YANG data model for the configuration of > network interfaces. It is expected that interface type specific > configuration data models augment the generic interfaces data model > defined in this document. > > The IETF Secretariat. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 9 02:58: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 D91B63A69A6 for ; Thu, 9 Dec 2010 02:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmBJ0U4raV-I for ; Thu, 9 Dec 2010 02:58:08 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 06F8E3A6AD0 for ; Thu, 9 Dec 2010 02:58:08 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B0772616001; Thu, 9 Dec 2010 11:59:35 +0100 (CET) Date: Thu, 09 Dec 2010 11:59:33 +0100 (CET) Message-Id: <20101209.115933.235079090.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <87d3pb9qjw.fsf@stardust-w.lhotkovi.cz> References: <20101208.173319.37127102.mbj@tail-f.com> <87d3pb9qjw.fsf@stardust-w.lhotkovi.cz> 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 Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 10:58:09 -0000 Ladislav Lhotka wrote: > Hi Martin, > > my question is a follow-up to our private discussion about whether HW > interfaces appear automagically in the configuration: In the Ethernet bonding > example, the slave Ethernet interfaces have to be manually entered together > with their type, location and name, even if I don't want to configure them in > any way, right? Because otherwise they won't be in the configuration and > "slave-if" leafrefs would point to nowhere. Correct. But note that this is just an example. It was used to examplify how you can do interface layering with "interface-ref". With this kind of slave-if reference, you get these properties. An alternative design for a bonding interface may be that the bonding interface refers to the physical locations e.g. with a leaf-list of locations. /martin From lhotka@cesnet.cz Thu Dec 9 04:04: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 65F9F28C0F3 for ; Thu, 9 Dec 2010 04:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.675, 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 ovc05csHG1GS for ; Thu, 9 Dec 2010 04:03:51 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 3581D28C0D8 for ; Thu, 9 Dec 2010 04:03:36 -0800 (PST) Received: from stardust-w.lhotkovi.cz (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 978DC2CDE057 for ; Thu, 9 Dec 2010 13:05:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ladislav Lhotka In-Reply-To: <20101209.115933.235079090.mbj@tail-f.com> Date: Thu, 9 Dec 2010 13:05:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101208.173319.37127102.mbj@tail-f.com> <87d3pb9qjw.fsf@stardust-w.lhotkovi.cz> <20101209.115933.235079090.mbj@tail-f.com> To: netmod@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 12:04:05 -0000 On Dec 9, 2010, at 11:59 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi Martin, >>=20 >> my question is a follow-up to our private discussion about whether HW >> interfaces appear automagically in the configuration: In the Ethernet = bonding >> example, the slave Ethernet interfaces have to be manually entered = together >> with their type, location and name, even if I don't want to configure = them in >> any way, right? Because otherwise they won't be in the configuration = and >> "slave-if" leafrefs would point to nowhere. >=20 > Correct. But note that this is just an example. It was used to > examplify how you can do interface layering with "interface-ref". > With this kind of slave-if reference, you get these properties. Yes, but the situation for e.g. VLANs will be similar. For devices with = many physical interfaces this could be annoying. >=20 > An alternative design for a bonding interface may be that the > bonding interface refers to the physical locations e.g. with a > leaf-list of locations. Hmm, physical locations have the same problem - if a physical interface = present at a location is not explicitly configured, the location doesn't = exist in the configuration. What's the difference? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 9 04:13:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A208D28C0EA for ; Thu, 9 Dec 2010 04:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgptiE-gcKch for ; Thu, 9 Dec 2010 04:13:24 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B791428C0EE for ; Thu, 9 Dec 2010 04:13:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A1EC616001; Thu, 9 Dec 2010 13:14:52 +0100 (CET) Date: Thu, 09 Dec 2010 13:14:51 +0100 (CET) Message-Id: <20101209.131451.46789624.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <6A0B4C8B-F151-4F1B-B981-BCD0A27B4FA3@cesnet.cz> References: <87d3pb9qjw.fsf@stardust-w.lhotkovi.cz> <20101209.115933.235079090.mbj@tail-f.com> <6A0B4C8B-F151-4F1B-B981-BCD0A27B4FA3@cesnet.cz> 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 Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 12:13:25 -0000 Ladislav Lhotka wrote: > > On Dec 9, 2010, at 11:59 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Hi Martin, > >> > >> my question is a follow-up to our private discussion about whether HW > >> interfaces appear automagically in the configuration: In the Ethernet > >> bonding > >> example, the slave Ethernet interfaces have to be manually entered together > >> with their type, location and name, even if I don't want to configure them > >> in > >> any way, right? Because otherwise they won't be in the configuration and > >> "slave-if" leafrefs would point to nowhere. > > > > Correct. But note that this is just an example. It was used to > > examplify how you can do interface layering with "interface-ref". > > With this kind of slave-if reference, you get these properties. > > Yes, but the situation for e.g. VLANs will be similar. For devices with many > physical interfaces this could be annoying. For the VLAN I think you will need to actually configure the underlying interface. You might need to set speed / duplex etc. > > An alternative design for a bonding interface may be that the > > bonding interface refers to the physical locations e.g. with a > > leaf-list of locations. > > Hmm, physical locations have the same problem - if a physical interface present > at a location is not explicitly configured, the location doesn't exist in the > configuration. What's the difference? The location is not a leafref; it's just a plain string that tells the system that this confiuration applies to the thing at a certain location. /martin From lhotka@cesnet.cz Thu Dec 9 04:47:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D2628C0F7 for ; Thu, 9 Dec 2010 04:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, NO_RELAYS=-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 zZOQQ39A03A5 for ; Thu, 9 Dec 2010 04:47:15 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 4B30028C0EF for ; Thu, 9 Dec 2010 04:47:15 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7F3252CDE057; Thu, 9 Dec 2010 13:48:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20101209.131451.46789624.mbj@tail-f.com> Date: Thu, 9 Dec 2010 13:48:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d3pb9qjw.fsf@stardust-w.lhotkovi.cz> <20101209.115933.235079090.mbj@tail-f.com> <6A0B4C8B-F151-4F1B-B981-BCD0A27B4FA3@cesnet.cz> <20101209.131451.46789624.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1082) Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 12:47:17 -0000 On Dec 9, 2010, at 1:14 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Dec 9, 2010, at 11:59 AM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> Hi Martin, >>>>=20 >>>> my question is a follow-up to our private discussion about whether = HW >>>> interfaces appear automagically in the configuration: In the = Ethernet >>>> bonding >>>> example, the slave Ethernet interfaces have to be manually entered = together >>>> with their type, location and name, even if I don't want to = configure them >>>> in >>>> any way, right? Because otherwise they won't be in the = configuration and >>>> "slave-if" leafrefs would point to nowhere. >>>=20 >>> Correct. But note that this is just an example. It was used to >>> examplify how you can do interface layering with "interface-ref". >>> With this kind of slave-if reference, you get these properties. >>=20 >> Yes, but the situation for e.g. VLANs will be similar. For devices = with many >> physical interfaces this could be annoying. >=20 > For the VLAN I think you will need to actually configure the > underlying interface. You might need to set speed / duplex etc. No, I can just use system defaults. The problem here is that although an = interface physically exists and may be operational with certain default = parameters, the corresponding config entry in the list of interfaces = doesn't exist and so the defaults that may be specified in the data = model don't apply. In general, I think if an object such as physical = interface exists in reality, it should be possible to refer to it from = configuration. The reference could either point to some state data (but = this unfortunately can't be done with leafrefs) or the object must = somehow appear in the configuration.=20 =20 >=20 >>> An alternative design for a bonding interface may be that the >>> bonding interface refers to the physical locations e.g. with a >>> leaf-list of locations. >>=20 >> Hmm, physical locations have the same problem - if a physical = interface present >> at a location is not explicitly configured, the location doesn't = exist in the >> configuration. What's the difference? >=20 > The location is not a leafref; it's just a plain string that tells the > system that this confiuration applies to the thing at a certain > location. OK, but then the 'must' constraint you have for the slave-if cannot be = used either and the reference cannot be validated in any way. A typo in = an interface name (or location) would then result in a run-time error = rather than a commit-time error. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 9 04:57: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 B8F9E28C0E9 for ; Thu, 9 Dec 2010 04:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaCwurV42YbV for ; Thu, 9 Dec 2010 04:57:38 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A4C0C28C0EF for ; Thu, 9 Dec 2010 04:57:37 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F5F1616001; Thu, 9 Dec 2010 13:59:06 +0100 (CET) Date: Thu, 09 Dec 2010 13:59:04 +0100 (CET) Message-Id: <20101209.135904.248121699.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: References: <6A0B4C8B-F151-4F1B-B981-BCD0A27B4FA3@cesnet.cz> <20101209.131451.46789624.mbj@tail-f.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 Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 12:57:38 -0000 Ladislav Lhotka wrote: > > On Dec 9, 2010, at 1:14 PM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On Dec 9, 2010, at 11:59 AM, Martin Bjorklund wrote: > >> > >>> Ladislav Lhotka wrote: > >>>> Hi Martin, > >>>> > >>>> my question is a follow-up to our private discussion about whether HW > >>>> interfaces appear automagically in the configuration: In the Ethernet > >>>> bonding > >>>> example, the slave Ethernet interfaces have to be manually entered > >>>> together > >>>> with their type, location and name, even if I don't want to configure them > >>>> in > >>>> any way, right? Because otherwise they won't be in the configuration and > >>>> "slave-if" leafrefs would point to nowhere. > >>> > >>> Correct. But note that this is just an example. It was used to > >>> examplify how you can do interface layering with "interface-ref". > >>> With this kind of slave-if reference, you get these properties. > >> > >> Yes, but the situation for e.g. VLANs will be similar. For devices with many > >> physical interfaces this could be annoying. > > > > For the VLAN I think you will need to actually configure the > > underlying interface. You might need to set speed / duplex etc. > > No, I can just use system defaults. The problem here is that although an > interface physically exists and may be operational with certain default > parameters, the corresponding config entry in the list of interfaces doesn't > exist and so the defaults that may be specified in the data model don't > apply. In general, I think if an object such as physical interface exists in > reality, it should be possible to refer to it from configuration. The reference > could either point to some state data (but this unfortunately can't be done > with leafrefs) or the object must somehow appear in the > configuration. I don't think that this necessarily is a problem. If you have many interfaces that you want to use, you need to configure many interfaces. > >>> An alternative design for a bonding interface may be that the > >>> bonding interface refers to the physical locations e.g. with a > >>> leaf-list of locations. > >> > >> Hmm, physical locations have the same problem - if a physical interface > >> present > >> at a location is not explicitly configured, the location doesn't exist in > >> the > >> configuration. What's the difference? > > > > The location is not a leafref; it's just a plain string that tells the > > system that this confiuration applies to the thing at a certain > > location. > > OK, but then the 'must' constraint you have for the slave-if cannot be used > either and the reference cannot be validated in any way. A typo in an interface > name (or location) would then result in a run-time error rather than a > commit-time error. Two observations. First, yes you can enter configuration for an interface that does not yet have the physical hardware in place. This is pre-configuration. Second, it is expected that devices puts constraints on location string, so that you cannot enter any garbage value. /martin From lhotka@cesnet.cz Thu Dec 9 05:14: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 817A128C0FE for ; Thu, 9 Dec 2010 05:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, NO_RELAYS=-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 UCjVbCgZ-zq1 for ; Thu, 9 Dec 2010 05:14:08 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id EA5C528C0F1 for ; Thu, 9 Dec 2010 05:14:07 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 32CD82CDE058; Thu, 9 Dec 2010 14:15:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20101209.135904.248121699.mbj@tail-f.com> Date: Thu, 9 Dec 2010 14:15:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AA04DCE-D2B6-4294-A1A1-A9604E74F93A@cesnet.cz> References: <6A0B4C8B-F151-4F1B-B981-BCD0A27B4FA3@cesnet.cz> <20101209.131451.46789624.mbj@tail-f.com> <20101209.135904.248121699.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1082) Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 13:14:09 -0000 On Dec 9, 2010, at 1:59 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Dec 9, 2010, at 1:14 PM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On Dec 9, 2010, at 11:59 AM, Martin Bjorklund wrote: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> Hi Martin, >>>>>>=20 >>>>>> my question is a follow-up to our private discussion about = whether HW >>>>>> interfaces appear automagically in the configuration: In the = Ethernet >>>>>> bonding >>>>>> example, the slave Ethernet interfaces have to be manually = entered >>>>>> together >>>>>> with their type, location and name, even if I don't want to = configure them >>>>>> in >>>>>> any way, right? Because otherwise they won't be in the = configuration and >>>>>> "slave-if" leafrefs would point to nowhere. >>>>>=20 >>>>> Correct. But note that this is just an example. It was used to >>>>> examplify how you can do interface layering with "interface-ref". >>>>> With this kind of slave-if reference, you get these properties. >>>>=20 >>>> Yes, but the situation for e.g. VLANs will be similar. For devices = with many >>>> physical interfaces this could be annoying. >>>=20 >>> For the VLAN I think you will need to actually configure the >>> underlying interface. You might need to set speed / duplex etc. >>=20 >> No, I can just use system defaults. The problem here is that although = an >> interface physically exists and may be operational with certain = default >> parameters, the corresponding config entry in the list of interfaces = doesn't >> exist and so the defaults that may be specified in the data model = don't >> apply. In general, I think if an object such as physical interface = exists in >> reality, it should be possible to refer to it from configuration. The = reference >> could either point to some state data (but this unfortunately can't = be done >> with leafrefs) or the object must somehow appear in the >> configuration. >=20 > I don't think that this necessarily is a problem. If you have many > interfaces that you want to use, you need to configure many > interfaces. But I don't want to manually copy and paste data that have already been = assigned by the system and cannot be changed. >=20 >=20 >>>>> An alternative design for a bonding interface may be that the >>>>> bonding interface refers to the physical locations e.g. with a >>>>> leaf-list of locations. >>>>=20 >>>> Hmm, physical locations have the same problem - if a physical = interface >>>> present >>>> at a location is not explicitly configured, the location doesn't = exist in >>>> the >>>> configuration. What's the difference? >>>=20 >>> The location is not a leafref; it's just a plain string that tells = the >>> system that this confiuration applies to the thing at a certain >>> location. >>=20 >> OK, but then the 'must' constraint you have for the slave-if cannot = be used >> either and the reference cannot be validated in any way. A typo in an = interface >> name (or location) would then result in a run-time error rather than = a >> commit-time error. >=20 > Two observations. First, yes you can enter configuration for an > interface that does not yet have the physical hardware in place. This > is pre-configuration. Second, it is expected that devices puts I agree that pre-confuration may be useful, but it won't be if a typo in = interface name could be misinterpreted by the system as = pre-configuration and silently ignored. =20 > constraints on location string, so that you cannot enter any garbage > value. But such constraints cannot be expressed in a data model - except in = descriptions. Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Dec 9 05:27:20 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8634328C10F for ; Thu, 9 Dec 2010 05:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.08 X-Spam-Level: X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 On7dZgT5LjMz for ; Thu, 9 Dec 2010 05:27:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECAEB28C10D for ; Thu, 9 Dec 2010 05:27:18 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D9BEC0021; Thu, 9 Dec 2010 14:28:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v4OLMZdKvhfO; Thu, 9 Dec 2010 14:28:47 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27AC4C0016; Thu, 9 Dec 2010 14:28:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0061215E7F88; Thu, 9 Dec 2010 14:28:45 +0100 (CET) Date: Thu, 9 Dec 2010 14:28:45 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20101209132845.GC21227@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <6A0B4C8B-F151-4F1B-B981-BCD0A27B4FA3@cesnet.cz> <20101209.131451.46789624.mbj@tail-f.com> <20101209.135904.248121699.mbj@tail-f.com> <7AA04DCE-D2B6-4294-A1A1-A9604E74F93A@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AA04DCE-D2B6-4294-A1A1-A9604E74F93A@cesnet.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00 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, 09 Dec 2010 13:27:20 -0000 On Thu, Dec 09, 2010 at 02:15:36PM +0100, Ladislav Lhotka wrote: > > constraints on location string, so that you cannot enter any garbage > > value. > > But such constraints cannot be expressed in a data model - except in > descriptions. Descriptions are part of a data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Dec 9 09:02: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 D59F228C129 for ; Thu, 9 Dec 2010 09:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 z-wdVrccj8mc for ; Thu, 9 Dec 2010 09:02:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9DFB528C128 for ; Thu, 9 Dec 2010 09:02:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E295DC0007 for ; Thu, 9 Dec 2010 18:04:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5wYhb+9OxxqE; Thu, 9 Dec 2010 18:04:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56A1FC0005; Thu, 9 Dec 2010 18:04:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F24615E8EBB; Thu, 9 Dec 2010 18:04:02 +0100 (CET) Date: Thu, 9 Dec 2010 18:04:02 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20101209170401.GA23747@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.21 (2010-09-15) Subject: [netmod] ietf 79 draft minutes uploaded 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, 09 Dec 2010 17:02:36 -0000 Hi, I have uploaded draft minutes for the Beijing meeting: http://www.ietf.org/proceedings/79/minutes/netmod.txt Let me know if any corrections are needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@andybierman.com Fri Dec 10 10:36:01 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6949328C10A for ; Fri, 10 Dec 2010 10:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR-DNoE0tJnz for ; Fri, 10 Dec 2010 10:36:00 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by core3.amsl.com (Postfix) with ESMTP id 53EF428C0F9 for ; Fri, 10 Dec 2010 10:36:00 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oBAIbV5m024168 for ; Fri, 10 Dec 2010 13:37:31 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:55451] helo=[192.168.0.14]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id A7/D5-20635-B63720D4; Fri, 10 Dec 2010 13:37:31 -0500 Message-ID: <4D027364.3050409@andybierman.com> Date: Fri, 10 Dec 2010 10:37:24 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00 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, 10 Dec 2010 18:36:01 -0000 Hi, - I like the augment-by-if:type design. - This is a good enough starting point for the WG draft - an example of the interface list is needed; - the relationship between name and location is not clear to implementors; what info goes in what field? - An oper-status config=false leaf needs to be included. This should be an identityref, like if:type. Some basic oper-states should be defined here. A module augmenting the interface list should add its own oper-status identities as needed. - the SNMP coupling is not really explained anywhere; the specific conformance macro should be specified. e.g, is ifAdminStatus == admin-status; How can just 1 leaf out of the ifEntry be shared? Clearly there is more overlap than 1 leaf. - I don't understand why if-index is a leaf-list. Why would a NETCONF interface show up as multiple SNMP interfaces? This raises IF-MIB divergence issues. - what about the ifStackTable? There is no example in the draft that shows the ifStackTable information for the interface list entries - what about ifUp and ifDown notifications? provisioning and other NETCONF app business logic may be interested in these events in order to adjust the config - what about a standard knob to request persistent if-index values? (uh-oh; that's not config true or false; doesn't fit the NETCONF model! Ignore it!) Andy From ietf@andybierman.com Fri Dec 10 10:36: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 6587B28C112 for ; Fri, 10 Dec 2010 10:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02ST+AcTjBaH for ; Fri, 10 Dec 2010 10:36:44 -0800 (PST) Received: from nm11.bullet.mail.ne1.yahoo.com (nm11.bullet.mail.ne1.yahoo.com [98.138.90.74]) by core3.amsl.com (Postfix) with SMTP id 2E65328C10A for ; Fri, 10 Dec 2010 10:36:44 -0800 (PST) Received: from [98.138.90.48] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2010 18:38:13 -0000 Received: from [98.138.89.193] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 10 Dec 2010 18:38:13 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 10 Dec 2010 18:38:13 -0000 X-Yahoo-Newman-Id: 83694.66739.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 12930 invoked from network); 10 Dec 2010 18:38:13 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 10 Dec 2010 10:38:09 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: A97grHYVM1lSk2mXNgV9yrVXxtwKznUERSTGSZVvrzN871g chKDqNzGo3bWjZA0MlM5rT94cBTf7L5NPdyDEGHr8TgCLx8wMaXOvDZHe1ai lKJhSzIdV3S0nmN_pupYu95Ch5myauhjAMzALcK_B3091DRqZBsKrUZe7.Lf JFWrTaWuMsJvJ3DjTfcIvbvjthtDgHFi__6PfZZlaqr9ew8jt6eDP2Lj0lBT qAomXYd_yTW4_IPYutYx0zx6orJ74BWD9ka_R.4pA7YQ3AC6Gr2XEcpRBd0. 56C2TZzKo7T0O2384vqmmaCPwWmqSmcSMER5p3AU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D02738D.40403@andybierman.com> Date: Fri, 10 Dec 2010 10:38:05 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00 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, 10 Dec 2010 18:36:44 -0000 Hi, - I like the augment-by-if:type design. - This is a good enough starting point for the WG draft - an example of the interface list is needed; - the relationship between name and location is not clear to implementors; what info goes in what field? - An oper-status config=false leaf needs to be included. This should be an identityref, like if:type. Some basic oper-states should be defined here. A module augmenting the interface list should add its own oper-status identities as needed. - the SNMP coupling is not really explained anywhere; the specific conformance macro should be specified. e.g, is ifAdminStatus == admin-status; How can just 1 leaf out of the ifEntry be shared? Clearly there is more overlap than 1 leaf. - I don't understand why if-index is a leaf-list. Why would a NETCONF interface show up as multiple SNMP interfaces? This raises IF-MIB divergence issues. - what about the ifStackTable? There is no example in the draft that shows the ifStackTable information for the interface list entries - what about ifUp and ifDown notifications? provisioning and other NETCONF app business logic may be interested in these events in order to adjust the config - what about a standard knob to request persistent if-index values? (uh-oh; that's not config true or false; doesn't fit the NETCONF model! Ignore it!) Andy From j.schoenwaelder@jacobs-university.de Fri Dec 10 12:56:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53DEA3A6BB1 for ; Fri, 10 Dec 2010 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.09 X-Spam-Level: X-Spam-Status: No, score=-103.09 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 mliL4cpFjuOv for ; Fri, 10 Dec 2010 12:56:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4F40E3A6BAF for ; Fri, 10 Dec 2010 12:56:39 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A945C001B for ; Fri, 10 Dec 2010 21:58:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id on1VnPUdbwzk; Fri, 10 Dec 2010 21:58:10 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75A78C0014; Fri, 10 Dec 2010 21:58:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5D9F815EAD6B; Fri, 10 Dec 2010 21:58:05 +0100 (CET) Date: Fri, 10 Dec 2010 21:58:05 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20101210205805.GD975@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.21 (2010-09-15) Subject: [netmod] interfaces 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, 10 Dec 2010 20:56:40 -0000 Hi, Martin's ID assumes that interface type specific modules introduce a mechanism to layer a logical interface on some other interface. The bonding example introduces a slave-if list (with additional constraints). The vlan example introduces a base-interface leaf (with additional constraints). I am wondering whether the layering mechanism, that is how I identify the underlying interface(s), should not be a generic interface feature. As it is now, it is not possible to generically analyze/display the interface layering since for each logical interface type things are done in a different way. /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 Dec 10 13:00: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 DFBD83A6CC3 for ; Fri, 10 Dec 2010 13:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Ov7RpZynRS9O for ; Fri, 10 Dec 2010 13:00:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0F30C3A6BB1 for ; Fri, 10 Dec 2010 13:00:26 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE378C001B; Fri, 10 Dec 2010 22:01:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aPI0jDAaWkvP; Fri, 10 Dec 2010 22:01:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3793EC0014; Fri, 10 Dec 2010 22:01:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EA74915EADBF; Fri, 10 Dec 2010 22:01:52 +0100 (CET) Date: Fri, 10 Dec 2010 22:01:52 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20101210210152.GA1245@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4D027364.3050409@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D027364.3050409@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00 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, 10 Dec 2010 21:00:27 -0000 On Fri, Dec 10, 2010 at 10:37:24AM -0800, Andy Bierman wrote: > - I don't understand why if-index is a leaf-list. > Why would a NETCONF interface show up as multiple SNMP interfaces? > This raises IF-MIB divergence issues. Some boxes have really interesting interface stacks (consider an ADSL interface for example which on some boxes involves several ATM sub-interfaces). While configuring an interface, you might actually create multiple instances in the ifTable. The question then is whether it is sufficient to refer to one of them or all of them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Dec 10 14:04: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 E64FA28C13B for ; Fri, 10 Dec 2010 14:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-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 mcYcHD7uboQ6 for ; Fri, 10 Dec 2010 14:04:14 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A62BC28C133 for ; Fri, 10 Dec 2010 14:04:13 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id A060C2CDE058; Fri, 10 Dec 2010 23:05:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20101210205805.GD975@elstar.local> Date: Fri, 10 Dec 2010 23:05:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7751C616-79E6-4C02-A3F1-02E41D0DF1EA@cesnet.cz> References: <20101210205805.GD975@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) Cc: netmod@ietf.org Subject: Re: [netmod] interfaces 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, 10 Dec 2010 22:04:15 -0000 On Dec 10, 2010, at 9:58 PM, Juergen Schoenwaelder wrote: > Hi, >=20 > Martin's ID assumes > that interface type specific modules introduce a mechanism to layer a > logical interface on some other interface. The bonding example > introduces a slave-if list (with additional constraints). The vlan > example introduces a base-interface leaf (with additional > constraints). I am wondering whether the layering mechanism, that is > how I identify the underlying interface(s), should not be a generic > interface feature. As it is now, it is not possible to generically > analyze/display the interface layering since for each logical > interface type things are done in a different way. It would make sense to use the same referring leaf if the relationship = between the adjacent layers is identical so that, for instance, an IP = interface could have a "link-interface" leaf that can point to an = Ethernet, VLAN, PPP or any other interface. For the bonding and VLAN = cases, the function of the underlying interfaces substantially differs, = so I would keep different names. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Dec 10 14:33:18 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 0056A28C158 for ; Fri, 10 Dec 2010 14:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_24=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA5xjXzWbSyL for ; Fri, 10 Dec 2010 14:33:15 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 609B028C0F3 for ; Fri, 10 Dec 2010 14:33:15 -0800 (PST) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BBB6616001; Fri, 10 Dec 2010 23:34:46 +0100 (CET) Date: Fri, 10 Dec 2010 23:34:45 +0100 (CET) Message-Id: <20101210.233445.44549979.mbj@tail-f.com> To: andy@andybierman.com From: Martin Bjorklund In-Reply-To: <4D027364.3050409@andybierman.com> References: <4D027364.3050409@andybierman.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 Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00 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, 10 Dec 2010 22:33:18 -0000 Hi, Andy Bierman wrote: > - an example of the interface list is needed; Ok, I will add that. > - the relationship between name and location is not clear > to implementors; what info goes in what field? The idea is that name is arbitrary, i.e. any name that the operator chooses. This could be a logical name like "acme-1" or reference to a location like "fe-1/0/0". But it is up to the operator. The location, however, is not arbitrary; it is a string that refers to a physical location. The format of this string is device-specific. > - An oper-status config=false leaf needs to be included. > This should be an identityref, like if:type. > Some basic oper-states should be defined here. > A module augmenting the interface list should add > its own oper-status identities as needed. The current approach is that this module be confguration only, plus the mapping to ifIndex. The ifTable then contains all the operational state and counters. It can be accessed over SNMP, or, once we have the std SMIv2 -> YANG mapping in place, over NETCONF. > - the SNMP coupling is not really explained anywhere; > the specific conformance macro should be specified. > e.g, is ifAdminStatus == admin-status; The DESCRIPTION of ifAdminStatus says: "The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state)." The if-admin status object is the "configuration information". I have a FIXME that needs to be resolved. Can we say that if ifAdminStatus is changed, that also means that if-admin-status is changed, i.e. are these two objects really the same? If so, ifAdminStatus really modifies the configuration. How does that interact with the candidate? OTOH, if ifAdminStatus is not config, but rather it changes the (volatile) operational state, is that universally true? > How can just 1 leaf out of the > ifEntry be shared? Clearly there is more overlap than 1 leaf. See above. The idea was that just enough information is present to map to ifTable. There are some other read-write objects in IF-MIB that we can discuss; ifLinkUpDownTrapEnable: maybe we should include this one ifPromiscuousMode: I don't think this object should be present in the config ifAlias: I'm not sure it is needed, since we have an arbitrary name. > - I don't understand why if-index is a leaf-list. > Why would a NETCONF interface show up as multiple SNMP interfaces? > This raises IF-MIB divergence issues. The reason is that IF-MIB allows for this. The ifName DESCRIPTION says: The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. [...] If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. So ifName allows the case that one named interface is mapped to several entries in ifTable. This said, maybe we could say that if-index is a single leaf, and that it maps to the top-level ifTable entry for this configured interface. But can we be sure that such a top-level entry always exists? Can one configured interface be represented as two ifTable entries on the same level? By using a leaf-list, this decision is up to the media-specific modules. Many will map 1-1 to ifTable, so in that case this leaf-list will contain one single value. > - what about the ifStackTable? There is no example in the draft that shows > the ifStackTable information for the interface list entries See above. Use ifStackTable for this. I wanted to limit the scope to configuration. > - what about ifUp and ifDown notifications? > provisioning and other NETCONF app business logic may be interested > in these events in order to adjust the config Philosophical question: Should we do NETCONF versions of all interesting SNMP notifications? In this particualr case we might do "better" than the current SMIv2 versions, but maybe we should think about a generic mechanism instead? /martin From j.schoenwaelder@jacobs-university.de Mon Dec 20 15:44:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B151F3A681F for ; Mon, 20 Dec 2010 15:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 6Ub01GI8-YBS for ; Mon, 20 Dec 2010 15:44:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 420043A6834 for ; Mon, 20 Dec 2010 15:44:57 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51569C0009 for ; Tue, 21 Dec 2010 00:46:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PyQFOddrV-Ft; Tue, 21 Dec 2010 00:46:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DC32C0008; Tue, 21 Dec 2010 00:46:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81B1416030CA; Tue, 21 Dec 2010 00:46:44 +0100 (CET) Date: Tue, 21 Dec 2010 00:46:44 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20101220234644.GA31859@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.21 (2010-09-15) Subject: [netmod] Document Action: 'Extending YANG with Language Abstractions' to Experimental RFC (draft-linowski-netmod-yang-abstract-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: Mon, 20 Dec 2010 23:44:58 -0000 Hi, this might be of interest for the NETMOD working group as well. /js ----- Forwarded message from The IESG ----- Date: Mon, 20 Dec 2010 12:44:34 -0800 From: The IESG To: IETF-Announce CC: Internet Architecture Board , RFC Editor Subject: Document Action: 'Extending YANG with Language Abstractions' to Experimental RFC (draft-linowski-netmod-yang-abstract-05.txt) Message-ID: <20101220204434.19900.67583.idtracker@localhost> The IESG has approved the following document: - 'Extending YANG with Language Abstractions' (draft-linowski-netmod-yang-abstract-05.txt) as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-linowski-netmod-yang-abstract/ Technical Summary YANG - the NETCONF Data Modeling Language - supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. The document defines extensions for the modeling language YANG as new language statements, which introduce language abstractions to improve the model extensibility and reuse. A model example from an actual network management system is given to highlight the value of proposed language extensions, especially class inheritance and recursiveness. The draft introduces object-oriented language features like class inheritance and recursiveness and enables high-level modeling and mapping of YANG models seamlessly to available information models like TM Forum SID. As such the draft can enable easy adoption of YANG language and YANG standard moduls by other SDOs (using UML as modeling language) as well as using industry information models as a basis for further detailed modeling and YANG module development. Working Group Summary The draft has been originally submitted as an individual draft to the NETMOD WG addressing the gap for language abstractions noted in NETMOD WG charter as an area of future work. After finalizing YANG language specification the NETMOD WG decided to focus on YANG module development rather than starting additional work for language extensions. Based on the feedback of the WG the draft specifies valuable extensions to the YANG language, thus WG members proposed to publish the document as an Experimental RFC. The draft might become a candidate for proposed standard once an IETF WG starts working on an update of the YANG language specification as YANG 2.0. Document Quality Several YANG experts from NETMOD WG and one expert from IPFIX WG reviewed different versions of the draft. The document has been reviewed by the editor of the YANG language specification Martin Bjorlund to make sure the defined YANG extensions do not conflict with the YANG language. The language extensions defined in the document have been implemented with two open source tools with different code base. These tools have been used to validate the model examples through the document. Personnel Mehmet Ersue is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. RFC Editor Note Abstract: OLD: memo suggests to enhance NEW: memo suggests enhancing Section 1: OLD: After successful usage this experimental specification can be republished at IETF as a proposed standard possibly as part of a future version of YANG. NEW: If this experimental specification results in successful usage, it is possible that the language extension defined herein could be updated to incorporate implementation and deployment experience, then pursued on the standards track, perhaps as part of a future version of YANG. Section 1.2: OLD: 1.2. Motivation NEW: 1.2. Motivation Following are non-exhaustive motivation examples highlighting usage scenarios for language abstractions. OLD: (e.g. TM Forum SID) NEW: (e.g. TM Forum SID [SID V8]) Section 2.9: OLD: file "ietf-complex-types@2010-10-05.yang" NEW: file "ietf-complex-types@2010-12-10.yang" OLD: "Editor: Bernd Linowski NEW: "Editor: Bernd Linowski Section 4: OLD: Registrant Contact: See the 'Author's Addresses' section of this document. NEW: Registrant Contact: Bernd Linowski (bernd.linowski.ext@nsn.com) Mehmet Ersue (mehmet.ersue@nsn.com) Siarhei Kuryla (s.kuryla@gmail.com) Authors' Addresses: OLD: EMail: bernd.linowski@ext.nsn.com NEW: EMail: bernd.linowski.ext@nsn.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- From kwatsen@juniper.net Tue Dec 28 15:59: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 AE6623A6802 for ; Tue, 28 Dec 2010 15:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 ba-m6KBjEREk for ; Tue, 28 Dec 2010 15:59:25 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 7C2F03A680D for ; Tue, 28 Dec 2010 15:59:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTRp6WrtfpI+WMGhxuQOLkmrAPHTJk4r7@postini.com; Tue, 28 Dec 2010 16:01:31 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 28 Dec 2010 15:59:19 -0800 From: Kent Watsen To: "netmod@ietf.org" Date: Tue, 28 Dec 2010 15:59:16 -0800 Thread-Topic: how to know which module revision an RPC is for? Thread-Index: Acum6zwPVNtEQlOFTSmFB8lzGKKh/w== Message-ID: <84600D05C20FF943918238042D7670FD374562B427@EMBX01-HQ.jnpr.net> 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_84600D05C20FF943918238042D7670FD374562B427EMBX01HQjnprn_" MIME-Version: 1.0 Subject: [netmod] how to know which module revision an RPC is for? 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, 28 Dec 2010 23:59:30 -0000 --_000_84600D05C20FF943918238042D7670FD374562B427EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry if this has been answered elsewhere, but a search didn't reveal it... Section 4.2.9 of draft-ietf-netmod-yang-13 provides an example whereby an "= rpc" statement results in the XML acmefw-2.3 The image acmefw-2.3 is being installed. Note that only the namespace is passed (http://acme.example.com/system) And section 5.6.4.1. says that "A server MUST advertise all revisions of al= l modules it implements". Servers indicate the names of supported modules via the message. Module namespaces are encoded as the base URI in the capability string, and the module name is encoded as the "module" parameter to the base URI. A server MUST advertise all revisions of all modules it implements. For example, this message advertises one module "syslog". http://example.com/syslog?module=3Dsyslog&revision=3D2008-04-01 So what if a server implements more than one revision of a module, each def= ining the same rpc from, but with only a slight variation in output. Since= there is no ability for the client to indicate which module revision their= RPC is using, how would the server know which response to send? Thanks, Kent --_000_84600D05C20FF943918238042D7670FD374562B427EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Sorry if this has been answered = elsewhere, but a search didn’t reveal it…
 
 
 
Section 4.2.9 of draft-ietf-netm= od-yang-13 provides an example whereby an “rpc” statement resul= ts in the XML
 
   <rpc message-i= d=3D"101"
     &n= bsp;    xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= 0">
     &n= bsp; <activate-software-image xmlns=3D"http://acme.example.com/syst= em">
     &n= bsp;   <image-name>acmefw-2.3</image-name>
      &= lt;/activate-software-image>
     </rp= c>
 
     <rpc= -reply message-id=3D"101"
     &n= bsp;          xmlns=3D"ur= n:ietf:params:xml:ns:netconf:base:1.0">
     &n= bsp; <status xmlns=3D"http://acme.example.com/system">
     &n= bsp;   The image acmefw-2.3 is being installed.
     &n= bsp; </status>
     </rp= c-reply>
 
 
Note that only the namespace is = passed (http://acme.example.com/= system)
 
 
And section 5.6.4.1. says that &= #8220;A server MUST advertise all revisions of all modules it implements= 221;.
 
 
   Servers indicate th= e names of supported modules via the <hello>
   message.  Modu= le namespaces are encoded as the base URI in the
   capability string, = and the module name is encoded as the "module"
   parameter to the ba= se URI.
 
   A server MUST adver= tise all revisions of all modules it implements.
 
   For example, this &= lt;hello> message advertises one module "syslog".
 
     <hel= lo xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
     &n= bsp; <capability>
     &n= bsp; </capability>
     </he= llo>
 
 
So what if a server implements m= ore than one revision of a module, each defining the same rpc from, but wit= h only a slight variation in output.  Since there is no ability for th= e client to indicate which module revision their RPC is using, how would the server know which response to send?
 
 
Thanks,
Kent
 
 
 
 
 
 
 --_000_84600D05C20FF943918238042D7670FD374562B427EMBX01HQjnprn_-- From ietf@andybierman.com Wed Dec 29 09:53:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CBC3A67D6 for ; Wed, 29 Dec 2010 09:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI7+Xd28LTTz for ; Wed, 29 Dec 2010 09:53:54 -0800 (PST) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by core3.amsl.com (Postfix) with SMTP id DA9803A6860 for ; Wed, 29 Dec 2010 09:53:52 -0800 (PST) Received: from [98.138.90.53] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 29 Dec 2010 17:55:55 -0000 Received: from [98.138.88.238] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 29 Dec 2010 17:55:55 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 29 Dec 2010 17:55:55 -0000 X-Yahoo-Newman-Id: 441977.51420.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 50713 invoked from network); 29 Dec 2010 17:55:55 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.ne1.yahoo.com with SMTP; 29 Dec 2010 09:55:52 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: BTLP2lgVM1mjuhfPTqfJd3paWQUkKCb6M2nObOwnRvG6_4. gm4MPpKz_0ZQHI_m625GavHLQA7iAEhnRa5m3Sxuz5zNlXwGfbqZn7NjJ8Ft QpKwFRkXZW2JRagrqxAO5spQcc4wRtCDyJEvNIo8P3XIETxpTKYM1qnnaWz. nLC58hTWlHUjaMHMK0XWNqXKZC_hULq3MW0shka45Ck_du7M5xVajsWQ.mdQ SFYQiArvNv3tGV76fHjorkBUXyMyRUWNXl.XYNxMSB_Fdh7KXZ9.JjNAR0qJ sHlh_giYZPDJvr0loEr_yEuLhtigsEL3k2S.iKQk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D1B7629.2000807@andybierman.com> Date: Wed, 29 Dec 2010 09:55:53 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD374562B427@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD374562B427@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 29 Dec 2010 17:53:55 -0000 On 12/28/2010 03:59 PM, Kent Watsen wrote: > Sorry if this has been answered elsewhere, but a search didn’t reveal it… > Section 4.2.9 of draft-ietf-netmod-yang-13 provides an example whereby an “rpc” statement results in the XML > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > acmefw-2.3 > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > The image acmefw-2.3 is being installed. > > > Note that only the namespace is passed (http://acme.example.com/system) You can add a leaf to the input for the client to request a specific version. Normally, a server implements just the most recent version. Andy > And section 5.6.4.1. says that “A server MUST advertise all revisions of all modules it implements”. > Servers indicate the names of supported modules via the > message. Module namespaces are encoded as the base URI in the > capability string, and the module name is encoded as the "module" > parameter to the base URI. > A server MUST advertise all revisions of all modules it implements. > For example, this message advertises one module "syslog". > > > http://example.com/syslog?module=syslog&revision=2008-04-01 > > > So what if a server implements more than one revision of a module, each defining the same rpc from, but with only a slight variation in output. Since there is no ability for the client to indicate > which module revision their RPC is using, how would the server know which response to send? > Thanks, > Kent > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From kwatsen@juniper.net Wed Dec 29 12:05: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 3C67D28B797 for ; Wed, 29 Dec 2010 12:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdAx5hOZI2fX for ; Wed, 29 Dec 2010 12:05:58 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 50F473A687F for ; Wed, 29 Dec 2010 12:05:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTRuVIySpcUW5Q6yWrXrnGuf4UqEOMNZf@postini.com; Wed, 29 Dec 2010 12:08:04 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 29 Dec 2010 12:04:41 -0800 From: Kent Watsen To: Andy Bierman Date: Wed, 29 Dec 2010 12:04:37 -0800 Thread-Topic: [netmod] how to know which module revision an RPC is for? Thread-Index: AcungYLvibP7+/OUQyiyXuXYcl/DJwADgycQ Message-ID: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD374562B427@EMBX01-HQ.jnpr.net> <4D1B7629.2000807@andybierman.com> In-Reply-To: <4D1B7629.2000807@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 29 Dec 2010 20:05:59 -0000 Hi Andy, > You can add a leaf to the input for the client to request > a specific version. I don't understand, can you provide an example? Oh, wait, do you mean tha= t the payload of the RPC itself would have a element? - ugh, do= you want to define that in the RFC? It seems that augmenting the xmlns m= ight be more elegant, perhaps something like: "> acmefw-2.3 Or maybe: "> acmefw-2.3 Or maybe even: .xsd"> acmefw-2.3 > Normally, a server implements just the most recent version. But what if the revision breaks compatibility with existing clients? The = current YANG spec does not constrain revisions to be backwards compatible o= r provide rules enabling clients to skip over unrecognized fields. An appl= ication coded to only support the previous revision will not know how to in= teroperate with a device that only advertises the new/current revision. It would be good if we could allow devices to support multiple revisions si= multaneously (using something like one of the proposals above) as well as s= ome kind of deprecation/expiration policy to allow clients enough time to g= racefully migrate to the new revision before the device drops support for t= he legacy revisions entirely. What do you think? Thanks, Kent From phil@juniper.net Wed Dec 29 12:14:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A69E3A67B1 for ; Wed, 29 Dec 2010 12:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 PHwRCD0wWAmn for ; Wed, 29 Dec 2010 12:14:36 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id B21503A6875 for ; Wed, 29 Dec 2010 12:14:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTRuXKU+uz2XTx/a5ymQ6mOn/a5Ozlu55@postini.com; Wed, 29 Dec 2010 12:16:42 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 29 Dec 2010 12:15:28 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id oBTKFSU76799; Wed, 29 Dec 2010 12:15:28 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id oBTJrOH8038698; Wed, 29 Dec 2010 19:53:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201012291953.oBTJrOH8038698@idle.juniper.net> To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> Date: Wed, 29 Dec 2010 14:53:24 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 29 Dec 2010 20:14:37 -0000 Kent Watsen writes: >But what if the revision breaks compatibility with existing clients? The current YANG >spec does not constrain revisions to be backwards compatible or provide rules enabling c >lients to skip over unrecognized fields. An application coded to only support the previ >ous revision will not know how to interoperate with a device that only advertises the ne >w/current revision. A YANG module is a contract, so breaking between revisions is a bug in the new revision. If the module adds new elements, then the old clients will ignore them. If the new module deprecates elements, then both sides can ignore them. If the new module, say, removes elements that were previously mandatory, then you have a bug in the new revision. Thanks, Phil From ietf@andybierman.com Wed Dec 29 12:37:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768E73A687D for ; Wed, 29 Dec 2010 12:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 7adp0Xph6Ph4 for ; Wed, 29 Dec 2010 12:37:45 -0800 (PST) Received: from nm28-vm0.bullet.mail.ac4.yahoo.com (nm28-vm0.bullet.mail.ac4.yahoo.com [98.139.52.246]) by core3.amsl.com (Postfix) with SMTP id 3FA403A687C for ; Wed, 29 Dec 2010 12:37:44 -0800 (PST) Received: from [98.139.52.197] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 29 Dec 2010 20:39:47 -0000 Received: from [98.139.52.134] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 29 Dec 2010 20:39:47 -0000 Received: from [127.0.0.1] by omp1017.mail.ac4.yahoo.com with NNFMP; 29 Dec 2010 20:39:47 -0000 X-Yahoo-Newman-Id: 380045.11864.bm@omp1017.mail.ac4.yahoo.com Received: (qmail 71113 invoked from network); 29 Dec 2010 20:39:47 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 29 Dec 2010 12:39:44 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: xZLyfK0VM1mR6EYUyrBK4H5I6LW8OZ5MG7e8PiQ97Y4w0DW 46Xk1cLSSYKPFirRCSslsg2PRsWLJAVv3Z0uNLXvt0os9NwrGLZhVHLJT7T6 1X3kawiCZAPZNiENCTFw7wM3PbbuPJ9sBmwViMZvLH6EKZuHnhrtI_NLFvrp 8PDtCmoQmO8JEhFXnrxGFAmFgoTGUPI6IQzpbA.aHDheFfF5xrfsmoTL4B0F ecvAQxHnO_d4s8AV_FAJ3Ch29SA34UdbPLQZuKINQC.4ikQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D1B9C92.4030606@andybierman.com> Date: Wed, 29 Dec 2010 12:39:46 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD374562B427@EMBX01-HQ.jnpr.net> <4D1B7629.2000807@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 29 Dec 2010 20:37:46 -0000 On 12/29/2010 12:04 PM, Kent Watsen wrote: > Hi Andy, > > >> You can add a leaf to the input for the client to request >> a specific version. > > I don't understand, can you provide an example? Oh, wait, do you mean that the payload of the RPC itself would have a element? - ugh, do you want to define that in the RFC? It seems that augmenting the xmlns might be more elegant, perhaps something like: > > > > acmefw-2.3 > > > > Or maybe: > > > > acmefw-2.3 > > > > Or maybe even: > > > > acmefw-2.3 > > > > > >> Normally, a server implements just the most recent version. > > But what if the revision breaks compatibility with existing clients? The current YANG spec does not constrain revisions to be backwards compatible or provide rules enabling clients to skip over unrecognized fields. An application coded to only support the previous revision will not know how to interoperate with a device that only advertises the new/current revision. > > It would be good if we could allow devices to support multiple revisions simultaneously (using something like one of the proposals above) as well as some kind of deprecation/expiration policy to allow clients enough time to gracefully migrate to the new revision before the device drops support for the legacy revisions entirely. > > What do you think? This is not something for the standard to worry about. Usually a server image implements a particular revision of a module, and advertises just that revision. There are corner cases where module A and B both import C, but different versions of C, (e.g. acme-types.yang), so there are 2 versions of C advertised by the server. You have a different use-case. Applications are coded to check for different data structures in the output, based on the module version. You want to let the client pick the output version, so the YANG versions align properly. You do not need to do this if newer module versions just add to the output. Optional nodes that go away will look like an unsupported feature. You could use 'anyxml' in the output, instead of a detailed YANG model. In this case knowing the exact module version is needed. This is supported by adding an input parameter, like in your examples. NETCONF/YANG doesn't really support what you want without changing the XML namespace each module revision. Andy > > > Thanks, > Kent > > > > From kwatsen@juniper.net Wed Dec 29 15:59:29 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4CE3A68F7 for ; Wed, 29 Dec 2010 15:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+OP2XMXuKRn for ; Wed, 29 Dec 2010 15:59:28 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 38EAB3A68F5 for ; Wed, 29 Dec 2010 15:59:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTRvL3TeoJJ4rbLYc7NOZfqy97kgqDA26@postini.com; Wed, 29 Dec 2010 16:01:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 29 Dec 2010 16:01:22 -0800 From: Kent Watsen To: Phil Shafer Date: Wed, 29 Dec 2010 16:01:20 -0800 Thread-Topic: [netmod] how to know which module revision an RPC is for? Thread-Index: AcunlQGZCFoxrcISQUWP9z4mWqP1MwACpcxA Message-ID: <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> In-Reply-To: <201012291953.oBTJrOH8038698@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 29 Dec 2010 23:59:29 -0000 > A YANG module is a contract, so breaking between revisions is a bug > in the new revision. If the module adds new elements, then the old > clients will ignore them. If the new module deprecates elements, > then both sides can ignore them. If the new module, say, removes > elements that were previously mandatory, then you have a bug in the > new revision. The "Updating a Module" section (http://tools.ietf.org/html/rfc6020#section= -10) supports most of this. However, I find the statement: "However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification." to be in conflict with the ability to obsolete nodes using the status state= ment (http://tools.ietf.org/html/rfc6020#section-7.19.2), as a server could= cause interoperability problems if it ever stops supporting RPC elements o= r stops returning RPC-Reply elements. In fact, it seems that the current d= efinition requires: For RPCs: - the server MUST support a deprecated nodes forever - the server can never obsolete a node For RPC Replies: - the server MUST continue to return deprecated nodes forever - the server can never obsolete a node Is this true? Perhaps I'm missing something, as I don't truly understand the purpose of t= he "obsolete" status as it seems that 1) existing implementations can never= obsolete a node (see above) and 2) new implementations wouldn't even bothe= r to support deprecated nodes, so again, no need for an obsolete status. As I abhor the idea of needing to forever support nodes, it seems that a fi= x would be to enable a deprecated node to specify a date after which it can= be considered obsolete, not to be less than one year from the module's rev= ision date, so as to allow clients enough time to gracefully migrate off of= the deprecated node prior to its support being dropped entirely. What do = you think? Anyway, back to my original question, the conclusion appears to be: - it is OK for the server to not know what module-revision a client used = to format its RPC message as the server must forever support previous versi= ons of the RPC. - it is OK for the client to not be coded to support the current module-r= evision a server supports as the server must continue to return all previou= sly returned fields and also because the client can safely ignore any unrec= ognized fields. - the ability for the server to return the list of revisions it supports = is valuable in that it allows new implementations can indicate support for = just the current version and hence never have to support previously depreca= ted nodes. Thanks, Kent From ietf@andybierman.com Wed Dec 29 16:48: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 CC71B28C12C for ; Wed, 29 Dec 2010 16:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 tNkuVTBn4m6n for ; Wed, 29 Dec 2010 16:48:32 -0800 (PST) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by core3.amsl.com (Postfix) with SMTP id 6B79928C125 for ; Wed, 29 Dec 2010 16:48:32 -0800 (PST) Received: from [98.139.52.189] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 30 Dec 2010 00:50:34 -0000 Received: from [98.139.52.177] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 30 Dec 2010 00:50:34 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 30 Dec 2010 00:50:34 -0000 X-Yahoo-Newman-Id: 572094.7819.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 63449 invoked from network); 30 Dec 2010 00:50:34 -0000 Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 29 Dec 2010 16:50:30 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Qjdy3XsVM1k2wByPVrY.nql7ag_GBhUYp9qrgOwMLeBlvNN vBIeZAUFnWyfj8dgx90V8It9Eccfsa81GhRPjGA3o1CekE4X2CYuk4bMsYKW LMOIRE39Ox3G.Fez.zeTNnhEvL2mFXOK8P3HlorYXioAOfZLtbGSaGd0Niax gKCFVtGiA27LXLKxxW4t_5wX2Yy0D9ysXIuwBkmigWg8xerb6xPIIV1_S2eQ AbtsVDHb7ye0aqE2IVVFs0t2PKl84KegqUWePMspvjniCE9Q0o58TjIZGp5J 2kLBpcuaT3xUyj49Y X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D1BD759.1090207@andybierman.com> Date: Wed, 29 Dec 2010 16:50:33 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 30 Dec 2010 00:48:35 -0000 On 12/29/2010 04:01 PM, Kent Watsen wrote: >> A YANG module is a contract, so breaking between revisions is a bug in the new revision. If the module adds new elements, then the old clients will ignore them. If the new module deprecates >> elements, then both sides can ignore them. If the new module, say, removes elements that were previously mandatory, then you have a bug in the new revision. > > > The "Updating a Module" section (http://tools.ietf.org/html/rfc6020#section-10) supports most of this. However, I find the statement: > > "However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification." > > to be in conflict with the ability to obsolete nodes using the status statement (http://tools.ietf.org/html/rfc6020#section-7.19.2), as a server could cause interoperability problems if it ever > stops supporting RPC elements or stops returning RPC-Reply elements. In fact, it seems that the current definition requires: > > For RPCs: - the server MUST support a deprecated nodes forever - the server can never obsolete a node > > For RPC Replies: - the server MUST continue to return deprecated nodes forever - the server can never obsolete a node > > Is this true? > > > Perhaps I'm missing something, as I don't truly understand the purpose of the "obsolete" status as it seems that 1) existing implementations can never obsolete a node (see above) and 2) new > implementations wouldn't even bother to support deprecated nodes, so again, no need for an obsolete status. > > As I abhor the idea of needing to forever support nodes, it seems that a fix would be to enable a deprecated node to specify a date after which it can be considered obsolete, not to be less than > one year from the module's revision date, so as to allow clients enough time to gracefully migrate off of the deprecated node prior to its support being dropped entirely. What do you think? > > > Anyway, back to my original question, the conclusion appears to be: > > - it is OK for the server to not know what module-revision a client used to format its RPC message as the server must forever support previous versions of the RPC. > > - it is OK for the client to not be coded to support the current module-revision a server supports as the server must continue to return all previously returned fields and also because the client > can safely ignore any unrecognized fields. > > - the ability for the server to return the list of revisions it supports is valuable in that it allows new implementations can indicate support for just the current version and hence never have to > support previously deprecated nodes. > I don't understand why the server would want to advertise old versions. It advertises the version most current at the time of implementation. The client should be OK if the data model was updated properly. The intent of status obsolete is that the object is removed from the server. A mandatory node cannot be removed. If that or a key leaf is wrong, the data model has to start over with a new name. A client needs to access data nodes by name instead of assuming the child node list will be exactly a certain way. Then an old client will ignore new fields and assume missing optional fields means the option is not supported. I think you may have a real concern. If you have an application that knows about rev 2010-01-01 of the FOO module, then the app might break if the server stops advertising 2010-01-01 and starts advertising a new version instead. Can this client just code to its old notion of the FOO module and ignore the version difference in the advertisement? As you pointed out, not if an object is now obsolete. I think current NETCONF/YANG forces you to keep renaming the RPC, or add a parameter to request a specific version of the RPC. There is no other way for the server to know the client wants an old version. I do not like adding 'special XML' that signals the version somehow within the message encoding. > > Thanks, Kent > > > Andy From kwatsen@juniper.net Thu Dec 30 11:04:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7483A6817 for ; Thu, 30 Dec 2010 11:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-u9Wv2SR65W for ; Thu, 30 Dec 2010 11:04:34 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 8ED5A3A67E7 for ; Thu, 30 Dec 2010 11:04:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTRzYPzbtChh98BGEGqgxpul7h6RhqrFm@postini.com; Thu, 30 Dec 2010 11:06:40 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 30 Dec 2010 11:05:41 -0800 From: Kent Watsen To: Andy Bierman Date: Thu, 30 Dec 2010 11:05:35 -0800 Thread-Topic: [netmod] how to know which module revision an RPC is for? Thread-Index: Acunu2/NgfMbHNytScuHe6ulY1VmCQAkzcQA Message-ID: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> <4D1BD759.1090207@andybierman.com> In-Reply-To: <4D1BD759.1090207@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 30 Dec 2010 19:04:35 -0000 > I don't understand why the server would want to advertise > old versions. It advertises the version most current at > the time of implementation. The client should be OK if > the data model was updated properly. My best guess is that it is so that clients can know that the server implem= ents the since-deprecated nodes. For instance, assume revision 2011-01-01 = defines RPC , which is deprecated in 2012-02-02. A server advertiz= ing both revisions is expected to implement , while one only advert= ising 2012-02-02 is not. > The intent of status obsolete is that the object is removed > from the server. A mandatory node cannot be removed. If that > or a key leaf is wrong, the data model has to start over with a > new name. The rules must be different for RPCs and RPC Replies. For RPCs, it would b= e an error if even a non-mandatory node disappeared, as a legacy client cou= ld still send it, while for RPC Replies, it would be OK for a non-mandatory= node to disappear, since the client shouldn't have been coded to expect it= . Regarding mandatory nodes not being removable, the RFC says otherwise or, m= ore specifically, section 10 says: a "mandatory" statement may be removed o= r changed from "true" to "false". I think this statement makes sense for i= nputs (like RPCs and Config), but not so much for outputs (like RPC Replies= and Notifications). Nonetheless, there it is, which seems to be a mistake= . Starting over with a new name may be required, given the current state of t= he RFC, but the server still needs to return the mandatory nodes, even if t= hey've been deprecated (see previous email), so this means the server would= be returning both the old and the new names (ugh). We can limit the dura= tion of this suboptimal solution using the explicit expiration policy descr= ibed previously, but it's still ugly compared to the client passing a names= paces (or a special parameter) in the RPC to indicate which module-revision= its using. > A client needs to access data nodes by name instead of assuming > the child node list will be exactly a certain way. Then an old > client will ignore new fields and assume missing optional fields > means the option is not supported. I agree that this is implied by the current versioning strategy defined in = the RFC > I think you may have a real concern. > If you have an application that knows about rev 2010-01-01 > of the FOO module, then the app might break if the server > stops advertising 2010-01-01 and starts advertising a new version > instead. > > Can this client just code to its old notion of the FOO module > and ignore the version difference in the advertisement? > As you pointed out, not if an object is now obsolete. Exactly. This is the problem. > I think current NETCONF/YANG forces you to keep renaming the RPC, > or add a parameter to request a specific version of the RPC. > There is no other way for the server to know the client wants > an old version. I do not like adding 'special XML' that signals > the version somehow within the message encoding. Renaming the RPC seems like a non-starter. Passing a parameter (or using a= namespace) is viable, but I believe that the RFC needs to specify the solu= tion in order to insure interoperability. Thanks, Kent From j.schoenwaelder@jacobs-university.de Thu Dec 30 12:36: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 73B7828C0D0 for ; Thu, 30 Dec 2010 12:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 92q4+pEBsBoE for ; Thu, 30 Dec 2010 12:36:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5EB5028B56A for ; Thu, 30 Dec 2010 12:36:03 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2DFAC0012; Thu, 30 Dec 2010 21:38:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pswb1m976BJ3; Thu, 30 Dec 2010 21:38:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BF14C008D; Thu, 30 Dec 2010 21:38:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 601BA160A0BF; Thu, 30 Dec 2010 21:37:57 +0100 (CET) Date: Thu, 30 Dec 2010 21:37:57 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20101230203757.GA9795@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "netmod@ietf.org" References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> <4D1BD759.1090207@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 30 Dec 2010 20:36:08 -0000 On Thu, Dec 30, 2010 at 11:05:35AM -0800, Kent Watsen wrote: > Renaming the RPC seems like a non-starter. Passing a parameter (or > using a namespace) is viable, but I believe that the RFC needs to > specify the solution in order to insure interoperability. So what is the big difference between these options? a) renaming m:foo to m:foo2 b) renaming m:foo to n:foo c) using m:foo(v=0) vs. m:foo(v=1) In the SMI world, the guiding principle was that you can make changes as long as the change is interoperable between old agents/managers and new agents/managers. This is carried forward in RFC 6020: As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification. If a change is needed where interoperability can't be ensured, you have to do a) or, if the change is really big, you may consider doing b). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Thu Dec 30 16:09: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 8EFD228B797 for ; Thu, 30 Dec 2010 16:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 aXB7kAYQBnAi for ; Thu, 30 Dec 2010 16:09:58 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id B905728B56A for ; Thu, 30 Dec 2010 16:09:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTR0f0XHDQkk4sx6ED4ctqr6Gf0rrMkCA@postini.com; Thu, 30 Dec 2010 16:12:05 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 30 Dec 2010 16:09:51 -0800 From: Kent Watsen To: Juergen Schoenwaelder Date: Thu, 30 Dec 2010 16:09:49 -0800 Thread-Topic: [netmod] how to know which module revision an RPC is for? Thread-Index: AcuoYVXzu+aOq8lIStiyj01cZ1Wj9wAGAF/g Message-ID: <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> <4D1BD759.1090207@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> In-Reply-To: <20101230203757.GA9795@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 31 Dec 2010 00:09:59 -0000 > So what is the big difference between these options? > > a) renaming m:foo to m:foo2 > b) renaming m:foo to n:foo > c) using m:foo(v=3D0) vs. m:foo(v=3D1) > > In the SMI world, the guiding principle was that you can make changes > as long as the change is interoperable between old agents/managers and >new agents/managers.=20 Ay, I misunderstood Andy to mean a new name for a child node to an existing= RPC. Yes, of course, a new RPC could break compatibility with whatever RP= C it may have forked off. Good point. But how can this be applied to configuration? - there can only be one conf= iguration (AFAIK), so how can breaks in compatibility ever be supported? =20 Other concerns not yet addressed: 1. unclear how "obsolete" status can ever be used (as to do so would break = backwards compatibility) 2. missing clarification that removing a "mandatory" statement is only allo= w for inputs (RPCs and config) 3. missing clarifying statement that clients must skip over unrecognized el= ements in a response 4. no expiration policy (or are implementations to be forever backwards com= patible?) Thanks, Kent From biermana@Brocade.com Thu Dec 30 16:33: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 13B8B28C0D0 for ; Thu, 30 Dec 2010 16:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=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 Pp+4fkoRZfzN for ; Thu, 30 Dec 2010 16:33:15 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 0382128B56A for ; Thu, 30 Dec 2010 16:33:14 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oBV0YDJm027226; Thu, 30 Dec 2010 16:35:20 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id tgug4g6vx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Dec 2010 16:35:20 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Dec 2010 16:36:44 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 30 Dec 2010 16:35:18 -0800 From: Andy Bierman To: Kent Watsen , Juergen Schoenwaelder Date: Thu, 30 Dec 2010 16:35:17 -0800 Thread-Topic: [netmod] how to know which module revision an RPC is for? Thread-Index: AcuoYVXzu+aOq8lIStiyj01cZ1Wj9wAGAF/gAAHYObA= Message-ID: References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> <4D1BD759.1090207@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-30_13:2010-12-30, 2010-12-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1010190000 definitions=main-1012300108 Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 31 Dec 2010 00:33:19 -0000 Re issue #1: We better figure out how to use status=3Dobsolete. Changing the XML namespace or local-name is always possible. Hopefully we can avoid a cut-and-paste design and come up with something better. IMO, the NMS has to be robust, and fail gracefully if a server advertises a version of a module it does not understand. It can either use its old version, knowing an object could have been made obsolete, or fail altogether. (Or use and stay in synch by compiling modules from the server on-the-fly!) I think you mentioned a 1 year guideline for how long an object has to be 'deprecated' before it can transition to 'obsolete'. That seems like a good idea. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Kent Watsen Sent: Thursday, December 30, 2010 4:10 PM To: Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] how to know which module revision an RPC is for? > So what is the big difference between these options? > > a) renaming m:foo to m:foo2 > b) renaming m:foo to n:foo > c) using m:foo(v=3D0) vs. m:foo(v=3D1) > > In the SMI world, the guiding principle was that you can make changes > as long as the change is interoperable between old agents/managers and >new agents/managers.=20 Ay, I misunderstood Andy to mean a new name for a child node to an existing= RPC. Yes, of course, a new RPC could break compatibility with whatever RP= C it may have forked off. Good point. But how can this be applied to configuration? - there can only be one conf= iguration (AFAIK), so how can breaks in compatibility ever be supported? =20 Other concerns not yet addressed: 1. unclear how "obsolete" status can ever be used (as to do so would break = backwards compatibility) 2. missing clarification that removing a "mandatory" statement is only allo= w for inputs (RPCs and config) 3. missing clarifying statement that clients must skip over unrecognized el= ements in a response 4. no expiration policy (or are implementations to be forever backwards com= patible?) Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu Dec 30 23:26: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 A5A9228C0E3 for ; Thu, 30 Dec 2010 23:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.114 X-Spam-Level: X-Spam-Status: No, score=-103.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 H7Pu8ZrLJfq7 for ; Thu, 30 Dec 2010 23:26:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D1D623A68E5 for ; Thu, 30 Dec 2010 23:26:45 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CF83C0092; Fri, 31 Dec 2010 08:28:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XKAFkO428CVx; Fri, 31 Dec 2010 08:28:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2EC1C0012; Fri, 31 Dec 2010 08:28:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B35F5160A57F; Fri, 31 Dec 2010 08:28:41 +0100 (CET) Date: Fri, 31 Dec 2010 08:28:41 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20101231072840.GA10546@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "netmod@ietf.org" References: <84600D05C20FF943918238042D7670FD3745A2B52D@EMBX01-HQ.jnpr.net> <201012291953.oBTJrOH8038698@idle.juniper.net> <84600D05C20FF943918238042D7670FD3745A2B70F@EMBX01-HQ.jnpr.net> <4D1BD759.1090207@andybierman.com> <84600D05C20FF943918238042D7670FD3745A2BA82@EMBX01-HQ.jnpr.net> <20101230203757.GA9795@elstar.local> <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3745A2BCC8@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] how to know which module revision an RPC is for? 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, 31 Dec 2010 07:26:47 -0000 On Thu, Dec 30, 2010 at 04:09:49PM -0800, Kent Watsen wrote: > But how can this be applied to configuration? - there can only be > one configuration (AFAIK), so how can breaks in compatibility ever > be supported? It depends on what "break in compatibility" means. If you really do something radically different, you create a new module which has its own new name space and this will lead to a break of interoperability. > > Other concerns not yet addressed: > > 1. unclear how "obsolete" status can ever be used (as to do so would break backwards compatibility) RFC 6020 says: o "obsolete" means the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. My reading of that is that obsolete definitions simply record the fact that they were used some time ago - a place holder to track the history and most importantly to make sure the obsolete name is not being reused. See also this quote: Obsolete definitions MUST NOT be removed from modules since their identifiers may still be referenced by other modules. > 2. missing clarification that removing a "mandatory" statement is only allow for inputs (RPCs and config) Which text in section 10 of RFC 6020 makes you believe that removing "mandatory" is allowed? > 3. missing clarifying statement that clients must skip over unrecognized elements in a response This might be stated somewhere but I am not sure how to search efficiently. With vendor augmentations, I guess a client not prepared to handle unknown elements won't get very far in terms of cross vendor interoperability. > 4. no expiration policy (or are implementations to be forever backwards compatible?) An expiration policy in standards implemented across different vendors and deployed in rather diverse environments is likely not a very realistic option. But yes, expiration may work for a single vendor dealing only with specific product lines. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103