From internet-drafts@ietf.org Wed Feb 1 00:34:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E010421F857F; Wed, 1 Feb 2012 00:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUWi6Ee2wWSJ; Wed, 1 Feb 2012 00:34:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02521F856F; Wed, 1 Feb 2012 00:34:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120201083427.11908.53697.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 00:34:27 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 08:34:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-00.txt Pages : 40 Date : 2012-01-31 This document defines a YANG data model for the configuration and identification of the management system of a device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-system-mgmt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-system-mgmt-00.txt From andy@netconfcentral.org Thu Feb 2 08:49:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F821F85E1 for ; Thu, 2 Feb 2012 08:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1vWJqszmdmm for ; Thu, 2 Feb 2012 08:49:15 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54C21F8595 for ; Thu, 2 Feb 2012 08:49:15 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q12GnE3J010959 for ; Thu, 2 Feb 2012 11:49:14 -0500 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:60341] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B7/60-23058-A8EBA2F4; Thu, 02 Feb 2012 11:49:14 -0500 Message-ID: <4F2ABE8A.3080408@netconfcentral.org> Date: Thu, 02 Feb 2012 08:49:14 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20120201083427.11908.53697.idtracker@ietfa.amsl.com> In-Reply-To: <20120201083427.11908.53697.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:49:16 -0000 On 02/01/2012 12:34 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > Title : YANG Data Model for System Management > Author(s) : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netmod-system-mgmt-00.txt > Pages : 40 > Date : 2012-01-31 > > This document defines a YANG data model for the configuration and > identification of the management system of a device. > Hi, Please review this draft and send comments to the mailing list. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netmod-system-mgmt-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-system-mgmt-00.txt > The original timezone name list is not unique (the same abbreviation for multiple locations), so I appended '-2', '-3' to some of them. e.g.: enum ECT { description "Eastern Caribbean Time (does not recognise DST) UTC-04"; } enum ECT-2 { description "Ecuador Time UTC-05"; } Afterwards I realized that changing these strings defeats the purpose of using well-known strings in the first place. I think all timezone-name stuff should be removed from the draft because the strings are not unique, and therefore broken for setting the timezone. Andy From dromasca@avaya.com Thu Feb 2 09:29:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275D421F85F0 for ; Thu, 2 Feb 2012 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO8s1gKmWNLP for ; Thu, 2 Feb 2012 09:29:51 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id CAE7C21F858D for ; Thu, 2 Feb 2012 09:29:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALvHKk/GmAcF/2dsb2JhbABDrwuBBYF0AQEDEh4KPxIBFRUGDAwHVwEEGxqkH5t5i1AsBgFCAgECAYMeAYEGEhQBFYI5YwSbHIxd X-IronPort-AV: E=Sophos;i="4.71,610,1320642000"; d="scan'208";a="327913914" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Feb 2012 12:29:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2012 12:23:57 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AMxZ BgCv B4se Dqxo DvK0 D5Fi F/4G GdKS IlXx L97E M/eO RLRk T3vH WFo/ Wot0 X6n7; 2; YgBjAGwAYQBpAHMAZQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAbgBlAHQAbQBvAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {DBFAA6EF-4542-4E2D-AA3A-2FE81F21A790}; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0A; Thu, 02 Feb 2012 17:29:26 GMT; TgBFAFQATQBPAEQAIAByAGUAYwBoAGEAcgB0AGUAcgBpAG4AZwAgAGEAcABwAHIAbwB2AGUAZAA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {DBFAA6EF-4542-4E2D-AA3A-2FE81F21A790} Content-class: urn:content-classes:message Date: Thu, 2 Feb 2012 18:29:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETMOD rechartering approved Thread-Index: Aczh0DY2F4mCdIZMT4+OyvKPosKTRA== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] NETMOD rechartering approved X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 17:29:52 -0000 The IESG approved in the telechat today the NETMOD rechartering without sending it to external review. You should see the announcement at the beginning of the next week. I wish you success in meeting the goals and milestones.=20 Regards, Dan From j.schoenwaelder@jacobs-university.de Mon Feb 6 05:56:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1484021F84BD for ; Mon, 6 Feb 2012 05:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4ufmqhyE5oH for ; Mon, 6 Feb 2012 05:56:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9D21F8497 for ; Mon, 6 Feb 2012 05:56:25 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C46E020C8F; Mon, 6 Feb 2012 14:56:24 +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 e6ymTWxsoYnX; Mon, 6 Feb 2012 14:56:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 684F420C13; Mon, 6 Feb 2012 14:56:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F3201CED195; Mon, 6 Feb 2012 14:56:06 +0100 (CET) Date: Mon, 6 Feb 2012 14:56:06 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120206135605.GA21106@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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 13:56:30 -0000 Hi, I have a closer look at the interfaces document (as technical contributor) and here are my comments. None of my comments is really a big thing - they are more possible suggestions for little improvements. Overall, the document seems to be in a good shape. - Section 3 uses the pyang tree format (which I personally like very much) but it might not be immediately clear what all the notation means, e.g. enabled? or if-index*. I think I figured this out myself but perhaps we would benefit from having a writeup of the tree format that we could easily refer to. - I am wondering whether there should be a more detailed discussion how the leaf name related to ifName. There are character set differences and it seems also some uniqueness differences. We might help implementors by spelling things out more clearly. - The leaf name has a length restriction of 1..255. This might be coming from ifName. Anyway, draft-carpenter-6man-uri-zoneid-00 suggests a zoneid is 1..15 characters and it seems Linux and Mac OS X use a 16 byte character array (holding a NUL terminated string). Should there be text saying that using names longer than 15 characters (well thinking ASCII for the moment ;-) may be problematic? Or is this a non-issue since these interface names are usually generated automatically? Well, on Linux this command ip link set eth0 name abcdefghij123456 actually fails with a name too long error. - Should this text be more explicit: OLD This leaf contains the configured, desired state of the interface. Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus after an ifEntry has been initialized, as described in RFC 2863."; NEW This leaf contains the configured, desired state of the interface. Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus to up or down after an ifEntry has been initialized, as described in RFC 2863."; - Should there be an example motivating/explaining why an interface might have multiple associated if-index values? In which situations does the YANG model have a different number of interfaces than the SNMP model? - I was wondering about trap vs. notification - we meanwhile prefer the term notification but on the other hand the leaf link-up-down-trap-enable models a well established MIB object. But at least in the description, I think we should write OLD "Indicates whether linkUp/linkDown SNMP traps should be generated for this interface. NEW "Indicates whether linkUp/linkDown SNMP notifications should be generated for this interface. - While looking at appendix D, I first spotted 192.168.1.1 which should probably be changed to 198.51.0.1 (see RFC5737) but then I was wondering whether the example should not better line up with the other example augmentations shown in appendix A-C, that is focusing on ethernet/vlan examples rather than IP examples (that are covered meanwhile in a separate document). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Feb 6 13:22:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4293E21F8738 for ; Mon, 6 Feb 2012 13:22: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7UrAV5JPiiM for ; Mon, 6 Feb 2012 13:22:55 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20121F872E for ; Mon, 6 Feb 2012 13:22:54 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1235C1200AD8; Mon, 6 Feb 2012 22:22:52 +0100 (CET) Date: Mon, 06 Feb 2012 22:22:50 +0100 (CET) Message-Id: <20120206.222250.276702524.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120206135605.GA21106@elstar.local> References: <20120206135605.GA21106@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 21:22:56 -0000 Hi Juergen, Thank you for your review. Comments inline. Juergen Schoenwaelder wrote: > Hi, > > I have a closer look at the interfaces document (as technical > contributor) and here are my comments. None of my comments is really > a big thing - they are more possible suggestions for little > improvements. Overall, the document seems to be in a good shape. > > - Section 3 uses the pyang tree format (which I personally like very > much) but it might not be immediately clear what all the notation > means, e.g. enabled? or if-index*. I think I figured this out myself > but perhaps we would benefit from having a writeup of the tree > format that we could easily refer to. I agree. This was also discussed earlier, and I have this text now: The data model in the module "ietf-interfaces" has the following structure, where square brackets are used to enclose a list's keys, "*" denotes a leaf-list, and "?" means that the leaf is optional: > - I am wondering whether there should be a more detailed discussion > how the leaf name related to ifName. There are character set > differences and it seems also some uniqueness differences. We might > help implementors by spelling things out more clearly. Actually, ifName isn't mentioned at all in the draft. The 'name' leaf is not mapped to ifName. See more below. > - The leaf name has a length restriction of 1..255. This might be > coming from ifName. Anyway, draft-carpenter-6man-uri-zoneid-00 > suggests a zoneid is 1..15 characters and it seems Linux and Mac OS > X use a 16 byte character array (holding a NUL terminated string). > Should there be text saying that using names longer than 15 > characters (well thinking ASCII for the moment ;-) may be > problematic? Or is this a non-issue since these interface names are > usually generated automatically? Well, on Linux this command > > ip link set eth0 name abcdefghij123456 > > actually fails with a name too long error. Maybe we should have a text similar to 'description' for ifAlias: This leaf MAY be mapped to ifName by an implementation. Such an implementation MAY restrict the value space of this leaf so that it matches the restrictions of ifName. Why does draft-carpenter-6man-uri-zoneid-00 limit the length to 15? > - Should this text be more explicit: > > OLD > > This leaf contains the configured, desired state of the > interface. Systems that implement the IF-MIB use the > value of this leaf to set IF-MIB.ifAdminStatus after an > ifEntry has been initialized, as described in RFC 2863."; > > NEW > > This leaf contains the configured, desired state of the > interface. Systems that implement the IF-MIB use the > value of this leaf to set IF-MIB.ifAdminStatus to up > or down after an ifEntry has been initialized, as > described in RFC 2863."; Fixed. > - Should there be an example motivating/explaining why an interface > might have multiple associated if-index values? In which situations > does the YANG model have a different number of interfaces than the > SNMP model? The idea was to capture the following example from rfc2863 (in the discussion about ifName :) For example, consider a router having an interface composed of PPP running over an RS-232 port. If the router uses the name "wan1" for the (combined) interface, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would both have the value "wan1". An interface "wan1" in this data model would have two entries in the if-index leaf-list. > - I was wondering about trap vs. notification - we meanwhile prefer > the term notification but on the other hand the leaf > link-up-down-trap-enable models a well established MIB object. > But at least in the description, I think we should write > > OLD > "Indicates whether linkUp/linkDown SNMP traps should be > generated for this interface. > > NEW > "Indicates whether linkUp/linkDown SNMP notifications should be > generated for this interface. Fixed. > - While looking at appendix D, I first spotted 192.168.1.1 which > should probably be changed to 198.51.0.1 (see RFC5737) but then I > was wondering whether the example should not better line up with the > other example augmentations shown in appendix A-C, that is focusing > on ethernet/vlan examples rather than IP examples (that are covered > meanwhile in a separate document). Yes, I now removed the ip example completely. /martin From j.schoenwaelder@jacobs-university.de Mon Feb 6 23:49:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8532F21F85AD for ; Mon, 6 Feb 2012 23:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caJ0k5YQFq-K for ; Mon, 6 Feb 2012 23:49:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1621F85A7 for ; Mon, 6 Feb 2012 23:49:12 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2271B20BE4; Tue, 7 Feb 2012 08:49:11 +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 9B9kuCfVGvXT; Tue, 7 Feb 2012 08:49:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8674D20BE3; Tue, 7 Feb 2012 08:49:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 34B271CEE1CE; Tue, 7 Feb 2012 08:48:53 +0100 (CET) Date: Tue, 7 Feb 2012 08:48:53 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120207074853.GA23485@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120206135605.GA21106@elstar.local> <20120206.222250.276702524.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120206.222250.276702524.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 07:49:13 -0000 On Mon, Feb 06, 2012 at 10:22:50PM +0100, Martin Bjorklund wrote: > > Why does draft-carpenter-6man-uri-zoneid-00 limit the length to 15? > No idea, I did not follow the discussion that led to this I-D. But it seems interface names are commonly limited in size - that does not mean we should hard code the limit of the day but making people aware that there are common limits might be useful. > > - Should there be an example motivating/explaining why an interface > > might have multiple associated if-index values? In which situations > > does the YANG model have a different number of interfaces than the > > SNMP model? > > The idea was to capture the following example from rfc2863 (in the > discussion about ifName :) > > For example, consider a router having an interface composed of PPP > running over an RS-232 port. If the router uses the name "wan1" > for the (combined) interface, then the ifName objects for the > corresponding PPP and RS-232 entries in the ifTable would both have > the value "wan1". > > An interface "wan1" in this data model would have two entries in the > if-index leaf-list. So we have something like ifType.3 = rs232 ifType.4 = ppp ifName.3 = "wan1" ifName.4 = "wan1" with interface 4 stacked on interface 3 in the SNMP world and you would model this as interface { name "wan1"; if-index 3; if-index 4; } in the NETCONF world? What is the type of this interface then? Would it note make more sense to expose the structure 1:1, that is interface { name "wan1-1"; type "rs232"; if-index 3; } interface { name "wan1-2"; type "ppp"; if-index 4; } Yes, this requires to somehow create unique name leafs but that is also why I think some additional text concerning the relationship to ifName is probably a good thing. If we want to preserve the ifName mechanics to compose multiple interfaces into a single "unit", we probably need an additional leaf or so. (I am not sure how useful this is - on the other hand, many systems represent an ethernet interface and the IP interface on top of it as a single unit, e.g. eth0.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Feb 7 00:12:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9C421F870B for ; Tue, 7 Feb 2012 00:12:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey0uePsxC19n for ; Tue, 7 Feb 2012 00:12:07 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0432121F85BE for ; Tue, 7 Feb 2012 00:12:06 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 18F5312008D2; Tue, 7 Feb 2012 09:12:05 +0100 (CET) Date: Tue, 07 Feb 2012 09:12:02 +0100 (CET) Message-Id: <20120207.091202.515484859.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120207074853.GA23485@elstar.local> References: <20120206135605.GA21106@elstar.local> <20120206.222250.276702524.mbj@tail-f.com> <20120207074853.GA23485@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 08:12:08 -0000 Juergen Schoenwaelder wrote: > On Mon, Feb 06, 2012 at 10:22:50PM +0100, Martin Bjorklund wrote: > > > > Why does draft-carpenter-6man-uri-zoneid-00 limit the length to 15? > > > > No idea, I did not follow the discussion that led to this I-D. But it > seems interface names are commonly limited in size - that does not > mean we should hard code the limit of the day but making people aware > that there are common limits might be useful. I agree. Currently the text says A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. Do you want to add explicit text about the length (and maybe character set?) > > > - Should there be an example motivating/explaining why an interface > > > might have multiple associated if-index values? In which situations > > > does the YANG model have a different number of interfaces than the > > > SNMP model? > > > > The idea was to capture the following example from rfc2863 (in the > > discussion about ifName :) > > > > For example, consider a router having an interface composed of PPP > > running over an RS-232 port. If the router uses the name "wan1" > > for the (combined) interface, then the ifName objects for the > > corresponding PPP and RS-232 entries in the ifTable would both have > > the value "wan1". > > > > An interface "wan1" in this data model would have two entries in the > > if-index leaf-list. > > So we have something like > > ifType.3 = rs232 > ifType.4 = ppp > ifName.3 = "wan1" > ifName.4 = "wan1" > > with interface 4 stacked on interface 3 in the SNMP world and you > would model this as > > interface { > name "wan1"; > if-index 3; > if-index 4; > } > > in the NETCONF world? What is the type of this interface then? Would > it note make more sense to expose the structure 1:1, that is > > interface { > name "wan1-1"; > type "rs232"; > if-index 3; > } > > interface { > name "wan1-2"; > type "ppp"; > if-index 4; > } But you would still use ifName wan1 for both these interfaces? I think that is a bit odd. If we keep if-index a leaf-list, we obviously can model the simple case with a 1-1 mapping, but we are also flexible enough for 1-N mappings. > Yes, this requires to somehow create unique name leafs but that is > also why I think some additional text concerning the relationship to > ifName is probably a good thing. > > If we want to preserve the ifName mechanics to compose multiple > interfaces into a single "unit", we probably need an additional leaf > or so. (I am not sure how useful this is - on the other hand, many > systems represent an ethernet interface and the IP interface on top of > it as a single unit, e.g. eth0.) I also do not know how useful this is. But since the flexibility is there in IF-MIB, I think it makes sense to keep it here. What additional leaf(s) would be needed? /martin From j.schoenwaelder@jacobs-university.de Tue Feb 7 02:18:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D8321F8729 for ; Tue, 7 Feb 2012 02:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6wdoBOuRddw for ; Tue, 7 Feb 2012 02:18:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB9BC21F8723 for ; Tue, 7 Feb 2012 02:18:06 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA5E20BFA; Tue, 7 Feb 2012 11:18:06 +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 w7Z8Ii5nRYBd; Tue, 7 Feb 2012 11:18:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EB1020A13; Tue, 7 Feb 2012 11:18:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A05AA1CEE481; Tue, 7 Feb 2012 11:17:47 +0100 (CET) Date: Tue, 7 Feb 2012 11:17:47 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120207101747.GA23719@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120206135605.GA21106@elstar.local> <20120206.222250.276702524.mbj@tail-f.com> <20120207074853.GA23485@elstar.local> <20120207.091202.515484859.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120207.091202.515484859.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:18:08 -0000 On Tue, Feb 07, 2012 at 09:12:02AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Feb 06, 2012 at 10:22:50PM +0100, Martin Bjorklund wrote: > > > > > > Why does draft-carpenter-6man-uri-zoneid-00 limit the length to 15? > > > > > > > No idea, I did not follow the discussion that led to this I-D. But it > > seems interface names are commonly limited in size - that does not > > mean we should hard code the limit of the day but making people aware > > that there are common limits might be useful. > > I agree. Currently the text says > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. > > Do you want to add explicit text about the length (and maybe character > set?) Well, this likely depends on what happens to draft-carpenter-6man-uri-zoneid-00. So for now this text seems to be good enough. > > > > - Should there be an example motivating/explaining why an interface > > > > might have multiple associated if-index values? In which situations > > > > does the YANG model have a different number of interfaces than the > > > > SNMP model? > > > > > > The idea was to capture the following example from rfc2863 (in the > > > discussion about ifName :) > > > > > > For example, consider a router having an interface composed of PPP > > > running over an RS-232 port. If the router uses the name "wan1" > > > for the (combined) interface, then the ifName objects for the > > > corresponding PPP and RS-232 entries in the ifTable would both have > > > the value "wan1". > > > > > > An interface "wan1" in this data model would have two entries in the > > > if-index leaf-list. > > > > So we have something like > > > > ifType.3 = rs232 > > ifType.4 = ppp > > ifName.3 = "wan1" > > ifName.4 = "wan1" > > > > with interface 4 stacked on interface 3 in the SNMP world and you > > would model this as > > > > interface { > > name "wan1"; > > if-index 3; > > if-index 4; > > } > > > > in the NETCONF world? What is the type of this interface then? Would > > it note make more sense to expose the structure 1:1, that is > > > > interface { > > name "wan1-1"; > > type "rs232"; > > if-index 3; > > } > > > > interface { > > name "wan1-2"; > > type "ppp"; > > if-index 4; > > } > > But you would still use ifName wan1 for both these interfaces? I > think that is a bit odd. If we keep if-index a leaf-list, we > obviously can model the simple case with a 1-1 mapping, but we are > also flexible enough for 1-N mappings. I strongly prefer to have a 1:1 relationship between interfaces in the YANG data model and the SNMP data model. And that means the name leaf can't be the same value as ifName in this case. This is why I changed it to "wan1-1" and "wan1-2" in the example. > > Yes, this requires to somehow create unique name leafs but that is > > also why I think some additional text concerning the relationship to > > ifName is probably a good thing. > > > > If we want to preserve the ifName mechanics to compose multiple > > interfaces into a single "unit", we probably need an additional leaf > > or so. (I am not sure how useful this is - on the other hand, many > > systems represent an ethernet interface and the IP interface on top of > > it as a single unit, e.g. eth0.) > > I also do not know how useful this is. But since the flexibility is > there in IF-MIB, I think it makes sense to keep it here. > > What additional leaf(s) would be needed? Essentially, the IF-MIB allows to have a single ifName value for several (stacked) interfaces. This can be used to "hide" or "collapse" interface layers on a CLI. Since I prefer to have a 1:1 mapping between interfaces in the YANG data model and interfaces in the IF-MIB data model and since the 'name' leaf is a key identifying an interface in the YANG data model, I think we would need an additional object to model an ifName value that is shared by multiple interfaces. I am actually not sure why all this is needed since we have stacking relationships. If I have a ppp interface named say ppp0 running over rs232, then using ppp0 is just good enough. And if you would have multiple different ppp sessions over a single rs232 layer, that is you multiplex N interfaces over 1, then the ifName magic won't work anyway. /js PS: If we do not have a 1:1 mapping, lots of questions will pop up (e.g. what is the interface type of a combined rs232 and ppp interface, or what is the effect of setting an MTU on say a combined ethernet / ip tunnel interface and so on. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Feb 7 03:42:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6521F85C3 for ; Tue, 7 Feb 2012 03:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU4xVtvRtFkX for ; Tue, 7 Feb 2012 03:42:26 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6421F85B1 for ; Tue, 7 Feb 2012 03:42:26 -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 0F12E12008B7; Tue, 7 Feb 2012 12:42:25 +0100 (CET) Date: Tue, 07 Feb 2012 12:42:24 +0100 (CET) Message-Id: <20120207.124224.1892641098026219574.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120207101747.GA23719@elstar.local> References: <20120207074853.GA23485@elstar.local> <20120207.091202.515484859.mbj@tail-f.com> <20120207101747.GA23719@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:42:26 -0000 Juergen Schoenwaelder wrote: > I strongly prefer to have a 1:1 relationship between interfaces in the > YANG data model and the SNMP data model. And that means the name leaf > can't be the same value as ifName in this case. This is why I changed > it to "wan1-1" and "wan1-2" in the example. Ok, I am fine with making this change. If one interface in the YANG model results in more than one ifEntry, if-index can point to the "best match" (probably the top-most interface). In order to figure out the sublayers, the ifStackTable can be used. NEW: leaf if-index { if-feature snmp-if-mib; type int32 { range "1..2147483647"; } config false; description "The ifIndex value for the ifEntry represented by this interface. Media-specific modules must specify how the type is mapped to entries in the ifTable."; reference "RFC 2863: The Interfaces Group MIB - ifIndex"; } Currently ifName is not mentioned at all. Do you think we should mention it? /martin From j.schoenwaelder@jacobs-university.de Tue Feb 7 04:30:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E5A21F8792 for ; Tue, 7 Feb 2012 04:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qga-UQVkj9af for ; Tue, 7 Feb 2012 04:30:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB321F8790 for ; Tue, 7 Feb 2012 04:30:24 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A62720C6D; Tue, 7 Feb 2012 13:30:24 +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 yMR1x_3znzAx; Tue, 7 Feb 2012 13:30:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2D1320C6E; Tue, 7 Feb 2012 13:30:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F17301CEE722; Tue, 7 Feb 2012 13:30:05 +0100 (CET) Date: Tue, 7 Feb 2012 13:30:05 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120207123005.GA24056@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120207074853.GA23485@elstar.local> <20120207.091202.515484859.mbj@tail-f.com> <20120207101747.GA23719@elstar.local> <20120207.124224.1892641098026219574.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120207.124224.1892641098026219574.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:30:26 -0000 On Tue, Feb 07, 2012 at 12:42:24PM +0100, Martin Bjorklund wrote: > > Currently ifName is not mentioned at all. Do you think we > should mention it? > I think it is in general helpful to be clear about such relationships. On most systems, I think we want the 'name' leaf and ifName to be the same value for the same interface. But it is good if we give implementors guidance so that they more easily can figure out whether their system deserves some special treatment (e.g. because they have interfaces without an ifName or interfaces with the same ifName value, which is what the IF-MIB allows while the 'name' leaf requires to provide a unique name. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Feb 7 07:07:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9621F84EC for ; Tue, 7 Feb 2012 07:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbtnFYouXvOK for ; Tue, 7 Feb 2012 07:07:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D3FB021F84D5 for ; Tue, 7 Feb 2012 07:07: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 4C9531200043; Tue, 7 Feb 2012 16:07:23 +0100 (CET) Date: Tue, 07 Feb 2012 16:07:22 +0100 (CET) Message-Id: <20120207.160722.1812683084474512088.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120207123005.GA24056@elstar.local> References: <20120207101747.GA23719@elstar.local> <20120207.124224.1892641098026219574.mbj@tail-f.com> <20120207123005.GA24056@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:07:26 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 07, 2012 at 12:42:24PM +0100, Martin Bjorklund wrote: > > > > Currently ifName is not mentioned at all. Do you think we > > should mention it? > > > > I think it is in general helpful to be clear about such > relationships. Ok. I suggest this: leaf name { type string { length "1..255"; } description "An arbitrary name for the interface. A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. For example, if a device has a single array of 8 ethernet ports, the name might be restricted to be on the form 'ethN', where N is an integer between '1' and '8'. This leaf MAY be mapped to ifName by an implementation. Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifName."; reference "RFC 2863: The Interfaces Group MIB - ifName"; } Hmm, maybe we should remove the length restriction altogether? It is probably also a good idea to add a new subsection in the main text describing the relationship to IF-MIB: * Relationship to the IF-MIB If the device implements IF-MIB ^RFC2863^, each entry in the "interface" list is typically mapped to one ifEntry. The "if-index" leaf contains the value of the corresponding ifEntry's ifIndex. In most cases, the "name" of an "interface" entry is mapped to ifName. ifName is defined as an DisplayString ^RFC2579^ which uses a 7-bit ASCII character set. An implementation MAY restrict the allowed values for "name" to match the restrictions of ifName. The IF-MIB allows two different ifEntries to have the same ifName. Devices that support this feature, and also support the configuration of these interfaces using the "interface" list, cannot have a 1-1 mapping between the "name" leaf and ifName. Should we be more strict regarding this mapping? For example, should we say that an interface MUST be mapped to an ifEntry? Are there situations where an entry might be configured, but no ifEntry exists? I was thinking about pre-provisioning, but even this can be represented by an ifEntry with ifOperStatus 'lowerLayerDown'. /martin From j.schoenwaelder@jacobs-university.de Tue Feb 7 07:23:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ADA21F8760 for ; Tue, 7 Feb 2012 07:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHsSgg6CFSgN for ; Tue, 7 Feb 2012 07:23:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0438C21F8748 for ; Tue, 7 Feb 2012 07:23:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F13E20CE5; Tue, 7 Feb 2012 16:23:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BDVneqHJfEOZ; Tue, 7 Feb 2012 16:23:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAD7A20CD2; Tue, 7 Feb 2012 16:23:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D803D1CF1478; Tue, 7 Feb 2012 16:22:58 +0100 (CET) Date: Tue, 7 Feb 2012 16:22:58 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120207152258.GA26539@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120207101747.GA23719@elstar.local> <20120207.124224.1892641098026219574.mbj@tail-f.com> <20120207123005.GA24056@elstar.local> <20120207.160722.1812683084474512088.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120207.160722.1812683084474512088.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:23:19 -0000 On Tue, Feb 07, 2012 at 04:07:22PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Feb 07, 2012 at 12:42:24PM +0100, Martin Bjorklund wrote: > > > > > > Currently ifName is not mentioned at all. Do you think we > > > should mention it? > > > > > > > I think it is in general helpful to be clear about such > > relationships. > > Ok. I suggest this: > > leaf name { > type string { > length "1..255"; > } > description > "An arbitrary name for the interface. > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. > > For example, if a device has a single array of 8 ethernet > ports, the name might be restricted to be on the form > 'ethN', where N is an integer between '1' and '8'. > > This leaf MAY be mapped to ifName by an implementation. > Such an implementation MAY restrict the allowed values for > this leaf so that it matches the restrictions of ifName."; > reference > "RFC 2863: The Interfaces Group MIB - ifName"; > } > > Hmm, maybe we should remove the length restriction altogether? > > It is probably also a good idea to add a new subsection in the main > text describing the relationship to IF-MIB: > > * Relationship to the IF-MIB > > If the device implements IF-MIB ^RFC2863^, each entry in the > "interface" list is typically mapped to one ifEntry. The "if-index" > leaf contains the value of the corresponding ifEntry's ifIndex. > > In most cases, the "name" of an "interface" entry is mapped to > ifName. ifName is defined as an DisplayString ^RFC2579^ which uses > a 7-bit ASCII character set. An implementation MAY restrict the > allowed values for "name" to match the restrictions of ifName. > > The IF-MIB allows two different ifEntries to have the same ifName. > Devices that support this feature, and also support the > configuration of these interfaces using the "interface" list, cannot > have a 1-1 mapping between the "name" leaf and ifName. > > Should we be more strict regarding this mapping? For example, should > we say that an interface MUST be mapped to an ifEntry? Are there > situations where an entry might be configured, but no ifEntry exists? > I was thinking about pre-provisioning, but even this can be > represented by an ifEntry with ifOperStatus 'lowerLayerDown'. This looks good to me. Forcing a 1:1 mapping by using MUST language may be wrong, e.g., some devices seem to have internal interfaces for the communication between the various components of the device that are sometimes visible in the IF-MIB but surely not a subject of a configuration interface exposing the primary functions of a device. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Feb 7 08:59:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA33E21F87EA for ; Tue, 7 Feb 2012 08:59:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAo1RzbQuz+e for ; Tue, 7 Feb 2012 08:59:41 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 064DE21F87E0 for ; Tue, 7 Feb 2012 08:59:40 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 795AE1200043; Tue, 7 Feb 2012 17:59:39 +0100 (CET) Date: Tue, 07 Feb 2012 17:59:38 +0100 (CET) Message-Id: <20120207.175938.523629280.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120207152258.GA26539@elstar.local> References: <20120207123005.GA24056@elstar.local> <20120207.160722.1812683084474512088.mbj@tail-f.com> <20120207152258.GA26539@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:59:41 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 07, 2012 at 04:07:22PM +0100, Martin Bjorklund wrote: > > It is probably also a good idea to add a new subsection in the main > > text describing the relationship to IF-MIB: > > > > * Relationship to the IF-MIB > > > > If the device implements IF-MIB ^RFC2863^, each entry in the > > "interface" list is typically mapped to one ifEntry. The "if-index" > > leaf contains the value of the corresponding ifEntry's ifIndex. > > > > In most cases, the "name" of an "interface" entry is mapped to > > ifName. ifName is defined as an DisplayString ^RFC2579^ which uses > > a 7-bit ASCII character set. An implementation MAY restrict the > > allowed values for "name" to match the restrictions of ifName. > > > > The IF-MIB allows two different ifEntries to have the same ifName. > > Devices that support this feature, and also support the > > configuration of these interfaces using the "interface" list, cannot > > have a 1-1 mapping between the "name" leaf and ifName. > > > > Should we be more strict regarding this mapping? For example, should > > we say that an interface MUST be mapped to an ifEntry? Are there > > situations where an entry might be configured, but no ifEntry exists? > > I was thinking about pre-provisioning, but even this can be > > represented by an ifEntry with ifOperStatus 'lowerLayerDown'. > > This looks good to me. Forcing a 1:1 mapping by using MUST language > may be wrong, e.g., some devices seem to have internal interfaces for > the communication between the various components of the device that > are sometimes visible in the IF-MIB but surely not a subject of a > configuration interface exposing the primary functions of a device. Yes, it is certainly the case that interfaces show up in ifTable even though they are not explicitly configured. I was thinking of the other direction - are there cases where an interafce is configured, but it does not show up in ifTable? /martin From wwwrun@ietfa.amsl.com Tue Feb 7 09:48:49 2012 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 77D6D21F88DC; Tue, 7 Feb 2012 09:48:49 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120207174849.77D6D21F88DC@ietfa.amsl.com> Date: Tue, 7 Feb 2012 09:48:49 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] WG Action: RECHARTER: NETCONF Data Modeling Language (netmod) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:48:49 -0000 The NETCONF Data Modeling Language (netmod) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. NETCONF Data Modeling Language (netmod) ----------------------------------------- Current Status: Active Last Modified: 2012-02-02 Chairs: David Kessens Juergen Schoenwaelder Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing List Address: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Jabber Chat Room Address: xmpp:netmod@jabber.ietf.org Logs: http://jabber.ietf.org/logs/netmod/ Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts and review at WGLC by the Routing Area working group. 4. SMIv2 translation to YANG for read-only operational data and notifications. Guidance will be provided on how to reference existing data structures in SMIv2 from YANG. 5. Data model for configuring SNMP engines. The model must be capable of representing all SNMP engine configurations possible with the standard SNMPv3 MIB modules that are common operational practice. Any differences in functionality and behavior should be documented. The NETMOD Working Group will not work on another version of YANG. Further, the NETMOD Working Group will not serve as a review team for YANG modules developed by other working groups. All new charter items must be fully interoperable with implementations of RFC 6241 and/or RFC 6020. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones Done All _individual_ drafts available that will be used as input into the WG documents (draft-bjorklund-yang, architecture draft, YIN draft, YANG standard library draft, DSDL mapping rules draft) Done Initial set of WG drafts: architecture, YANG, YIN, YANG standard library, DSDL mapping rules (if there is one/more individual draft), based on WG decisions in Dublin Done Initial DSDL mapping rules document Done 01 of YANG, DSDL, architecture, YIN, and standard library draft. If split out, -00 of on-the-wire XML draft. Done Initial YANG Usage guidelines document available as a working group document Done WGLC for YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules Done Submit YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules to the IESG for publication as a Proposed Standard Done Submission of individual draft(s) of Interface data model Done Submission of individual draft(s) of Routing data model Done Submission of individual draft(s) of SMIv2 translation to YANG Done Submission of individual draft(s) of System data model draft Done Submit first working group draft of System data model draft Done Submit first working group draft of Interface data model Done Submit first working group draft of Routing data model Done Submit first working group draft of SMIv2 translation to YANG Mar 2012 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2012 Submit Interface data model to the IESG (proposed standard) Apr 2012 Submit first working group draft of Data model for configuring SNMP engines Aug 2012 Submit System data model to the IESG (proposed standard) Aug 2012 Submit Routing data model to the IESG (proposed standard) Sep 2012 Submit Data model for configuring SNMP engines to the IESG (proposed standard) From j.schoenwaelder@jacobs-university.de Tue Feb 7 10:17:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF121F86C8 for ; Tue, 7 Feb 2012 10:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzfmKwbLXFf6 for ; Tue, 7 Feb 2012 10:17:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ED01B21F86B8 for ; Tue, 7 Feb 2012 10:17:49 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20C5A20D14; Tue, 7 Feb 2012 19:17:49 +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 8kbDjnSzIYKH; Tue, 7 Feb 2012 19:17:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B691F20D10; Tue, 7 Feb 2012 19:17:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CEA181D575F9; Tue, 7 Feb 2012 19:17:30 +0100 (CET) Date: Tue, 7 Feb 2012 19:17:30 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120207181730.GA34641@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120207123005.GA24056@elstar.local> <20120207.160722.1812683084474512088.mbj@tail-f.com> <20120207152258.GA26539@elstar.local> <20120207.175938.523629280.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120207.175938.523629280.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:17:50 -0000 On Tue, Feb 07, 2012 at 05:59:38PM +0100, Martin Bjorklund wrote: > > This looks good to me. Forcing a 1:1 mapping by using MUST language > > may be wrong, e.g., some devices seem to have internal interfaces for > > the communication between the various components of the device that > > are sometimes visible in the IF-MIB but surely not a subject of a > > configuration interface exposing the primary functions of a device. > > Yes, it is certainly the case that interfaces show up in ifTable even > though they are not explicitly configured. I was thinking of the > other direction - are there cases where an interafce is configured, > but it does not show up in ifTable? I can't think of an example easily (except in situations where the SNMP agent screws up handling new interface types but this is a bug not something to design a data model for). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Feb 7 11:05:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB9721F889D for ; Tue, 7 Feb 2012 11:05:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zswL-QL0x3v for ; Tue, 7 Feb 2012 11:05:26 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BB62621F8860 for ; Tue, 7 Feb 2012 11:05:22 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 269C912008B7; Tue, 7 Feb 2012 20:05:21 +0100 (CET) Date: Tue, 07 Feb 2012 20:05:20 +0100 (CET) Message-Id: <20120207.200520.520599435.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120207181730.GA34641@elstar.local> References: <20120207152258.GA26539@elstar.local> <20120207.175938.523629280.mbj@tail-f.com> <20120207181730.GA34641@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:05:26 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 07, 2012 at 05:59:38PM +0100, Martin Bjorklund wrote: > > > > This looks good to me. Forcing a 1:1 mapping by using MUST language > > > may be wrong, e.g., some devices seem to have internal interfaces for > > > the communication between the various components of the device that > > > are sometimes visible in the IF-MIB but surely not a subject of a > > > configuration interface exposing the primary functions of a device. > > > > Yes, it is certainly the case that interfaces show up in ifTable even > > though they are not explicitly configured. I was thinking of the > > other direction - are there cases where an interafce is configured, > > but it does not show up in ifTable? > > I can't think of an example easily (except in situations where the > SNMP agent screws up handling new interface types but this is a bug > not something to design a data model for). Ok. In any case, I think the suggested text is probably sufficient (i.e., no "MUST map"). If you think I have addressed your comments (I do), I'll post a new version of the draft. /martin From j.schoenwaelder@jacobs-university.de Tue Feb 7 12:10:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF07F21F84F4 for ; Tue, 7 Feb 2012 12:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBsJluPfhWOg for ; Tue, 7 Feb 2012 12:10:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 18D9721F84F2 for ; Tue, 7 Feb 2012 12:10:06 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68C3F20D5F; Tue, 7 Feb 2012 21:10:05 +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 cTLAEygsGt1m; Tue, 7 Feb 2012 21:10:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1540620CD8; Tue, 7 Feb 2012 21:10:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4582E1D577D6; Tue, 7 Feb 2012 21:09:47 +0100 (CET) Date: Tue, 7 Feb 2012 21:09:47 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120207200946.GA35332@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120207152258.GA26539@elstar.local> <20120207.175938.523629280.mbj@tail-f.com> <20120207181730.GA34641@elstar.local> <20120207.200520.520599435.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120207.200520.520599435.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:10:06 -0000 On Tue, Feb 07, 2012 at 08:05:20PM +0100, Martin Bjorklund wrote: > > If you think I have addressed your comments (I do), I'll post a > new version of the draft. > Yes, my comments have been resolved. It would be nice to see even more reviews. /js PS: I am following up on the carpenter I-D to see whether we can get a consistent idea about interface names. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Tue Feb 7 14:01:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3459321F8658 for ; Tue, 7 Feb 2012 14:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6fz9jxk670t for ; Tue, 7 Feb 2012 14:01:31 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC0921F8655 for ; Tue, 7 Feb 2012 14:01:30 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA13425 for ; Tue, 7 Feb 2012 17:01:23 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA20947 for ; Tue, 7 Feb 2012 17:01:23 -0500 (EST) Message-Id: <201202072201.RAA20947@adminfs.snmp.com> To: netmod@ietf.org Date: Tue, 07 Feb 2012 17:01:22 -0500 From: David Reid Subject: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 22:01:32 -0000 I'm working on implementing the DISPLAY-HINT part of the MIB to YANG conversion. I'm wondering what to do in cases where the value does not match the DISPLAY-HINT. For example, the SnmpTagValue textual convention has a DISPLAY-HINT of 255t and the description says "implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff." But I don't know how to display many of those code points that I must be prepared to encounter. In our SNMP code we just dump it in hex if we don't know how to render it. But that is not really correct in this case. -David Reid From randy_presuhn@mindspring.com Tue Feb 7 14:53:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432E921F860D for ; Tue, 7 Feb 2012 14:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ywpp+plrAMk for ; Tue, 7 Feb 2012 14:53:41 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5B56621F8613 for ; Tue, 7 Feb 2012 14:53:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SAm/ce9jlpqEb2DrRlhycKEc4cuhpKQWDfusZFQgJQR6W6yMEDXMK24O7nTZYilt; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.173.119] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rutuu-00022t-D5 for netmod@ietf.org; Tue, 07 Feb 2012 17:53:40 -0500 Message-ID: <000601cce5eb$f6dc26c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201202072201.RAA20947@adminfs.snmp.com> Date: Tue, 7 Feb 2012 14:58:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0fd2303a8a2489e67ca92038c874b9a3f1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.173.119 Subject: Re: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 22:53:43 -0000 Hi - > From: "David Reid" > To: > Sent: Tuesday, February 07, 2012 2:01 PM > Subject: [netmod] mib to yang conversion: display-hint > > I'm working on implementing the DISPLAY-HINT part of the MIB to YANG > conversion. I'm wondering what to do in cases where the value does not > match the DISPLAY-HINT. For example, the SnmpTagValue textual convention has > a DISPLAY-HINT of 255t and the description says "implementations must be > prepared to encounter any code point from 0x00000000 to 0x7fffffff." But I > don't know how to display many of those code points that I must be prepared > to encounter. In our SNMP code we just dump it in hex if we don't know how to > render it. But that is not really correct in this case. There is no single "right" answer. Never mind that the failure to specify a normalization form means there are lots of situations where different byte sequences will be displayed exactly the same. There are lots of code points which are not (yet) assigned, and situations will arise where a code point has been assigned, but your system doesn't have a font that can display an appropriate glyph. Depending on your application needs, you might find these suggestions useful: http://unicode.org/faq/unsup_char.html Randy From j.schoenwaelder@jacobs-university.de Tue Feb 7 23:24:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE26F21F86F8 for ; Tue, 7 Feb 2012 23:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwgyNaPmrkNI for ; Tue, 7 Feb 2012 23:24:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6A08121F86F5 for ; Tue, 7 Feb 2012 23:24:51 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDE9720C03; Wed, 8 Feb 2012 08:24:50 +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 dbszQqzc0Rkc; Wed, 8 Feb 2012 08:24:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4958020C02; Wed, 8 Feb 2012 08:24:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2FF651D57D9C; Wed, 8 Feb 2012 08:24:32 +0100 (CET) Date: Wed, 8 Feb 2012 08:24:32 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20120208072432.GA36497@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201202072201.RAA20947@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202072201.RAA20947@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:24:55 -0000 On Tue, Feb 07, 2012 at 05:01:22PM -0500, David Reid wrote: > I'm working on implementing the DISPLAY-HINT part of the MIB to YANG > conversion. I'm wondering what to do in cases where the value does not > match the DISPLAY-HINT. For example, the SnmpTagValue textual convention has > a DISPLAY-HINT of 255t and the description says "implementations must be > prepared to encounter any code point from 0x00000000 to 0x7fffffff." But I > don't know how to display many of those code points that I must be prepared > to encounter. In our SNMP code we just dump it in hex if we don't know how to > render it. But that is not really correct in this case. I think this is not a mib to yang conversion issue (as indicated in the subject line) and hence there is no action for the smiv2 to yang mapping document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Tue Feb 7 23:26:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3368521F86F6; Tue, 7 Feb 2012 23:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uvTYwYgNp53; Tue, 7 Feb 2012 23:26:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1298021F86FA; Tue, 7 Feb 2012 23:26:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120208072621.5713.2538.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 23:26:21 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:26:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for Interface Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-03.txt Pages : 24 Date : 2012-02-07 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-03.txt From mbj@tail-f.com Tue Feb 7 23:30:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822B221F871D for ; Tue, 7 Feb 2012 23:30:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkCL7+crJ4dt for ; Tue, 7 Feb 2012 23:30:11 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C221F871B for ; Tue, 7 Feb 2012 23:30:06 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 31A101200043; Wed, 8 Feb 2012 08:30:05 +0100 (CET) Date: Wed, 08 Feb 2012 08:30:03 +0100 (CET) Message-Id: <20120208.083003.352927737.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120207200946.GA35332@elstar.local> References: <20120207181730.GA34641@elstar.local> <20120207.200520.520599435.mbj@tail-f.com> <20120207200946.GA35332@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] js review of interfaces-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:30:11 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 07, 2012 at 08:05:20PM +0100, Martin Bjorklund wrote: > > > > If you think I have addressed your comments (I do), I'll post a > > new version of the draft. > > > > Yes, my comments have been resolved. It would be nice to see even > more reviews. I have posted a new version of the draft, addressing all comments raised during the WGLC. /martin From internet-drafts@ietf.org Wed Feb 8 04:39:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189D521F86AD; Wed, 8 Feb 2012 04:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yotli4zYkz3; Wed, 8 Feb 2012 04:39:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8DB21F8601; Wed, 8 Feb 2012 04:39:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120208123932.26494.75725.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 04:39:32 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:39:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-02.txt Pages : 14 Date : 2012-02-08 This document defines a YANG data model for configuration of IP addresses on network interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-02.txt From mbj@tail-f.com Wed Feb 8 04:42:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C3C21F84F5 for ; Wed, 8 Feb 2012 04:42:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAXSwyOtuHuk for ; Wed, 8 Feb 2012 04:42:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 17CC621F847F for ; Wed, 8 Feb 2012 04:42:25 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DAF2B12008BC for ; Wed, 8 Feb 2012 13:42:23 +0100 (CET) Date: Wed, 08 Feb 2012 13:42:23 +0100 (CET) Message-Id: <20120208.134223.308665635.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Feb__8_13_42_23_2012_523)--" Content-Transfer-Encoding: 7bit Subject: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:42:26 -0000 ----Next_Part(Wed_Feb__8_13_42_23_2012_523)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have posted an updated version of the ip-cfg draft. There are still some open issues; see the attached file and please comment on these issues. /martin ----Next_Part(Wed_Feb__8_13_42_23_2012_523)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="issues.org" * ip-01 primary, secondary, and preferred address [open] Lada suggested that we need to specify the primary address on an interface, and he pointed to the solution of two router vendors for doing this. Phil sent some links to Juniper's documentation. It seems to be that these two vendors have the same terminology, but different meaning of the term "primary address". In one case it seems to be the source address used for all outgoing packets on the interface, and in the other it seems to be the source address used for outgoing multi- and broadcast packets. Phil also mentioned "preferred address", which seems to be the source address used for outgoing unicast packets on the *subnet* (i.e., there can be one "preferred address" per subnet on an interface (I think)). So it seems there are two concepts here: default source on interface default source in subnet Q. Is my understanding correct? Q. If it is, do we need any, both, or more of these concepts? This was discussed at IETF-82. From the minutes: JS: Trying to summarize. It seems to be important that the application running on the box can choose the source address. It is less clear that we need something per interface. ** Solution #ip-01.01 Do not add any configration parameters for this. * ip-02 ipv6 auto-link-local-address leaf [open] Lada suggested that maybe there should be a way to tell the server to not automatically assign a link-local unicast address for an ipv6 interface, as defined in RFC 4862. Q. Is this a useful (and implementable) parameter? ** Solution #ip-02.01 If it is decided to do this... container ipv6 { ... container autoconf { ... leaf create-link-local-address { type boolean; default true; description "When create-link-local-address is false, a link local unicast address MUST be configured."; } } } ** Solution #ip-02.02 Since RFC 4862 does not mention that this should be configurable, do not add such a leaf. * ip-03 ip enable knob [open] It seems useful to have a knob to enable ipv6 on an interface. When enabled, stateless address autoconfiguration (RFC 4862) can run. Same for ipv4? IP-MIB has such objects (ipv4InterfaceEnableStatus and ipv6InterfaceEnableStatus). (See also ip-02). ** Solution #ip-03.01 container ipv6 { ... leaf enabled { type boolean; default true; description "Controls if IPv6 is enabled or disabled on this interface."; } } Ditto for IPv4. * ip-04 ipv6 parameters for stateless address autoconfiguration [closed] RFC 4862, section 5.1. states: A node MUST allow the following autoconfiguration-related variable to be configured by system management for each multicast-capable interface: DupAddrDetectTransmits Q. Should we add this leaf? ** Solution #ip-04.01 container autoconf { ... leaf dup-addr-detect-transmits { type uint32; default 1; description "The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. A value of zero indicates that Duplicate Address Detection is not performed on tentative addresses. A value of one indicates a single transmission with no follow-up retransmissions."; reference "RFC 4862: IPv6 Stateless Address Autoconfiguration"; } } This issue was discussed at IETF-82. The conclusion there was that this leaf is needed. ** Resolution Adopted #ip-04.01 * ip-05 ipv6 parameters for neighbor discovery [open] RFC 4861, section 6.2.1. states: A router MUST allow for the following conceptual variables to be configured by system management. Q. Should we add these leaf, conditional on a feature "ipv6-router"? This issue was discussed at IETF-82. The conclusion there was that these objects are needed. ** Solution #ip-05.01 Yes, we should add these parameters, but in the routing document. (Note that in SNMP land, these objects are defined in IP-MIB) * ip-06 add a feature for ipv6 hosts [open] RFC 4862 specifies that the creation of global addresses applies only to hosts, not to routers. Thus, should we add a feature for ipv6 hosts? It would be used in the create-global-addresses leaf: leaf create-global-addresses { // Open Issue #ip-06: should we have a feature here? //if-feature ipv6-host; type boolean; default true; description "If enabled, the host creates global addresses as described in section 5.5 of RFC 4862."; reference "RFC 4862: IPv6 Stateless Address Autoconfiguration"; } Question. In RFC 4862 a host is defined as a node that is not a router, and a router is defined as a node that forwards IP packets. In the IP-MIB (and in some well known OSes), ip forwarding is a writable knob, i.e. if a node is a router or host could change dynamically. If this is correct, we cannot make this a YANG feature. ** Solution #ip-06.01 Yes, add this feature. ** Solution #ip-06.02 No, instead move all host-related parameters to a separate module. ----Next_Part(Wed_Feb__8_13_42_23_2012_523)---- From spakes@snmp.com Wed Feb 8 08:15:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2142521F876A for ; Wed, 8 Feb 2012 08:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnUppzoxNoME for ; Wed, 8 Feb 2012 08:15:32 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C237921F8789 for ; Wed, 8 Feb 2012 08:15:31 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA10693; Wed, 8 Feb 2012 11:15:27 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA04980; Wed, 8 Feb 2012 11:15:18 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 8 Feb 2012 11:15:17 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20120208072432.GA36497@elstar.local> Message-ID: References: <201202072201.RAA20947@adminfs.snmp.com> <20120208072432.GA36497@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:15:33 -0000 Juergen, I think David Reid was asking a follow-up question about the issue from November, "smi2yang-04: string vs. binary". The group came to consensus on solution #04-01: "The mapping of the OCTET STRING depends on the context. If an OCTET STRING type has an associated DISPLAY-HINT, then the corresponding YANG base type is the string type. Otherwise, the binary type is used." As I understand the issue, the question is: What is the proper XML rendering of the YANG string if the value in the OCTET STRING object having DISPLAY-HINT "255t" does not map to a graphic character in the current UTF-8 set? -dss On Wed, 8 Feb 2012, Juergen Schoenwaelder wrote: > On Tue, Feb 07, 2012 at 05:01:22PM -0500, David Reid wrote: > > I'm working on implementing the DISPLAY-HINT part of the MIB to YANG > > conversion. I'm wondering what to do in cases where the value does not > > match the DISPLAY-HINT. For example, the SnmpTagValue textual convention has > > a DISPLAY-HINT of 255t and the description says "implementations must be > > prepared to encounter any code point from 0x00000000 to 0x7fffffff." But I > > don't know how to display many of those code points that I must be prepared > > to encounter. In our SNMP code we just dump it in hex if we don't know how to > > render it. But that is not really correct in this case. > > I think this is not a mib to yang conversion issue (as indicated in > the subject line) and hence there is no action for the smiv2 to yang > mapping document. > > /js On Tue, 22 Nov 2011, Juergen Schoenwaelder wrote: > Subject: Re: [netmod] smi2yang-04: string vs. binary > > On Thu, Nov 17, 2011 at 12:21:29PM -0500, David Spakes wrote: > > If the group concensus is solution #04-01, I'd go along. However, I > > favor solution #04-02. The first character of the value would indicate > > to the NETCONF protocol receiver which element of the union applies. > > > > * If the first character is a double-quote, a string value follows, > > and the leading double-quote is not part of the value. > > > > * If the first character is not a double-quote, the value is binary, > > and the leading character is part of the encoded value. > > A native NETCONF implementation will not do this and it is out of > scope for us to change NETCONF behaviour. I am closing this now in > favour of solution #04-01. > > /js On Thu, 17 Nov 2011, David Spakes wrote: > If the group concensus is solution #04-01, I'd go along ... > > ---------- Forwarded message ---------- > Date: Thu, 17 Nov 2011 11:44:08 -0500 > From: David Reid > To: netmod@ietf.org > Subject: [netmod] smi2yang-04: string vs. binary > > I've never been entirely comfortable with solution #04-01, but I can't > come up with anything better. Of the options on the table, I think #04-01 > is the best. > > -David Reid > > > > * smi2yang-04: string vs. binary [open] > > > > It would be nice to have a reliable mechanism to determine whether > > an OCTET STRING can be represented as a human readable string or is > > a binary string. The current ID suggests to use the presence of a > > DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a > > DISPLAY-HINT when a MIB module is revised, which can lead to > > different translations of different versions of a MIB module. > > > > ** Solution #04-01 > > > > Declare this a non-problem since additions of DISPLAY-HINTs are > > rare. Suggest that implementations provide options to cast an > > OCTET STRING into binary to handle situations where a DISPLAY-HINT > > got added when a module was revised. > > > > ** Solution #04-02 > > > > Translate strings into unions that allows both a human readable > > string representation and a binary representation. However, this > > requires to have some mechanism in place to decide whether a value > > is a human readable string or a binary string, which means we > > likely have to mess around with values. > > > > ** Solution #04-03 > > > > Always translate OCTET STRING types into the YANG binary types. We > > could list some well-known types as exceptions, like DisplayString, > > SnmpAdminString, DateAndTime but such a list will always be > > incomplete and hence some human readable data will be encoded into > > base64. > > > > ** Solution #04-04 > > > > Always translate OCTET STRINGS into a choice which contains a > > binary leaf. Add a second string leaf if there is a DISPLAY-HINT. > > This would also apply to objects using an OCTET STRING TC, that is > > in the extreme case (no special rules for well known string types), > > we get for sysDescr: > > > > choice sysDescr-leaf { > > leaf sysDescr-string { > > type string; > > } > > leaf sysDescr-binary { > > type binary; > > } > > } > > > > While this solution is robust wrt. module revisions that add a > > DISPLAY-HINT, the cost of having to support two formats are > > significant. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Wed Feb 8 09:27:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAC21F8487 for ; Wed, 8 Feb 2012 09:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktmPf3SvPnUy for ; Wed, 8 Feb 2012 09:27:21 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0A45E21F8693 for ; Wed, 8 Feb 2012 09:27:20 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA17132; Wed, 8 Feb 2012 12:27:19 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA05641; Wed, 8 Feb 2012 12:27:18 -0500 (EST) Message-Id: <201202081727.MAA05641@adminfs.snmp.com> To: David Spakes From: David Reid In-reply-to: Your message of Wed, 08 Feb 2012 11:15:17 -0500. Date: Wed, 08 Feb 2012 12:27:18 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:27:22 -0000 Yes David, that is my question, how do I render it. Just to be clear: I don't want to reopen issue #04-01 and I certainly don't want to make the normal case harder by changing things to handle this corner case. I'm just trying to figure out how to implement it. -David Reid > Juergen, > > I think David Reid was asking a follow-up question about the issue > from November, "smi2yang-04: string vs. binary". The group came to > consensus on solution #04-01: "The mapping of the OCTET STRING depends > on the context. If an OCTET STRING type has an associated DISPLAY-HINT, > then the corresponding YANG base type is the string type. Otherwise, > the binary type is used." > > As I understand the issue, the question is: What is the proper XML > rendering of the YANG string if the value in the OCTET STRING object > having DISPLAY-HINT "255t" does not map to a graphic character in the > current UTF-8 set? > > -dss > > On Wed, 8 Feb 2012, Juergen Schoenwaelder wrote: > > > On Tue, Feb 07, 2012 at 05:01:22PM -0500, David Reid wrote: > > > I'm working on implementing the DISPLAY-HINT part of the MIB to YANG > > > conversion. I'm wondering what to do in cases where the value does not > > > match the DISPLAY-HINT. For example, the SnmpTagValue textual convention has > > > a DISPLAY-HINT of 255t and the description says "implementations must be > > > prepared to encounter any code point from 0x00000000 to 0x7fffffff." But I > > > don't know how to display many of those code points that I must be prepared > > > to encounter. In our SNMP code we just dump it in hex if we don't know how to > > > render it. But that is not really correct in this case. > > > > I think this is not a mib to yang conversion issue (as indicated in > > the subject line) and hence there is no action for the smiv2 to yang > > mapping document. > > > > /js > From randy_presuhn@mindspring.com Wed Feb 8 12:25:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDAE21F8539 for ; Wed, 8 Feb 2012 12:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.369 X-Spam-Level: X-Spam-Status: No, score=-100.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzQPpM3-qMia for ; Wed, 8 Feb 2012 12:25:52 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 2F48321F8537 for ; Wed, 8 Feb 2012 12:25:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Ulq8yJWNREWUaXYKOtgoC3BWc5Yu5p1SOYnqPXUmghJHoWheTL8yjjDEDPHGmbMX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.173.119] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RvE5P-00018g-8j for netmod@ietf.org; Wed, 08 Feb 2012 15:25:51 -0500 Message-ID: <000801cce6a0$7913d340$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201202072201.RAA20947@adminfs.snmp.com><20120208072432.GA36497@elstar.local> Date: Wed, 8 Feb 2012 12:30:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f9ab8c2aa8c2b33cc6d574cd02d39bafb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.173.119 Subject: Re: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:25:53 -0000 Hi - > From: "David Spakes" > To: "Juergen Schoenwaelder" > Cc: > Sent: Wednesday, February 08, 2012 8:15 AM > Subject: Re: [netmod] mib to yang conversion: display-hint ... > As I understand the issue, the question is: What is the proper XML > rendering of the YANG string if the value in the OCTET STRING object > having DISPLAY-HINT "255t" does not map to a graphic character in the > current UTF-8 set? There are additional complications. See http://www.w3.org/TR/2007/NOTE-unicode-xml-20070516/ for an introduction to some of the issues. It's made worse with data from SNMP-land because we didn't mandate a normalization form. I think the bottom line is that NCRs are your friends. Randy From reid@snmp.com Wed Feb 8 13:58:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9450C11E8080 for ; Wed, 8 Feb 2012 13:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14-fc2hsKy6a for ; Wed, 8 Feb 2012 13:58:18 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9F66D21F85A3 for ; Wed, 8 Feb 2012 13:58:17 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA11326; Wed, 8 Feb 2012 16:58:12 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA00765; Wed, 8 Feb 2012 16:58:07 -0500 (EST) Message-Id: <201202082158.QAA00765@adminfs.snmp.com> To: "Randy Presuhn" From: David Reid In-reply-to: Your message of Wed, 08 Feb 2012 12:30:16 -0800. <000801cce6a0$7913d340$6b01a8c0@oemcomputer> Date: Wed, 08 Feb 2012 16:58:07 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: display-hint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:58:18 -0000 > Hi - > > > From: "David Spakes" > > To: "Juergen Schoenwaelder" > > Cc: > > Sent: Wednesday, February 08, 2012 8:15 AM > > Subject: Re: [netmod] mib to yang conversion: display-hint > ... > > As I understand the issue, the question is: What is the proper XML > > rendering of the YANG string if the value in the OCTET STRING object > > having DISPLAY-HINT "255t" does not map to a graphic character in the > > current UTF-8 set? > > There are additional complications. See > http://www.w3.org/TR/2007/NOTE-unicode-xml-20070516/ > for an introduction to some of the issues. It's made worse with > data from SNMP-land because we didn't mandate a normalization > form. > > I think the bottom line is that NCRs are your friends. That seems like a reasonable solution. -David Reid From lhotka@nic.cz Thu Feb 9 07:59:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221B21F8628 for ; Thu, 9 Feb 2012 07:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4JbgJGi4Vcu for ; Thu, 9 Feb 2012 07:58:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 88AAD21F8622 for ; Thu, 9 Feb 2012 07:58:57 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 3731D2A0056 for ; Thu, 9 Feb 2012 16:58:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328803136; bh=MP+y1/z5ZsQAEQzAhmWK/FN6M99GdeZcwQzS7MY+TNw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=ZRu8mB9deLtdNY0ZLFuV84NTkv8CtPcv/cdhrCyWxcpHuUeBxbC1Q8x0oDw9Ci23F RTdR7gk9lqpFQ6D83xL1xM60DvVSX95ppteUBzvGszLU6QJRMgrrWydT8xQcYCGwQf kMywo9xXj0Y0tKrytOMaBAIGl3o4ThNBoH5c8o+A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Ladislav Lhotka In-Reply-To: <20120208.134223.308665635.mbj@tail-f.com> Date: Thu, 9 Feb 2012 16:58:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <132D2FFB-8D86-44BC-B37B-FA831BAD43C4@nic.cz> References: <20120208.134223.308665635.mbj@tail-f.com> To: netmod@ietf.org X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:59:02 -0000 On Wed, 08 Feb 2012 13:42:23 +0100 (CET), Martin Bjorklund = wrote: > Hi, >=20 > I have posted an updated version of the ip-cfg draft. >=20 > There are still some open issues; see the attached file and please > comment on these issues. >=20 >=20 > /martin > * ip-01 primary, secondary, and preferred address [open] >=20 ... >=20 > So it seems there are two concepts here: >=20 > default source on interface >=20 > default source in subnet >=20 > Q. Is my understanding correct? >=20 > Q. If it is, do we need any, both, or more of these concepts? For IPv6, RFC 3484 doesn't require the source address to be = configurable, just states that "some unspecified tie-breaker should be = used" if the source address selection algoritm fails to choose a unique = address. So IMO neither of these concepts is strictly necessary. >=20 > This was discussed at IETF-82. =46rom the minutes: >=20 > JS: Trying to summarize. It seems to be important that the > application running on the box can choose the source address. > It is less clear that we need something per interface. I agree with this. >=20 > ** Solution #ip-01.01 >=20 > Do not add any configration parameters for this. >=20 > * ip-02 ipv6 auto-link-local-address leaf [open] >=20 > Lada suggested that maybe there should be a way to tell the server > to not automatically assign a link-local unicast address for an ipv6 > interface, as defined in RFC 4862. >=20 > Q. Is this a useful (and implementable) parameter? >=20 > ** Solution #ip-02.01 >=20 > If it is decided to do this... >=20 > container ipv6 { > ... > container autoconf { > ... > leaf create-link-local-address { > type boolean; > default true; > description > "When create-link-local-address is false, a link local > unicast address MUST be configured."; > } > } > } >=20 > ** Solution #ip-02.02 >=20 > Since RFC 4862 does not mention that this should be configurable, do > not add such a leaf. RFC 4862: "If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required." This seems to be the only case where an operator might want to disable = the automatic LL address. This situation should however be very rare, = and can be handled by the DAD procedure even if the automatic LL address = is not explicitly disabled. So my preferred solution is #ip-02.02. >=20 > * ip-03 ip enable knob [open] >=20 > It seems useful to have a knob to enable ipv6 on an interface. When > enabled, stateless address autoconfiguration (RFC 4862) can run. >=20 > Same for ipv4? IP-MIB has such objects (ipv4InterfaceEnableStatus > and ipv6InterfaceEnableStatus). >=20 > (See also ip-02). >=20 > ** Solution #ip-03.01 >=20 > container ipv6 { > ... > leaf enabled { > type boolean; > default true; > description > "Controls if IPv6 is enabled or disabled on this > interface."; > } > } >=20 > Ditto for IPv4. +1 >=20 > * ip-04 ipv6 parameters for stateless address autoconfiguration = [closed] >=20 > RFC 4862, section 5.1. states: >=20 > A node MUST allow the following autoconfiguration-related variable = to > be configured by system management for each multicast-capable > interface: >=20 > DupAddrDetectTransmits >=20 > Q. Should we add this leaf? >=20 > ** Solution #ip-04.01 >=20 > container autoconf { > ... > leaf dup-addr-detect-transmits { > type uint32; > default 1; > description > "The number of consecutive Neighbor Solicitation messages > sent while performing Duplicate Address Detection on a > tentative address. A value of zero indicates that > Duplicate Address Detection is not performed on tentative > addresses. A value of one indicates a single > transmission with no follow-up retransmissions."; > reference > "RFC 4862: IPv6 Stateless Address Autoconfiguration"; > } > } >=20 > This issue was discussed at IETF-82. The conclusion there was that > this leaf is needed. +1 >=20 > ** Resolution >=20 > Adopted #ip-04.01 >=20 > * ip-05 ipv6 parameters for neighbor discovery [open] >=20 > RFC 4861, section 6.2.1. states: >=20 > A router MUST allow for the following conceptual variables to be > configured by system management. >=20 > Q. Should we add these leaf, conditional on a feature "ipv6-router"? >=20 > This issue was discussed at IETF-82. The conclusion there was that > these objects are needed. >=20 > ** Solution #ip-05.01 >=20 > Yes, we should add these parameters, but in the routing document. > (Note that in SNMP land, these objects are defined in IP-MIB) +1. I can do it in the next revision of the routing document. >=20 > * ip-06 add a feature for ipv6 hosts [open] >=20 > RFC 4862 specifies that the creation of global addresses applies > only to hosts, not to routers. Thus, should we add a feature for > ipv6 hosts? It would be used in the create-global-addresses leaf: >=20 > leaf create-global-addresses { > // Open Issue #ip-06: should we have a feature here? > //if-feature ipv6-host; > type boolean; > default true; > description > "If enabled, the host creates global addresses as described > in section 5.5 of RFC 4862."; > reference > "RFC 4862: IPv6 Stateless Address Autoconfiguration"; > } >=20 > Question. In RFC 4862 a host is defined as a node that is not a > router, and a router is defined as a node that forwards IP packets. >=20 > In the IP-MIB (and in some well known OSes), ip forwarding is a > writable knob, i.e. if a node is a router or host could change > dynamically. If this is correct, we cannot make this a YANG > feature. >=20 > ** Solution #ip-06.01 >=20 > Yes, add this feature. >=20 > ** Solution #ip-06.02 >=20 > No, instead move all host-related parameters to a separate module. ** Solution #ip-06.03 Define the "ip-forwarding" knob and use a dynamic default for = "create-global-addresses": "true" if ip-forwarding is disabled and = "false" if ip-forwarding is enabled. Lada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Feb 9 08:27:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A735421F85D6 for ; Thu, 9 Feb 2012 08:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxurYc+8KKUn for ; Thu, 9 Feb 2012 08:27:41 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5D21F8570 for ; Thu, 9 Feb 2012 08:27:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 64F68540DF0; Thu, 9 Feb 2012 16:09:42 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxx+vMZAPCYp; Thu, 9 Feb 2012 16:09:26 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B68D15403D9; Thu, 9 Feb 2012 16:09:26 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20120208.134223.308665635.mbj@tail-f.com> References: <20120208.134223.308665635.mbj@tail-f.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Thu, 09 Feb 2012 16:09:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 16:27:41 -0000 On Wed, 08 Feb 2012 13:42:23 +0100 (CET), Martin Bjorklund wrote: > Hi, > > I have posted an updated version of the ip-cfg draft. > > There are still some open issues; see the attached file and please > comment on these issues. > > > /martin > * ip-01 primary, secondary, and preferred address [open] > ... > > So it seems there are two concepts here: > > default source on interface > > default source in subnet > > Q. Is my understanding correct? > > Q. If it is, do we need any, both, or more of these concepts? For IPv6, RFC 3484 doesn't require the source address to be configurable, just states that "some unspecified tie-breaker should be used" if the source address selection algoritm fails to choose a unique address. So IMO neither of these concepts is strictly necessary. > > This was discussed at IETF-82. From the minutes: > > JS: Trying to summarize. It seems to be important that the > application running on the box can choose the source address. > It is less clear that we need something per interface. I agree with this. > > ** Solution #ip-01.01 > > Do not add any configration parameters for this. > > * ip-02 ipv6 auto-link-local-address leaf [open] > > Lada suggested that maybe there should be a way to tell the server > to not automatically assign a link-local unicast address for an ipv6 > interface, as defined in RFC 4862. > > Q. Is this a useful (and implementable) parameter? > > ** Solution #ip-02.01 > > If it is decided to do this... > > container ipv6 { > ... > container autoconf { > ... > leaf create-link-local-address { > type boolean; > default true; > description > "When create-link-local-address is false, a link local > unicast address MUST be configured."; > } > } > } > > ** Solution #ip-02.02 > > Since RFC 4862 does not mention that this should be configurable, do > not add such a leaf. RFC 4862: "If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required." This seems to be the only case where an operator might want to disable the automatic LL address. This situation should however be very rare, and can be handled by the DAD procedure even if the automatic LL address is not explicitly disabled. So my preferred solution is #ip-02.02. > > * ip-03 ip enable knob [open] > > It seems useful to have a knob to enable ipv6 on an interface. When > enabled, stateless address autoconfiguration (RFC 4862) can run. > > Same for ipv4? IP-MIB has such objects (ipv4InterfaceEnableStatus > and ipv6InterfaceEnableStatus). > > (See also ip-02). > > ** Solution #ip-03.01 > > container ipv6 { > ... > leaf enabled { > type boolean; > default true; > description > "Controls if IPv6 is enabled or disabled on this > interface."; > } > } > > Ditto for IPv4. +1 > > * ip-04 ipv6 parameters for stateless address autoconfiguration [closed] > > RFC 4862, section 5.1. states: > > A node MUST allow the following autoconfiguration-related variable to > be configured by system management for each multicast-capable > interface: > > DupAddrDetectTransmits > > Q. Should we add this leaf? > > ** Solution #ip-04.01 > > container autoconf { > ... > leaf dup-addr-detect-transmits { > type uint32; > default 1; > description > "The number of consecutive Neighbor Solicitation messages > sent while performing Duplicate Address Detection on a > tentative address. A value of zero indicates that > Duplicate Address Detection is not performed on tentative > addresses. A value of one indicates a single > transmission with no follow-up retransmissions."; > reference > "RFC 4862: IPv6 Stateless Address Autoconfiguration"; > } > } > > This issue was discussed at IETF-82. The conclusion there was that > this leaf is needed. +1 > > ** Resolution > > Adopted #ip-04.01 > > * ip-05 ipv6 parameters for neighbor discovery [open] > > RFC 4861, section 6.2.1. states: > > A router MUST allow for the following conceptual variables to be > configured by system management. > > Q. Should we add these leaf, conditional on a feature "ipv6-router"? > > This issue was discussed at IETF-82. The conclusion there was that > these objects are needed. > > ** Solution #ip-05.01 > > Yes, we should add these parameters, but in the routing document. > (Note that in SNMP land, these objects are defined in IP-MIB) +1. I can do it in the next revision of the routing document. > > * ip-06 add a feature for ipv6 hosts [open] > > RFC 4862 specifies that the creation of global addresses applies > only to hosts, not to routers. Thus, should we add a feature for > ipv6 hosts? It would be used in the create-global-addresses leaf: > > leaf create-global-addresses { > // Open Issue #ip-06: should we have a feature here? > //if-feature ipv6-host; > type boolean; > default true; > description > "If enabled, the host creates global addresses as described > in section 5.5 of RFC 4862."; > reference > "RFC 4862: IPv6 Stateless Address Autoconfiguration"; > } > > Question. In RFC 4862 a host is defined as a node that is not a > router, and a router is defined as a node that forwards IP packets. > > In the IP-MIB (and in some well known OSes), ip forwarding is a > writable knob, i.e. if a node is a router or host could change > dynamically. If this is correct, we cannot make this a YANG > feature. > > ** Solution #ip-06.01 > > Yes, add this feature. > > ** Solution #ip-06.02 > > No, instead move all host-related parameters to a separate module. ** Solution #ip-06.03 Define the "ip-forwarding" knob and use a dynamic default for "create-global-addresses": "true" if ip-forwarding is disabled and "false" if ip-forwarding is enabled. Lada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From Tina.Tsou.Zouting@huawei.com Thu Feb 9 11:17:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9455721E8036 for ; Thu, 9 Feb 2012 11:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8CTFSiRQvqV for ; Thu, 9 Feb 2012 11:17:48 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7545621E8040 for ; Thu, 9 Feb 2012 11:17:48 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ50054C49GIM@szxga03-in.huawei.com> for netmod@ietf.org; Fri, 10 Feb 2012 03:17:41 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500IMR49GKI@szxga03-in.huawei.com> for netmod@ietf.org; Fri, 10 Feb 2012 03:17:40 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ79939; Fri, 10 Feb 2012 03:17:12 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 03:17:09 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 03:17:31 +0800 Date: Thu, 09 Feb 2012 19:16:51 +0000 From: Tina TSOU In-reply-to: To: Ladislav Lhotka Message-id: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [netmod] ip-cfg-02 Thread-index: AQHM5l9NCwqVbeDy0EStQ8rRBO/om5Y0JsUAgADLPXE= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120208.134223.308665635.mbj@tail-f.com> Cc: "netmod@ietf.org" Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:17:49 -0000 Sent from my iPad On Feb 9, 2012, at 8:27 AM, "Ladislav Lhotka" wrote: > On Wed, 08 Feb 2012 13:42:23 +0100 (CET), Martin Bjorklund wrote: >> Hi, >> >> I have posted an updated version of the ip-cfg draft. >> >> There are still some open issues; see the attached file and please >> comment on these issues. >> >> >> /martin >> * ip-01 primary, secondary, and preferred address [open] >> > > ... > >> >> So it seems there are two concepts here: >> >> default source on interface >> >> default source in subnet >> >> Q. Is my understanding correct? >> >> Q. If it is, do we need any, both, or more of these concepts? > > For IPv6, RFC 3484 doesn't require the source address to be configurable, just states that "some unspecified tie-breaker should be used" if the source address selection algoritm fails to choose a unique address. > > So IMO neither of these concepts is strictly necessary. Would u give example of how u configure default source here? > >> >> This was discussed at IETF-82. From the minutes: >> >> JS: Trying to summarize. It seems to be important that the >> application running on the box can choose the source address. >> It is less clear that we need something per interface. > > I agree with this. > >> >> ** Solution #ip-01.01 >> >> Do not add any configration parameters for this. >> >> * ip-02 ipv6 auto-link-local-address leaf [open] >> >> Lada suggested that maybe there should be a way to tell the server >> to not automatically assign a link-local unicast address for an ipv6 >> interface, as defined in RFC 4862. >> >> Q. Is this a useful (and implementable) parameter? >> >> ** Solution #ip-02.01 >> >> If it is decided to do this... >> >> container ipv6 { >> ... >> container autoconf { >> ... >> leaf create-link-local-address { >> type boolean; >> default true; >> description >> "When create-link-local-address is false, a link local >> unicast address MUST be configured."; >> } >> } >> } >> >> ** Solution #ip-02.02 >> >> Since RFC 4862 does not mention that this should be configurable, do >> not add such a leaf. > > RFC 4862: > "If a node determines that its tentative link-local address is not > unique, autoconfiguration stops and manual configuration of the > interface is required." > > This seems to be the only case where an operator might want to disable the automatic LL address. This situation should however be very rare, and can be handled by the DAD procedure even if the automatic LL address is not explicitly disabled. > > So my preferred solution is #ip-02.02. > >> >> * ip-03 ip enable knob [open] >> >> It seems useful to have a knob to enable ipv6 on an interface. When >> enabled, stateless address autoconfiguration (RFC 4862) can run. >> >> Same for ipv4? IP-MIB has such objects (ipv4InterfaceEnableStatus >> and ipv6InterfaceEnableStatus). >> >> (See also ip-02). >> >> ** Solution #ip-03.01 >> >> container ipv6 { >> ... >> leaf enabled { >> type boolean; >> default true; >> description >> "Controls if IPv6 is enabled or disabled on this >> interface."; >> } >> } >> >> Ditto for IPv4. > > +1 > >> >> * ip-04 ipv6 parameters for stateless address autoconfiguration [closed] >> >> RFC 4862, section 5.1. states: >> >> A node MUST allow the following autoconfiguration-related variable to >> be configured by system management for each multicast-capable >> interface: >> >> DupAddrDetectTransmits >> >> Q. Should we add this leaf? >> >> ** Solution #ip-04.01 >> >> container autoconf { >> ... >> leaf dup-addr-detect-transmits { >> type uint32; >> default 1; >> description >> "The number of consecutive Neighbor Solicitation messages >> sent while performing Duplicate Address Detection on a >> tentative address. A value of zero indicates that >> Duplicate Address Detection is not performed on tentative >> addresses. A value of one indicates a single >> transmission with no follow-up retransmissions."; >> reference >> "RFC 4862: IPv6 Stateless Address Autoconfiguration"; >> } >> } >> >> This issue was discussed at IETF-82. The conclusion there was that >> this leaf is needed. > > +1 > >> >> ** Resolution >> >> Adopted #ip-04.01 >> >> * ip-05 ipv6 parameters for neighbor discovery [open] >> >> RFC 4861, section 6.2.1. states: >> >> A router MUST allow for the following conceptual variables to be >> configured by system management. >> >> Q. Should we add these leaf, conditional on a feature "ipv6-router"? >> >> This issue was discussed at IETF-82. The conclusion there was that >> these objects are needed. >> >> ** Solution #ip-05.01 >> >> Yes, we should add these parameters, but in the routing document. >> (Note that in SNMP land, these objects are defined in IP-MIB) > > +1. I can do it in the next revision of the routing document. > >> >> * ip-06 add a feature for ipv6 hosts [open] >> >> RFC 4862 specifies that the creation of global addresses applies >> only to hosts, not to routers. Thus, should we add a feature for >> ipv6 hosts? It would be used in the create-global-addresses leaf: >> >> leaf create-global-addresses { >> // Open Issue #ip-06: should we have a feature here? >> //if-feature ipv6-host; >> type boolean; >> default true; >> description >> "If enabled, the host creates global addresses as described >> in section 5.5 of RFC 4862."; >> reference >> "RFC 4862: IPv6 Stateless Address Autoconfiguration"; >> } >> >> Question. In RFC 4862 a host is defined as a node that is not a >> router, and a router is defined as a node that forwards IP packets. >> >> In the IP-MIB (and in some well known OSes), ip forwarding is a >> writable knob, i.e. if a node is a router or host could change >> dynamically. If this is correct, we cannot make this a YANG >> feature. >> >> ** Solution #ip-06.01 >> >> Yes, add this feature. >> >> ** Solution #ip-06.02 >> >> No, instead move all host-related parameters to a separate module. > > ** Solution #ip-06.03 > > Define the "ip-forwarding" knob and use a dynamic default for "create-global-addresses": "true" if ip-forwarding is disabled and "false" if ip-forwarding is enabled. > > Lada > >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Thu Feb 9 12:42:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9096211E80A0 for ; Thu, 9 Feb 2012 12:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugxNpj0bKUrB for ; Thu, 9 Feb 2012 12:42:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14C11E809C for ; Thu, 9 Feb 2012 12:42:12 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 5C1FA2A2F79; Thu, 9 Feb 2012 21:42:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328820131; bh=nlFSCDkxePxrtjXFnl7wrQSe5/+7iKUTME2JLeTaZA4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ucIlR6IaoB7pG50A7w54k/y0AFlaFVQI86mHoK4hOivd64L99Ul58+OtQrTJ69Lkb c4ub9VeEOqjVJE14tDwiMpePlLuI1aq2McVBthTMC01ghLB1gHQ/YrDGPDo9PyC7s7 vMS7RkjdFSoDkzd9DxEehhz/oMtcoSSgGFIusxOw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> Date: Thu, 9 Feb 2012 21:42:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208.134223.308665635.mbj@tail-f.com> <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> To: Tina TSOU X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 20:42:13 -0000 On Feb 9, 2012, at 8:16 PM, Tina TSOU wrote: >>>=20 >>> So it seems there are two concepts here: >>>=20 >>> default source on interface >>>=20 >>> default source in subnet >>>=20 >>> Q. Is my understanding correct? >>>=20 >>> Q. If it is, do we need any, both, or more of these concepts? >>=20 >> For IPv6, RFC 3484 doesn't require the source address to be = configurable, just states that "some unspecified tie-breaker should be = used" if the source address selection algoritm fails to choose a unique = address. >>=20 >> So IMO neither of these concepts is strictly necessary. > Would u give example of how u configure default source here? What do you mean by "here"? The case when the 3484 rules don't provide a = unique address? I think that Linux, for example, chooses the address = that was configured last. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From Tina.Tsou.Zouting@huawei.com Thu Feb 9 14:54:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2542121E8069 for ; Thu, 9 Feb 2012 14:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSBMZMXmB8ZS for ; Thu, 9 Feb 2012 14:54:27 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6666021E8067 for ; Thu, 9 Feb 2012 14:54:27 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500L5REAQJ9@szxga05-in.huawei.com> for netmod@ietf.org; Fri, 10 Feb 2012 06:54:26 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500FBIEAQYB@szxga05-in.huawei.com> for netmod@ietf.org; Fri, 10 Feb 2012 06:54:26 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGT20638; Fri, 10 Feb 2012 06:54:18 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 06:53:44 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 06:53:59 +0800 Date: Thu, 09 Feb 2012 22:53:58 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.156] To: Ladislav Lhotka Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [netmod] ip-cfg-02 Thread-index: AQHM5l9NCwqVbeDy0EStQ8rRBO/om5Y0JsUAgADLPXH//5G5AIAAqogA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120208.134223.308665635.mbj@tail-f.com> <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> Cc: "netmod@ietf.org" Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:54:28 -0000 Tina > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Thursday, February 09, 2012 12:42 PM > To: Tina TSOU > Cc: Martin Bjorklund; netmod@ietf.org > Subject: Re: [netmod] ip-cfg-02 > > > On Feb 9, 2012, at 8:16 PM, Tina TSOU wrote: > > >>> > >>> So it seems there are two concepts here: > >>> > >>> default source on interface > >>> > >>> default source in subnet > >>> > >>> Q. Is my understanding correct? > >>> > >>> Q. If it is, do we need any, both, or more of these concepts? > >> > >> For IPv6, RFC 3484 doesn't require the source address to be > configurable, just states that "some unspecified tie-breaker should be > used" if the source address selection algoritm fails to choose a unique > address. > >> > >> So IMO neither of these concepts is strictly necessary. > > Would u give example of how u configure default source here? > > What do you mean by "here"? The case when the 3484 rules don't provide a > unique address? I think that Linux, for example, chooses the address that > was configured last. I meant the example default value of default source on interface default source in subnet > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > From mbj@tail-f.com Fri Feb 10 00:10:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A12D21F8709 for ; Fri, 10 Feb 2012 00:10:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU01e8a65COZ for ; Fri, 10 Feb 2012 00:10:52 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 117B521F8701 for ; Fri, 10 Feb 2012 00:10:50 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 0FABE1200AC8; Fri, 10 Feb 2012 09:10:42 +0100 (CET) Date: Fri, 10 Feb 2012 09:10:40 +0100 (CET) Message-Id: <20120210.091040.414915280.mbj@tail-f.com> To: Tina.Tsou.Zouting@huawei.com From: Martin Bjorklund In-Reply-To: References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 08:10:53 -0000 Hi Tina, This is regarding one of the open issues. The question is if we need to standardize a mechanism to configure the "primary" address. During the discussion about this issue, we identified at least two (maybe three) different concepts: default source on interface default source in subnet (The third is the ability to specify the source for a particular service, e.g. use 10.0.0.1 as source when you talk to the radius server, but 10.0.0.2 when you talk to the syslog server). The question now is *if* we should standardize a solution to these problems or not. I believe Lada said "no". /martin P.S. Here's the complete issue description again. * ip-01 primary, secondary, and preferred address [open] Lada suggested that we need to specify the primary address on an interface, and he pointed to the solution of two router vendors for doing this. Phil sent some links to Juniper's documentation. It seems to be that these two vendors have the same terminology, but different meaning of the term "primary address". In one case it seems to be the source address used for all outgoing packets on the interface, and in the other it seems to be the source address used for outgoing multi- and broadcast packets. Phil also mentioned "preferred address", which seems to be the source address used for outgoing unicast packets on the *subnet* (i.e., there can be one "preferred address" per subnet on an interface (I think)). So it seems there are two concepts here: default source on interface default source in subnet Q. Is my understanding correct? Q. If it is, do we need any, both, or more of these concepts? This was discussed at IETF-82. From the minutes: JS: Trying to summarize. It seems to be important that the application running on the box can choose the source address. It is less clear that we need something per interface. From j.schoenwaelder@jacobs-university.de Fri Feb 10 00:27:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9739F21F858A for ; Fri, 10 Feb 2012 00:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43oWnBQSANsm for ; Fri, 10 Feb 2012 00:27:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C654421F8573 for ; Fri, 10 Feb 2012 00:27:30 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7BD320D1E; Fri, 10 Feb 2012 09:27:29 +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 qMy78pSNtKqy; Fri, 10 Feb 2012 09:27:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F38220D13; Fri, 10 Feb 2012 09:27:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 88BFD1D61338; Fri, 10 Feb 2012 09:27:29 +0100 (CET) Date: Fri, 10 Feb 2012 09:27:29 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120210082729.GA17509@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> <20120210.091040.414915280.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120210.091040.414915280.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 08:27:32 -0000 On Fri, Feb 10, 2012 at 09:10:40AM +0100, Martin Bjorklund wrote: > Hi Tina, > > This is regarding one of the open issues. The question is if we need > to standardize a mechanism to configure the "primary" address. During > the discussion about this issue, we identified at least two (maybe > three) different concepts: > > default source on interface > > default source in subnet > > (The third is the ability to specify the source for a particular > service, e.g. use 10.0.0.1 as source when you talk to the radius > server, but 10.0.0.2 when you talk to the syslog server). > > The question now is *if* we should standardize a solution to these > problems or not. I believe Lada said "no". I think Lada said no to "default source on interface" and "default source in subnet". It still seems desirable to be able specify the default source applications/servers use. (But this is likely just a guideline for people to consider who do data models for application protocols/services - perhaps we should find a place to capture such things to consider when doing YANG configuration data models.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Feb 10 01:41:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C897521F86C2 for ; Fri, 10 Feb 2012 01:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg3wKUIOd7XW for ; Fri, 10 Feb 2012 01:41:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 04EAC21F86A0 for ; Fri, 10 Feb 2012 01:41:45 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 01F952A30A1; Fri, 10 Feb 2012 10:41:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328866904; bh=U7/SeA9N5YTFhh3ZsvxG/gvMUVpYrV4PmeMuO4dYcGk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=a0c/QqWgjFGH5Z6IN+5kNYxHg/CMWcVc/Oo9K1qzOo1a/gDG0Gly21UKVW3vBEXtU +2Gf363m5WLk9kLKvJs+3+fEMFAmfytMjlvAJexd8EovhsADBpBbFDNMQsq24ZkhED ktnuXUbbzsN/pAQh5JbMi5uTi+PA6PnTRjMUMiRc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120210.091040.414915280.mbj@tail-f.com> Date: Fri, 10 Feb 2012 10:41:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> <20120210.091040.414915280.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 09:41:46 -0000 On Feb 10, 2012, at 9:10 AM, Martin Bjorklund wrote: > Hi Tina, >=20 > This is regarding one of the open issues. The question is if we need > to standardize a mechanism to configure the "primary" address. During > the discussion about this issue, we identified at least two (maybe > three) different concepts: >=20 > default source on interface >=20 > default source in subnet >=20 > (The third is the ability to specify the source for a particular > service, e.g. use 10.0.0.1 as source when you talk to the radius > server, but 10.0.0.2 when you talk to the syslog server). Yes, a BGP implementation will also most likely include the possibility = to configure the source address. >=20 > The question now is *if* we should standardize a solution to these > problems or not. I believe Lada said "no". Right. Lada >=20 >=20 > /martin >=20 > P.S. Here's the complete issue description again. >=20 >=20 > * ip-01 primary, secondary, and preferred address [open] >=20 > Lada suggested that we need to specify the primary address on an > interface, and he pointed to the solution of two router vendors for > doing this. Phil sent some links to Juniper's documentation. >=20 > It seems to be that these two vendors have the same terminology, but > different meaning of the term "primary address". In one case it > seems to be the source address used for all outgoing packets on the > interface, and in the other it seems to be the source address used > for outgoing multi- and broadcast packets. >=20 > Phil also mentioned "preferred address", which seems to be the > source address used for outgoing unicast packets on the *subnet* > (i.e., there can be one "preferred address" per subnet on an > interface (I think)). >=20 > So it seems there are two concepts here: >=20 > default source on interface >=20 > default source in subnet >=20 > Q. Is my understanding correct? >=20 > Q. If it is, do we need any, both, or more of these concepts? >=20 > This was discussed at IETF-82. =46rom the minutes: >=20 > JS: Trying to summarize. It seems to be important that the > application running on the box can choose the source address. > It is less clear that we need something per interface. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Feb 10 01:45:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BFF21F8758 for ; Fri, 10 Feb 2012 01:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF0uh2IlWccR for ; Fri, 10 Feb 2012 01:45:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACED21F8757 for ; Fri, 10 Feb 2012 01:45:40 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 32B0F2A30AB; Fri, 10 Feb 2012 10:45:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328867139; bh=R2o7QprpNhsv+PP2XWWYM9by5qQNeWCoj8/hgwSIvGQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GQGGMa5et/NJzspzK2IwwjR1BDFGvq2bgwyFFvFO/k0uyRptwpnJumoJbDzpQ0Jwh pIAdXzFye1wY9GUTxjanJoREMP5hzXLUbEsSwWP7UfcmbXR5IxL76lL9R2NPmSBOjL 3aRQhWcbokEJUHZS3T1F9fCrejSCo1pSjiulXUEw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120210082729.GA17509@elstar.local> Date: Fri, 10 Feb 2012 10:45:42 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> <20120210.091040.414915280.mbj@tail-f.com> <20120210082729.GA17509@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 09:45:41 -0000 On Feb 10, 2012, at 9:27 AM, Juergen Schoenwaelder wrote: > On Fri, Feb 10, 2012 at 09:10:40AM +0100, Martin Bjorklund wrote: >> Hi Tina, >> >> This is regarding one of the open issues. The question is if we need >> to standardize a mechanism to configure the "primary" address. During >> the discussion about this issue, we identified at least two (maybe >> three) different concepts: >> >> default source on interface >> >> default source in subnet >> >> (The third is the ability to specify the source for a particular >> service, e.g. use 10.0.0.1 as source when you talk to the radius >> server, but 10.0.0.2 when you talk to the syslog server). >> >> The question now is *if* we should standardize a solution to these >> problems or not. I believe Lada said "no". > > I think Lada said no to "default source on interface" and "default > source in subnet". It still seems desirable to be able specify the > default source applications/servers use. (But this is likely just a > guideline for people to consider who do data models for application > protocols/services - perhaps we should find a place to capture such > things to consider when doing YANG configuration data models.) Do you mean this should be done in the ip-cfg module or elsewhere? Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Feb 10 02:48:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672B921F8568 for ; Fri, 10 Feb 2012 02:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA-m2meFAAqW for ; Fri, 10 Feb 2012 02:48:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9021F856A for ; Fri, 10 Feb 2012 02:48:08 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E340620CD1; Fri, 10 Feb 2012 11:48:07 +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 TYblZ9C0dCOQ; Fri, 10 Feb 2012 11:48:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC50420CF3; Fri, 10 Feb 2012 11:48:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 350761D616FB; Fri, 10 Feb 2012 11:48:04 +0100 (CET) Date: Fri, 10 Feb 2012 11:48:03 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120210104801.GA17801@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> <20120210.091040.414915280.mbj@tail-f.com> <20120210082729.GA17509@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 10:48:09 -0000 On Fri, Feb 10, 2012 at 10:45:42AM +0100, Ladislav Lhotka wrote: > > On Feb 10, 2012, at 9:27 AM, Juergen Schoenwaelder wrote: > > > On Fri, Feb 10, 2012 at 09:10:40AM +0100, Martin Bjorklund wrote: > >> Hi Tina, > >> > >> This is regarding one of the open issues. The question is if we need > >> to standardize a mechanism to configure the "primary" address. During > >> the discussion about this issue, we identified at least two (maybe > >> three) different concepts: > >> > >> default source on interface > >> > >> default source in subnet > >> > >> (The third is the ability to specify the source for a particular > >> service, e.g. use 10.0.0.1 as source when you talk to the radius > >> server, but 10.0.0.2 when you talk to the syslog server). > >> > >> The question now is *if* we should standardize a solution to these > >> problems or not. I believe Lada said "no". > > > > I think Lada said no to "default source on interface" and "default > > source in subnet". It still seems desirable to be able specify the > > default source applications/servers use. (But this is likely just a > > guideline for people to consider who do data models for application > > protocols/services - perhaps we should find a place to capture such > > things to consider when doing YANG configuration data models.) > > Do you mean this should be done in the ip-cfg module or elsewhere? The systems I am familiar with seem to have this as a service specific option, likely because the service implementation takes extra care to implement this. So I do not think the ip-cfg module should solve this. /js (as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Feb 10 04:02:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC56021F84E1 for ; Fri, 10 Feb 2012 04:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSumBG-7jr+O for ; Fri, 10 Feb 2012 04:02:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0923221F8539 for ; Fri, 10 Feb 2012 04:02:49 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 39A322A0DC4; Fri, 10 Feb 2012 13:02:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328875365; bh=qswGm3LVRi04Cyk9oc0BxalCe8wSB99f2Kl4vUnNFTE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=B81gfBAMIXsSuwY+dK2YB2LYEr24wZ7ajPMjgJAsFuRZl+tJJrhXO4QAsWIQ2T3nj 82IfyBgHB2TZNSRezuEHG39BEPTqrRN1O1DOxzB0nxWDKjtb+T99vzZGbcT3wXlDDW X0X3a9ZtOoQEq6E15XISXdYZ6jcam4YpSbMRZok8= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120210104801.GA17801@elstar.local> Date: Fri, 10 Feb 2012 13:02:44 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> <20120210.091040.414915280.mbj@tail-f.com> <20120210082729.GA17509@elstar.local> <20120210104801.GA17801@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:02:50 -0000 On Feb 10, 2012, at 11:48 AM, Juergen Schoenwaelder wrote: > On Fri, Feb 10, 2012 at 10:45:42AM +0100, Ladislav Lhotka wrote: >> >> On Feb 10, 2012, at 9:27 AM, Juergen Schoenwaelder wrote: >> >>> On Fri, Feb 10, 2012 at 09:10:40AM +0100, Martin Bjorklund wrote: >>>> Hi Tina, >>>> >>>> This is regarding one of the open issues. The question is if we need >>>> to standardize a mechanism to configure the "primary" address. During >>>> the discussion about this issue, we identified at least two (maybe >>>> three) different concepts: >>>> >>>> default source on interface >>>> >>>> default source in subnet >>>> >>>> (The third is the ability to specify the source for a particular >>>> service, e.g. use 10.0.0.1 as source when you talk to the radius >>>> server, but 10.0.0.2 when you talk to the syslog server). >>>> >>>> The question now is *if* we should standardize a solution to these >>>> problems or not. I believe Lada said "no". >>> >>> I think Lada said no to "default source on interface" and "default >>> source in subnet". It still seems desirable to be able specify the >>> default source applications/servers use. (But this is likely just a >>> guideline for people to consider who do data models for application >>> protocols/services - perhaps we should find a place to capture such >>> things to consider when doing YANG configuration data models.) >> >> Do you mean this should be done in the ip-cfg module or elsewhere? > > The systems I am familiar with seem to have this as a service specific > option, likely because the service implementation takes extra care to > implement this. So I do not think the ip-cfg module should solve this. Agreed. Lada > > /js (as contributor) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Feb 10 07:50:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B953021F85EF for ; Fri, 10 Feb 2012 07:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfzMmuSP6ywS for ; Fri, 10 Feb 2012 07:50:23 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5402621F85E7 for ; Fri, 10 Feb 2012 07:50:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 87648540A1E; Fri, 10 Feb 2012 16:50:21 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLTg67wRvb7K; Fri, 10 Feb 2012 16:50:11 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 22036540A1B; Fri, 10 Feb 2012 16:50:11 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20120208.134223.308665635.mbj@tail-f.com> References: <20120208.134223.308665635.mbj@tail-f.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Fri, 10 Feb 2012 16:50:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:50:24 -0000 Hi, I think the ietf-ip module should also define operational state data for: 1. Autoconfigured IPv6 addresses. 2. Per-interface host variables as required by RFC 4861 (sec. 6.3.2): LinkMTU, CurHopLimit, BaseReachableTime, ReachableTime and RetransTimer. Moreover, sec. 5.1 in the same RFC expects each host to maintain the following conceptual data structures: - neighbor cache - destination cache - prefix list - default router list These structures are global rather than per-interface so they do not fit into the ietf-ip module in its current form. It looks like we also need a new module, say "ip-host-cfg". Lada On Wed, 08 Feb 2012 13:42:23 +0100 (CET), Martin Bjorklund wrote: > Hi, > > I have posted an updated version of the ip-cfg draft. > > There are still some open issues; see the attached file and please > comment on these issues. > > > /martin > * ip-01 primary, secondary, and preferred address [open] > > Lada suggested that we need to specify the primary address on an > interface, and he pointed to the solution of two router vendors for > doing this. Phil sent some links to Juniper's documentation. > > It seems to be that these two vendors have the same terminology, but > different meaning of the term "primary address". In one case it > seems to be the source address used for all outgoing packets on the > interface, and in the other it seems to be the source address used > for outgoing multi- and broadcast packets. > > Phil also mentioned "preferred address", which seems to be the > source address used for outgoing unicast packets on the *subnet* > (i.e., there can be one "preferred address" per subnet on an > interface (I think)). > > So it seems there are two concepts here: > > default source on interface > > default source in subnet > > Q. Is my understanding correct? > > Q. If it is, do we need any, both, or more of these concepts? > > This was discussed at IETF-82. From the minutes: > > JS: Trying to summarize. It seems to be important that the > application running on the box can choose the source address. > It is less clear that we need something per interface. > > ** Solution #ip-01.01 > > Do not add any configration parameters for this. > > * ip-02 ipv6 auto-link-local-address leaf [open] > > Lada suggested that maybe there should be a way to tell the server > to not automatically assign a link-local unicast address for an ipv6 > interface, as defined in RFC 4862. > > Q. Is this a useful (and implementable) parameter? > > ** Solution #ip-02.01 > > If it is decided to do this... > > container ipv6 { > ... > container autoconf { > ... > leaf create-link-local-address { > type boolean; > default true; > description > "When create-link-local-address is false, a link local > unicast address MUST be configured."; > } > } > } > > ** Solution #ip-02.02 > > Since RFC 4862 does not mention that this should be configurable, do > not add such a leaf. > > * ip-03 ip enable knob [open] > > It seems useful to have a knob to enable ipv6 on an interface. When > enabled, stateless address autoconfiguration (RFC 4862) can run. > > Same for ipv4? IP-MIB has such objects (ipv4InterfaceEnableStatus > and ipv6InterfaceEnableStatus). > > (See also ip-02). > > ** Solution #ip-03.01 > > container ipv6 { > ... > leaf enabled { > type boolean; > default true; > description > "Controls if IPv6 is enabled or disabled on this > interface."; > } > } > > Ditto for IPv4. > > * ip-04 ipv6 parameters for stateless address autoconfiguration [closed] > > RFC 4862, section 5.1. states: > > A node MUST allow the following autoconfiguration-related variable to > be configured by system management for each multicast-capable > interface: > > DupAddrDetectTransmits > > Q. Should we add this leaf? > > ** Solution #ip-04.01 > > container autoconf { > ... > leaf dup-addr-detect-transmits { > type uint32; > default 1; > description > "The number of consecutive Neighbor Solicitation messages > sent while performing Duplicate Address Detection on a > tentative address. A value of zero indicates that > Duplicate Address Detection is not performed on tentative > addresses. A value of one indicates a single > transmission with no follow-up retransmissions."; > reference > "RFC 4862: IPv6 Stateless Address Autoconfiguration"; > } > } > > This issue was discussed at IETF-82. The conclusion there was that > this leaf is needed. > > ** Resolution > > Adopted #ip-04.01 > > * ip-05 ipv6 parameters for neighbor discovery [open] > > RFC 4861, section 6.2.1. states: > > A router MUST allow for the following conceptual variables to be > configured by system management. > > Q. Should we add these leaf, conditional on a feature "ipv6-router"? > > This issue was discussed at IETF-82. The conclusion there was that > these objects are needed. > > ** Solution #ip-05.01 > > Yes, we should add these parameters, but in the routing document. > (Note that in SNMP land, these objects are defined in IP-MIB) > > * ip-06 add a feature for ipv6 hosts [open] > > RFC 4862 specifies that the creation of global addresses applies > only to hosts, not to routers. Thus, should we add a feature for > ipv6 hosts? It would be used in the create-global-addresses leaf: > > leaf create-global-addresses { > // Open Issue #ip-06: should we have a feature here? > //if-feature ipv6-host; > type boolean; > default true; > description > "If enabled, the host creates global addresses as described > in section 5.5 of RFC 4862."; > reference > "RFC 4862: IPv6 Stateless Address Autoconfiguration"; > } > > Question. In RFC 4862 a host is defined as a node that is not a > router, and a router is defined as a node that forwards IP packets. > > In the IP-MIB (and in some well known OSes), ip forwarding is a > writable knob, i.e. if a node is a router or host could change > dynamically. If this is correct, we cannot make this a YANG > feature. > > ** Solution #ip-06.01 > > Yes, add this feature. > > ** Solution #ip-06.02 > > No, instead move all host-related parameters to a separate module. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From Tina.Tsou.Zouting@huawei.com Fri Feb 10 09:28:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7B821F8601 for ; Fri, 10 Feb 2012 09:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU1ANci1B8Cl for ; Fri, 10 Feb 2012 09:28:35 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 640CC21F85FF for ; Fri, 10 Feb 2012 09:28:35 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ6005VJTVCH5@szxga03-in.huawei.com> for netmod@ietf.org; Sat, 11 Feb 2012 01:28:24 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ600826TVCDE@szxga03-in.huawei.com> for netmod@ietf.org; Sat, 11 Feb 2012 01:28:24 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA75088; Sat, 11 Feb 2012 01:28:02 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 11 Feb 2012 01:27:57 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.62]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Sat, 11 Feb 2012 01:27:50 +0800 Date: Fri, 10 Feb 2012 17:27:49 +0000 From: Tina TSOU In-reply-to: To: Ladislav Lhotka Message-id: <3F429B94-D18C-4C95-9BF6-810E2F0B003B@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [netmod] ip-cfg-02 Thread-index: AQHM5l9NCwqVbeDy0EStQ8rRBO/om5Y0JsUAgADLPXH//5G5AIAAqogAgAAV1gCAAASzgIAAFdoAgAARbICAABTeAIAA4PHJ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9FA3F869-EE43-4368-8268-8971EA1D3F7F@huawei.com> <20120210.091040.414915280.mbj@tail-f.com> <20120210082729.GA17509@elstar.local> <20120210104801.GA17801@elstar.local> Cc: "netmod@ietf.org" Subject: Re: [netmod] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 17:28:36 -0000 Sent from my iPad On Feb 10, 2012, at 4:03 AM, "Ladislav Lhotka" wrote: > > On Feb 10, 2012, at 11:48 AM, Juergen Schoenwaelder wrote: > >> On Fri, Feb 10, 2012 at 10:45:42AM +0100, Ladislav Lhotka wrote: >>> >>> On Feb 10, 2012, at 9:27 AM, Juergen Schoenwaelder wrote: >>> >>>> On Fri, Feb 10, 2012 at 09:10:40AM +0100, Martin Bjorklund wrote: >>>>> Hi Tina, >>>>> >>>>> This is regarding one of the open issues. The question is if we need >>>>> to standardize a mechanism to configure the "primary" address. During >>>>> the discussion about this issue, we identified at least two (maybe >>>>> three) different concepts: >>>>> >>>>> default source on interface >>>>> >>>>> default source in subnet >>>>> >>>>> (The third is the ability to specify the source for a particular >>>>> service, e.g. use 10.0.0.1 as source when you talk to the radius >>>>> server, but 10.0.0.2 when you talk to the syslog server). >>>>> >>>>> The question now is *if* we should standardize a solution to these >>>>> problems or not. I believe Lada said "no". >>>> >>>> I think Lada said no to "default source on interface" and "default >>>> source in subnet". It still seems desirable to be able specify the >>>> default source applications/servers use. (But this is likely just a >>>> guideline for people to consider who do data models for application >>>> protocols/services - perhaps we should find a place to capture such >>>> things to consider when doing YANG configuration data models.) >>> >>> Do you mean this should be done in the ip-cfg module or elsewhere? >> >> The systems I am familiar with seem to have this as a service specific >> option, likely because the service implementation takes extra care to >> implement this. So I do not think the ip-cfg module should solve this. > > Agreed. Lada Agreed. Thank u for the clarification. > >> >> /js (as contributor) >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Sat Feb 11 04:23:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0B321F8516 for ; Sat, 11 Feb 2012 04:23:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqgyrtvqA91p for ; Sat, 11 Feb 2012 04:23:58 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3E21F8514 for ; Sat, 11 Feb 2012 04:23:58 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 67AEB12008D2; Sat, 11 Feb 2012 13:23:56 +0100 (CET) Date: Sat, 11 Feb 2012 13:23:55 +0100 (CET) Message-Id: <20120211.132355.189837832.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120208.134223.308665635.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 12:23:59 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > I think the ietf-ip module should also define operational state data for: > > 1. Autoconfigured IPv6 addresses. > > 2. Per-interface host variables as required by RFC 4861 (sec. 6.3.2): LinkMTU, > CurHopLimit, BaseReachableTime, ReachableTime and RetransTimer. > > Moreover, sec. 5.1 in the same RFC expects each host to maintain the following > conceptual data structures: > - neighbor cache > - destination cache > - prefix list > - default router list I believe most of these are present in IP-MIB, as read-only objects. Some are not, probably for a good reason. So this gets us into the question if it is a good idea to redo work already put into MIBs in YANG. For configuration data, the question has already been answered, but not for non-config. > These structures are global rather than per-interface so they do not fit into > the ietf-ip module in its current form. It looks like we also need a new > module, say "ip-host-cfg". No need for another module; the current module can define global structures as well. /martin From internet-drafts@ietf.org Mon Feb 20 11:27:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061A121F87C7; Mon, 20 Feb 2012 11:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olWAZmGqcOgw; Mon, 20 Feb 2012 11:26:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011CB21F87D3; Mon, 20 Feb 2012 11:26:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120220192639.8174.35084.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2012 11:26:39 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:27:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for Routing Configuration Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-02.txt Pages : 64 Date : 2012-02-20 This document contains a specification of four YANG modules. Together they form the core routing data model which serves as a basis for configuring a routing subsystem. It is therefore expected that this module will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such configurations - router instances, routes, routing tables, routing protocols and route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-02.txt From lhotka@nic.cz Mon Feb 20 11:40:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510C521F84CD for ; Mon, 20 Feb 2012 11:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGcQfSPr++3q for ; Mon, 20 Feb 2012 11:40:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7B21F86AF for ; Mon, 20 Feb 2012 11:40:04 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 6E2B62A2F37 for ; Mon, 20 Feb 2012 20:40:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1329766803; bh=cSjxRy9d+e7Th8N1itue45pOJTA7xGbY6UmFX+IFn5w=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=yD7zwVX+G9aeiYYH9LBlGBAQVxNVaZBc2i5obNb7Us8uOOvThVuvqISPDOBii4Bm1 EpWm5kmhXR/pSeOWOYjzPKt/ZKh3dI1Hd8Cx51Cpdl9mA7EeVD6Z/qn8ursYCVwxWK n2Mhn3Qm6JluXWpwbdZIjP+eIpsrY7Cl789BiWZ8= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 20:40:02 +0100 References: <20120220192639.8174.35084.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <850E0642-CFBE-45E4-AC93-3F1A4221914F@nic.cz> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:40:05 -0000 Hi, this is a new revision of the routing-cfg draft. Main changes compared = to -01 are: 1. New module for IPv6 unicast which includes configuration of RA = required by RFC 4861. 2. Logical interfaces must be explicitly assigned to a router instance. Please review the draft and the modules. Thanks, Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-02.txt > Date: February 20, 2012 8:26:39 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the NETCONF Data Modeling = Language Working Group of the IETF. >=20 > Title : A YANG Data Model for Routing Configuration > Author(s) : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-02.txt > Pages : 64 > Date : 2012-02-20 >=20 > This document contains a specification of four YANG modules. > Together they form the core routing data model which serves as a > basis for configuring a routing subsystem. It is therefore expected > that this module will be augmented by additional YANG modules > defining data models for individual routing protocols and other > related functions. The core routing data model provides common > building blocks for such configurations - router instances, routes, > routing tables, routing protocols and route filters. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-02.txt >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From Jonathan.Hansford@generaldynamics.uk.com Wed Feb 22 02:46:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4507A21F895B for ; Wed, 22 Feb 2012 02:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QJtTTaL+254 for ; Wed, 22 Feb 2012 02:46:21 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 177FE21F8952 for ; Wed, 22 Feb 2012 02:46:18 -0800 (PST) Received: from [85.158.137.83:49219] by server-3.bemta-3.messagelabs.com id 48/5C-06862-977C44F4; Wed, 22 Feb 2012 10:46:17 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-7.tower-140.messagelabs.com!1329907577!16970616!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11441 invoked from network); 22 Feb 2012 10:46:17 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-7.tower-140.messagelabs.com with SMTP; 22 Feb 2012 10:46:17 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 22 Feb 2012 10:46:18 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 10:46:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF14F.33AEC043" Date: Wed, 22 Feb 2012 10:46:18 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E650546206723E9E@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filenames, module names and import/include by revision Thread-Index: AczxTzUwnbtwMMvmR9iQGNnuNI3SNw== From: To: X-OriginalArrivalTime: 22 Feb 2012 10:46:19.0752 (UTC) FILETIME=[35FF0E80:01CCF14F] Subject: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 10:46:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF14F.33AEC043 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi, =20 I'm relatively new to NETCONF and YANG and am trying to understand the relationships between filenames, module names and import/include by revision. I have been digging around for some time looking for guidance and finally came across the "import-by-revision guidelines" thread starting 22/02/2009, which stated (with correction for second row in table): =20 > I plan to put a section in the YANG usage guidelines draft > about import-by-revision, but hopefully there will be > consensus on the details first. >=20 > Of course, standards-track modules MUST use revision dates, > but there are a lot of considerations for other types of > YANG modules. >=20 > The following applies to submodules/include as well. > There are 3 independent boolean variables: >=20 > importer: module with the import-stmt > yes: > import X { prefix x; revision 2009-01-01; } > no: > import X { prefix x; } >=20 >=20 > imported: module being imported > yes: > revision 2009-01-01 { description ""; } > no: // no revision-stmts >=20 > filename: > yes: > X.2009-01-01.yang > no: > X.yang >=20 > +---------------------------------+--------+ > | importer | imported | filename | result | > +-----------+----------+----------+--------+ > | no | no | no | (1) | > +-----------+----------+----------+--------+ > | no | no | yes | (2) | > +-----------+----------+----------+--------+ > | no | yes | no | (1) | > +-----------+----------+----------+--------+ > | no | yes | yes | (2) | > +-----------+----------+----------+--------+ > | yes | no | no | (3) | > +-----------+----------+----------+--------+ > | yes | no | yes | (3) | > +-----------+----------+----------+--------+ > | yes | yes | no | (4) | > +-----------+----------+----------+--------+ > | yes | yes | yes | (5) | > +-----------+----------+----------+--------+ >=20 >=20 > (1) Always accepted if any instance of module X found > (2) Search first for X.yang, which fails; > Then search for X.*.yang and return any instance > of module X found (very implementation dependent) > (3) Search fails, requested version not found > (4) If any X.yang found, it is accepted only if its highest > valued revision date matches the 'importer' value. > (5) If any X.2009-01-01.yang found, it is accepted only > if its highest valued revision date matches the > 'importer' value. =20 Can someone advise whether this guidance is still valid? It does not appear to have made it into any of the various updates to the YANG usage guidelines, which is a pity. =20 One problem I have with this table is that it doesn't explain the search order (other than for result 2). Any implementation would have no understanding of whether available files included the revision in their name or not. Result 2 implies files without the revision should be searched for first, though this appears to be at variance with the Mode 1 example on page 32 of the Yuma User Manual (v2.2). Without guidance, different implementations could have different search orders. Might this be problematic? If so, it might be better to remove the filename column from the table and explain the search order in the results. If not, that too could do with being explained. =20 Finally, according to RFC6020 Section 5.2, the file SHOULD be of the form: =20 module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) =20 Presumably that means references to X.*.yang and X.2009-01-01.yang in the guidance above should now have the first DOT replaced with an AT symbol. That also confirms (for me at least) that the import and include statements always use the module name not the filename (since the identifier cannot include an AT symbol). This, together with the recommendation in RFC6020 Section 5.2 replicated above, suggests a one-to-one mapping between files and modules. =20 Any advice gratefully received. Thanks, =20 Jonathan Hansford =20 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 ------_=_NextPart_001_01CCF14F.33AEC043 Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: 7bit X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1

Hi,

 

I’m relatively new to NETCONF and YANG and am trying to understand the relationships between filenames, module names and import/include by revision. I have been digging around for some time looking for guidance and finally came across the “import-by-revision guidelines” thread starting 22/02/2009, which stated (with correction for second row in table):

 

> I plan to put a section in the YANG usage guidelines draft
> about import-by-revision, but hopefully there will be
> consensus on the details first.
> 
> Of course, standards-track modules MUST use revision dates,
> but there are a lot of considerations for other types of
> YANG modules.
> 
> The following applies to submodules/include as well.
> There are 3 independent boolean variables:
> 
> importer: module with the import-stmt
>   yes:
>     import X { prefix x; revision 2009-01-01; }
>   no:
>     import X { prefix x; }
> 
> 
> imported: module being imported
>   yes:
>     revision 2009-01-01 { description ""; }
>   no:  // no revision-stmts
> 
> filename:
>   yes:
>      X.2009-01-01.yang
>   no:
>      X.yang
> 
>    +---------------------------------+--------+
>    |  importer | imported | filename | result |
>    +-----------+----------+----------+--------+
>    |    no     |   no     |   no     |  (1)   |
>    +-----------+----------+----------+--------+
>    |    no     |   no     |   yes    |  (2)   |
>    +-----------+----------+----------+--------+
>    |    no     |   yes    |   no     |  (1)   |
>    +-----------+----------+----------+--------+
>    |    no     |   yes    |   yes    |  (2)   |
>    +-----------+----------+----------+--------+
>    |    yes    |   no     |   no     |  (3)   |
>    +-----------+----------+----------+--------+
>    |    yes    |   no     |   yes    |  (3)   |
>    +-----------+----------+----------+--------+
>    |    yes    |   yes    |   no     |  (4)   |
>    +-----------+----------+----------+--------+
>    |    yes    |   yes    |   yes    |  (5)   |
>    +-----------+----------+----------+--------+
> 
> 
> (1) Always accepted if any instance of module X found
> (2) Search first for X.yang, which fails;
>     Then search for X.*.yang and return any instance
>     of module X found (very implementation dependent)
> (3) Search fails, requested version not found
> (4) If any X.yang found, it is accepted only if its highest
>     valued revision date matches the 'importer' value.
> (5) If any X.2009-01-01.yang found, it is accepted only
>     if its highest valued revision date matches the
>     'importer' value.
 

Can someone advise whether this guidance is still valid? It does not appear to have made it into any of the various updates to the YANG usage guidelines, which is a pity.

 

One problem I have with this table is that it doesn’t explain the search order (other than for result 2). Any implementation would have no understanding of whether available files included the revision in their name or not. Result 2 implies files without the revision should be searched for first, though this appears to be at variance with the Mode 1 example on page 32 of the Yuma User Manual (v2.2). Without guidance, different implementations could have different search orders. Might this be problematic? If so, it might be better to remove the filename column from the table and explain the search order in the results. If not, that too could do with being explained.

 

Finally, according to RFC6020 Section 5.2, the file SHOULD be of the form:

 

module-or-submodule-name [’@’ revision-date] ( ’.yang’ / ’.yin’ )

 

Presumably that means references to X.*.yang and X.2009-01-01.yang in the guidance above should now have the first DOT replaced with an AT symbol. That also confirms (for me at least) that the import and include statements always use the module name not the filename (since the identifier cannot include an AT symbol). This, together with the recommendation in RFC6020 Section 5.2 replicated above, suggests a one-to-one mapping between files and modules.

 

Any advice gratefully received. Thanks,

 

Jonathan Hansford

 

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

------_=_NextPart_001_01CCF14F.33AEC043-- From andy@netconfcentral.org Wed Feb 22 09:27:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3D21F8714 for ; Wed, 22 Feb 2012 09:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+EvWno+YfdM for ; Wed, 22 Feb 2012 09:27:00 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 619CD21F86F9 for ; Wed, 22 Feb 2012 09:26:57 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q1MHQuCn022616 for ; Wed, 22 Feb 2012 12:26:56 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:56216] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BE/17-03625-065254F4; Wed, 22 Feb 2012 12:26:56 -0500 Message-ID: <4F452565.5030701@netconfcentral.org> Date: Wed, 22 Feb 2012 09:27:01 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jonathan.Hansford@generaldynamics.uk.com References: <83C941F7F59F3F42AC017AD1E650546206723E9E@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206723E9E@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 17:27:04 -0000 On 02/22/2012 02:46 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: > Hi, > > I’m relatively new to NETCONF and YANG and am trying to understand the relationships between filenames, module names and import/include by revision. I have been digging around for some time looking > for guidance and finally came across the “import-by-revision guidelines” thread starting 22/02/2009, which stated (with correction > for second row in table): > .... (thought that text looked familiar :-) > > Can someone advise whether this guidance is still valid? It does not appear to have made it into any of the various updates to the YANG usage guidelines, which is a pity. > No it didn't make it into RFC 6087 because it wasn't really relevant to YANG module writers or reviewers. (Just implementors ;-) > One problem I have with this table is that it doesn’t explain the search order (other than for result 2). Any implementation would have no understanding of whether available files included the > revision in their name or not. Result 2 implies files without the revision should be searched for first, though this appears to be at variance with the Mode 1 example on page 32 of the Yuma User > Manual (v2.2). Without guidance, different implementations could have different search orders. Might this be problematic? If so, it might be better to remove the filename column from the table and > explain the search order in the results. If not, that too could do with being explained. > There is no search order that a tool must implement. There is no RFC that addresses a collection of YANG modules, other than the tool will magically figure out how to find the module from the imports/include statements. I have advocated for a "YANG Library" RFC in the past, but haven't really written any text (except in yuma documentation). There are lots of ways to implement this (e.g., search for all YANG first, then YIN, or search each subdir in the module path for both? What if you find a submodule when you're looking for an import? Keep looking? Error out? Do you search for all module revisions and use the newest, or use the first that you find? etc.) > Finally, according to RFC6020 Section 5.2, the file SHOULD be of the form: > > module-or-submodule-name [’@’ revision-date] ( ’.yang’ / ’.yin’ ) > > Presumably that means references to X.*.yang and X.2009-01-01.yang in the guidance above should now have the first DOT replaced with an AT symbol. That also confirms (for me at least) that the import > and include statements always use the module name not the filename (since the identifier cannot include an AT symbol). This, together with the recommendation in RFC6020 Section 5.2 replicated above, > suggests a one-to-one mapping between files and modules. > Yes -- this was changed a long time ago when we realized (duh!) that legal module name characters cannot be the separator char between fields. > Any advice gratefully received. Thanks, > > Jonathan Hansford > Andy From Jonathan.Hansford@generaldynamics.uk.com Wed Feb 22 13:52:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4070321E8039 for ; Wed, 22 Feb 2012 13:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.292 X-Spam-Level: X-Spam-Status: No, score=-4.292 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5WgFtch3Amk for ; Wed, 22 Feb 2012 13:52:25 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BB21E8022 for ; Wed, 22 Feb 2012 13:52:24 -0800 (PST) Received: from [85.158.137.35:57494] by server-9.bemta-3.messagelabs.com id BF/F2-30359-893654F4; Wed, 22 Feb 2012 21:52:24 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-13.tower-134.messagelabs.com!1329947543!12279155!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29090 invoked from network); 22 Feb 2012 21:52:23 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-13.tower-134.messagelabs.com with SMTP; 22 Feb 2012 21:52:23 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 22 Feb 2012 21:52:24 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 21:52:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF1AC.41883BA3" Date: Wed, 22 Feb 2012 21:52:18 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F452565.5030701@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: Aczxhy3fIRcLvEHJQ+S1cixwD+KUmQAJAL1w References: <83C941F7F59F3F42AC017AD1E650546206723E9E@GDUKADH850.uk1.r-org.net> <4F452565.5030701@netconfcentral.org> From: To: X-OriginalArrivalTime: 22 Feb 2012 21:52:22.0863 (UTC) FILETIME=[41DDDDF0:01CCF1AC] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:52:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF1AC.41883BA3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Unfortunately it appears the YANG Editor plugin for Eclipse was implemented without access to these guidelines as I have downloaded a number of modules from NETCONF Central, each of which include their revision in the filename (e.g. iana-if-type@2011-09-07.yang) and a revision statement. When the modules are then imported into other modules (e.g. import iana-if-type {...}, without a revision statement, as they are in various RFCs) the YANG Editor cannot find the files. =20 Might it be worth revisiting the idea of a "YANG Library" RFC? I can see similar problems occurring as more implementations are developed unless the import/include guidelines are detailed somewhere. =20 Jonathan Hansford This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 ------_=_NextPart_001_01CCF1AC.41883BA3 Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: 7bit X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1

Unfortunately it appears the YANG Editor plugin for Eclipse was implemented without access to these guidelines as I have downloaded a number of modules from NETCONF Central, each of which include their revision in the filename (e.g. iana-if-type@2011-09-07.yang) and a revision statement. When the modules are then imported into other modules (e.g. import iana-if-type {…}, without a revision statement, as they are in various RFCs) the YANG Editor cannot find the files.

 

Might it be worth revisiting the idea of a "YANG Library" RFC? I can see similar problems occurring as more implementations are developed unless the import/include guidelines are detailed somewhere.

 

Jonathan Hansford

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

------_=_NextPart_001_01CCF1AC.41883BA3-- From andy@netconfcentral.org Wed Feb 22 14:01:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0C821E803C for ; Wed, 22 Feb 2012 14:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dFhMxDby3Bw for ; Wed, 22 Feb 2012 14:01:52 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 188C821E802A for ; Wed, 22 Feb 2012 14:01:51 -0800 (PST) Received: from cm-omr8 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q1MM1nbZ005775 for ; Wed, 22 Feb 2012 17:01:49 -0500 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:56818] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CF/C0-13296-CC5654F4; Wed, 22 Feb 2012 17:01:49 -0500 Message-ID: <4F4565D2.3050308@netconfcentral.org> Date: Wed, 22 Feb 2012 14:01:54 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jonathan.Hansford@generaldynamics.uk.com References: <83C941F7F59F3F42AC017AD1E650546206723E9E@GDUKADH850.uk1.r-org.net> <4F452565.5030701@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:01:53 -0000 On 02/22/2012 01:52 PM, Jonathan.Hansford@generaldynamics.uk.com wrote: > Unfortunately it appears the YANG Editor plugin for Eclipse was implemented without access to these guidelines as I have downloaded a number of modules > from NETCONF Central, each of which include their revision in the filename (e.g. iana-if-type@2011-09-07.yang) and a revision statement. When the modules are then imported into other modules (e.g. > import iana-if-type {…}, without a revision statement, as they are in various RFCs) the YANG Editor cannot find the files. > > Might it be worth revisiting the idea of a "YANG Library" RFC? I can see similar problems occurring as more implementations are developed unless the import/include guidelines are detailed somewhere. > Perhaps -- if you install yuma the modules will be under /usr/share/yuma/modules without any dates in the names. Maybe that will help. http://sourceforge.net/projects/yuma/ > Jonathan Hansford Andy From Jonathan.Hansford@generaldynamics.uk.com Thu Feb 23 04:07:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3E921F86DF for ; Thu, 23 Feb 2012 04:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.861 X-Spam-Level: X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk5mUcetprAX for ; Thu, 23 Feb 2012 04:07:25 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9B521F86DE for ; Thu, 23 Feb 2012 04:07:24 -0800 (PST) Received: from [85.158.136.35:40591] by server-9.bemta-5.messagelabs.com id 7E/8A-30171-BFB264F4; Thu, 23 Feb 2012 12:07:23 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-4.tower-125.messagelabs.com!1329998842!13033654!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5725 invoked from network); 23 Feb 2012 12:07:22 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-4.tower-125.messagelabs.com with SMTP; 23 Feb 2012 12:07:22 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 23 Feb 2012 12:07:29 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 12:07:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 12:07:31 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F4565D2.3050308@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczxrZTyjeMG2jBBQra3p4DEFjWKrwAcP2dg References: <83C941F7F59F3F42AC017AD1E650546206723E9E@GDUKADH850.uk1.r-org.net> <4F452565.5030701@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net> <4F4565D2.3050308@netconfcentral.org> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 23 Feb 2012 12:07:21.0272 (UTC) FILETIME=[B219E380:01CCF223] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:07:26 -0000 For product vendors, the import/include search order is an implementation detail which has little impact. Even if they produce their own client, its development will probably be closely tied to the development of the product server, maybe even by the same engineers. However, for those developing a system management client for use with multiple vendors' products, any potential for ambiguity leading to conflict is no mere detail. This is further compounded if the client is a generic client that can be used to manage different systems using products, in any combination, from a wide range of vendors. Ambiguity is the curse of the system integrator and that integration takes place, at least in part, in the system management client. RFC3535 "Overview of the 2002 IAB Network Management Workshop", Section 3 "Operator Requirements", requirement 9 states: =2E.. It is desirable to extract, document, and standardize the common parts of these network wide configuration database schemas. If the search order threatens the standardisation of configuration database schemas then isn't one of the underpinnings of the NETCONF/YANG work threatened? And we then have weaknesses in our solutions that are similar to some for CLIs: - ... It is very well possible that the same command on different devices, even from the same vendor, behaves differently. - ... can not be used efficiently to automate processes in an environment with a heterogenous set of devices. As I said at the start of the thread, I am new to NETCONF and YANG and, if someone can convince me the search order is irrelevant (rather than an implementation detail), I will willingly climb down off my soapbox. Anything for an easy life! Jonathan Hansford This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From mbj@tail-f.com Thu Feb 23 05:21:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6332B21F87D7 for ; Thu, 23 Feb 2012 05:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcTdB0dAWmtt for ; Thu, 23 Feb 2012 05:21:53 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE421F87D2 for ; Thu, 23 Feb 2012 05:21:52 -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 AC5821200043; Thu, 23 Feb 2012 14:21:50 +0100 (CET) Date: Thu, 23 Feb 2012 14:21:49 +0100 (CET) Message-Id: <20120223.142149.929159853946432767.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> References: <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net> <4F4565D2.3050308@netconfcentral.org> <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:21:53 -0000 Hi, wrote: > However, for those developing a system management client for use with > multiple vendors' products, any potential for ambiguity leading to > conflict is no mere detail. This is further compounded if the client is > a generic client that can be used to manage different systems using > products, in any combination, from a wide range of vendors. IMO, how a client finds modules really is an implementation issue. One client might use the filesystem and a search path. Some other client might store all modules in some kind of database. A third client might use the operation defined in RFC 6022 to dynamically download modules from devices, and just store them internally. In the last two examples there are no filenames involved. It is important to remember that if a module uses import/incluce by revision, there is no amiguity about which version of the (sub)module it refers to. However, if a client says that it supports a module A that imports module B w/o revision, a client needs to check which version of B the device advertises. /martin From Jonathan.Hansford@generaldynamics.uk.com Thu Feb 23 05:36:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E8521F87F9 for ; Thu, 23 Feb 2012 05:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.145 X-Spam-Level: X-Spam-Status: No, score=-5.145 tagged_above=-999 required=5 tests=[AWL=0.853, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GsxyJ0maobj for ; Thu, 23 Feb 2012 05:35:59 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC721F863F for ; Thu, 23 Feb 2012 05:35:58 -0800 (PST) Received: from [85.158.136.3:62926] by server-6.bemta-5.messagelabs.com id A1/34-27305-9B0464F4; Thu, 23 Feb 2012 13:35:53 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-14.tower-123.messagelabs.com!1330004153!19755505!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25058 invoked from network); 23 Feb 2012 13:35:53 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-14.tower-123.messagelabs.com with SMTP; 23 Feb 2012 13:35:53 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 23 Feb 2012 13:35:55 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 13:35:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 13:35:57 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120223.142149.929159853946432767.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczyLhshUpe4E2r6SzWuMk5wiVBd3QAAEDMg References: <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net><4F4565D2.3050308@netconfcentral.org><83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 23 Feb 2012 13:35:51.0454 (UTC) FILETIME=[0F375BE0:01CCF230] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:36:00 -0000 But should filenames with the revision be searched for before or after those without? As stated at the start of this thread, Yuma appears to search in a different order to that suggested in the original "import-by-revision guidelines" thread. When the import statement includes a revision statement, as you say, there is no ambiguity. But when the import statement doesn't include a revision statement (as is the case with the YANG modules defined in RFCs), do you search all search paths for all files with and without revisions? And do you take the first file found, or the file with the latest revision? Jonathan Hansford -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: 23 February 2012 13:22 To: Jonathan Hansford Cc: andy@netconfcentral.org; netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision Hi, wrote: > However, for those developing a system management client for use with > multiple vendors' products, any potential for ambiguity leading to > conflict is no mere detail. This is further compounded if the client is > a generic client that can be used to manage different systems using > products, in any combination, from a wide range of vendors. IMO, how a client finds modules really is an implementation issue. One client might use the filesystem and a search path. Some other client might store all modules in some kind of database. A third client might use the operation defined in RFC 6022 to dynamically download modules from devices, and just store them internally. In the last two examples there are no filenames involved. It is important to remember that if a module uses import/incluce by revision, there is no amiguity about which version of the (sub)module it refers to. However, if a client says that it supports a module A that imports module B w/o revision, a client needs to check which version of B the device advertises. /martin This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From mbj@tail-f.com Thu Feb 23 05:47:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88421F87FB for ; Thu, 23 Feb 2012 05:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG-758tR4S9n for ; Thu, 23 Feb 2012 05:47:56 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D148F21F87D8 for ; Thu, 23 Feb 2012 05:47:55 -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 2472A12008B7; Thu, 23 Feb 2012 14:47:55 +0100 (CET) Date: Thu, 23 Feb 2012 14:47:54 +0100 (CET) Message-Id: <20120223.144754.120969355527331502.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:47:56 -0000 wrote: > But should filenames with the revision be searched for before or after > those without? As stated at the start of this thread, Yuma appears to > search in a different order to that suggested in the original > "import-by-revision guidelines" thread. When the import statement > includes a revision statement, as you say, there is no ambiguity. But > when the import statement doesn't include a revision statement (as is > the case with the YANG modules defined in RFCs), do you search all > search paths for all files with and without revisions? And do you take > the first file found, or the file with the latest revision? If you know which revision you are looking for, either b/c import by revision was used, or the server advertises the revision it implements, then there is no problem, right? And per 6020, the server MUST advertise the revision, so you actually know the revision to look for in your generic client. /martin From Jonathan.Hansford@generaldynamics.uk.com Thu Feb 23 05:52:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF03121F8800 for ; Thu, 23 Feb 2012 05:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9Hd0X6d+r8G for ; Thu, 23 Feb 2012 05:52:26 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8A21F87F9 for ; Thu, 23 Feb 2012 05:52:09 -0800 (PST) Received: from [85.158.137.35:54574] by server-6.bemta-3.messagelabs.com id 24/BD-26935-884464F4; Thu, 23 Feb 2012 13:52:08 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-14.tower-134.messagelabs.com!1330005128!18161733!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2752 invoked from network); 23 Feb 2012 13:52:08 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-14.tower-134.messagelabs.com with SMTP; 23 Feb 2012 13:52:08 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 23 Feb 2012 13:52:10 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 13:52:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 13:52:12 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E6505462067242E6@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120223.144754.120969355527331502.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczyMb9XG9TUAuh3ROSi9KXByA0kSwAAEGjA References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net><20120223.142149.929159853946432767.mbj@tail-f.com><83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <20120223.144754.120969355527331502.mbj@tail-f.com> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 23 Feb 2012 13:52:06.0519 (UTC) FILETIME=[54667870:01CCF232] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:52:28 -0000 Thanks. I'll climb down off my soapbox for now. I'm almost convinced! I obviously need to go away and do some more reading. Jonathan Hansford -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: 23 February 2012 13:48 To: Jonathan Hansford Cc: andy@netconfcentral.org; netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision wrote: > But should filenames with the revision be searched for before or after > those without? As stated at the start of this thread, Yuma appears to > search in a different order to that suggested in the original > "import-by-revision guidelines" thread. When the import statement > includes a revision statement, as you say, there is no ambiguity. But > when the import statement doesn't include a revision statement (as is > the case with the YANG modules defined in RFCs), do you search all > search paths for all files with and without revisions? And do you take > the first file found, or the file with the latest revision? If you know which revision you are looking for, either b/c import by revision was used, or the server advertises the revision it implements, then there is no problem, right? And per 6020, the server MUST advertise the revision, so you actually know the revision to look for in your generic client. /martin This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From Jonathan.Hansford@generaldynamics.uk.com Thu Feb 23 06:43:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA4F21F8847 for ; Thu, 23 Feb 2012 06:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9K+gKAMiTwU for ; Thu, 23 Feb 2012 06:43:16 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id AE26321F881E for ; Thu, 23 Feb 2012 06:43:15 -0800 (PST) Received: from [85.158.137.83:53196] by server-11.bemta-3.messagelabs.com id EC/CD-01931-280564F4; Thu, 23 Feb 2012 14:43:14 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-15.tower-140.messagelabs.com!1330008194!17176335!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16067 invoked from network); 23 Feb 2012 14:43:14 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-15.tower-140.messagelabs.com with SMTP; 23 Feb 2012 14:43:14 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 23 Feb 2012 14:43:17 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 14:43:12 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 14:43:19 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> In-Reply-To: <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczyMb9XG9TUAuh3ROSi9KXByA0kSwAAEGjAAAFxiNA= References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net><20120223.142149.929159853946432767.mbj@tail-f.com><83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <20120223.144754.120969355527331502.mbj@tail-f.com> <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 23 Feb 2012 14:43:12.0636 (UTC) FILETIME=[77F2CBC0:01CCF239] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:43:17 -0000 Apologies, but I'm just going to be back up on my soapbox, very briefly. This thread started, not because I'm implementing a client of server. I haven't got that far yet. I have been trying to use a free YANG editor to get up-to-speed. Unfortunately it doesn't find YANG files with the revision in the filename, whether the import includes a revision statement or not. 6020 is of no help for a YANG editor as there is no server to advertise the revision. Obviously the editor's developer was not aware of the need to search for files both with and without the revision.=20 How can they and other developers become aware of this issue without some guidance? I only became aware of the original thread from 2009 because I don't give up easily (as you've probably noticed). Jonathan Hansford This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From j.schoenwaelder@jacobs-university.de Thu Feb 23 06:51:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EC021F8809 for ; Thu, 23 Feb 2012 06:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuOriR0aXq+S for ; Thu, 23 Feb 2012 06:51:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 78F4B21F87F3 for ; Thu, 23 Feb 2012 06:51:01 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73BE820CDA; Thu, 23 Feb 2012 15:51:00 +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 FZdeR4gCWfwQ; Thu, 23 Feb 2012 15:51:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18FF320CB7; Thu, 23 Feb 2012 15:51:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DE8511D832CB; Thu, 23 Feb 2012 15:50:58 +0100 (CET) Date: Thu, 23 Feb 2012 15:50:58 +0100 From: Juergen Schoenwaelder To: Jonathan.Hansford@generaldynamics.uk.com Message-ID: <20120223145058.GC94243@elstar.local> Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, mbj@tail-f.com, netmod@ietf.org References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <20120223.144754.120969355527331502.mbj@tail-f.com> <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 14:51:13 -0000 On Thu, Feb 23, 2012 at 02:43:19PM +0000, Jonathan.Hansford@generaldynamics.uk.com wrote: > Apologies, but I'm just going to be back up on my soapbox, very briefly. > > This thread started, not because I'm implementing a client of server. I > haven't got that far yet. I have been trying to use a free YANG editor > to get up-to-speed. Unfortunately it doesn't find YANG files with the > revision in the filename, whether the import includes a revision > statement or not. 6020 is of no help for a YANG editor as there is no > server to advertise the revision. Obviously the editor's developer was > not aware of the need to search for files both with and without the > revision. > > How can they and other developers become aware of this issue without > some guidance? I only became aware of the original thread from 2009 > because I don't give up easily (as you've probably noticed). It might be reasonable to write some implementation guidelines document at some point in time. However, import by revision and the file name layout is defined in RFC 6020 section 5.2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Feb 23 06:54:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF06F21F872F for ; Thu, 23 Feb 2012 06:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E+3Yea6+SR5 for ; Thu, 23 Feb 2012 06:54:22 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3298121F871B for ; Thu, 23 Feb 2012 06:54:13 -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 725761200043; Thu, 23 Feb 2012 15:54:12 +0100 (CET) Date: Thu, 23 Feb 2012 15:54:11 +0100 (CET) Message-Id: <20120223.155411.862062938162692614.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> References: <20120223.144754.120969355527331502.mbj@tail-f.com> <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:54:22 -0000 wrote: > Apologies, but I'm just going to be back up on my soapbox, very briefly. > > This thread started, not because I'm implementing a client of server. I > haven't got that far yet. I have been trying to use a free YANG editor > to get up-to-speed. Unfortunately it doesn't find YANG files with the > revision in the filename, whether the import includes a revision > statement or not. 6020 is of no help for a YANG editor as there is no > server to advertise the revision. Obviously the editor's developer was > not aware of the need to search for files both with and without the > revision. I think we did what we could in 6020 when we stated: YANG modules and submodules are typically stored in files, one module or submodule per file. The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) YANG compilers can find imported modules and included submodules via this convention. The reason we did write this is that for MIBs, different tools have different conventions, for example no file suffix, ".mib", ".my", ".txt". With YANG we wanted to at least recommend a common file name convention. /martin From Jonathan.Hansford@generaldynamics.uk.com Thu Feb 23 06:56:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0979521F8809 for ; Thu, 23 Feb 2012 06:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huRO4Xo5n0kC for ; Thu, 23 Feb 2012 06:56:19 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id CE54721F87B6 for ; Thu, 23 Feb 2012 06:56:18 -0800 (PST) Received: from [85.158.137.67:31874] by server-5.bemta-3.messagelabs.com id 18/1D-09139-293564F4; Thu, 23 Feb 2012 14:56:18 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-12.tower-139.messagelabs.com!1330008977!16406022!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6588 invoked from network); 23 Feb 2012 14:56:17 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-12.tower-139.messagelabs.com with SMTP; 23 Feb 2012 14:56:17 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 23 Feb 2012 14:56:20 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 14:56:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 14:56:23 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E65054620672434D@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120223145058.GC94243@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczyOo+h6ndf/CP0QpuqC6UGfe6ApAAACjZg References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <20120223.144754.120969355527331502.mbj@tail-f.com> <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> <20120223145058.GC94243@elstar.local> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 23 Feb 2012 14:56:16.0095 (UTC) FILETIME=[4AED26F0:01CCF23B] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:56:20 -0000 It might be reasonable to infer from 6020 that an include statement with a revision statement should look for files with the revision in the filename. But is it also reasonable to infer that it should look for files without the revision in the filename? Or to infer that an include statement without a revision statement should look for files with the revision in the filename? And those are all inferences that someone could easily overlook. Jonathan Hansford -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: 23 February 2012 14:51 To: Jonathan Hansford Cc: mbj@tail-f.com; netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision On Thu, Feb 23, 2012 at 02:43:19PM +0000, Jonathan.Hansford@generaldynamics.uk.com wrote: > Apologies, but I'm just going to be back up on my soapbox, very briefly. >=20 > This thread started, not because I'm implementing a client of server. I > haven't got that far yet. I have been trying to use a free YANG editor > to get up-to-speed. Unfortunately it doesn't find YANG files with the > revision in the filename, whether the import includes a revision > statement or not. 6020 is of no help for a YANG editor as there is no > server to advertise the revision. Obviously the editor's developer was > not aware of the need to search for files both with and without the > revision. > > How can they and other developers become aware of this issue without > some guidance? I only became aware of the original thread from 2009 > because I don't give up easily (as you've probably noticed). It might be reasonable to write some implementation guidelines document at some point in time. However, import by revision and the file name layout is defined in RFC 6020 section 5.2. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From j.schoenwaelder@jacobs-university.de Thu Feb 23 07:04:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5B721F85A8 for ; Thu, 23 Feb 2012 07:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqAO3QwKmFC2 for ; Thu, 23 Feb 2012 07:04:27 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 47D1D21F859B for ; Thu, 23 Feb 2012 07:04:27 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EED920CE2; Thu, 23 Feb 2012 16:04:26 +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 X7M21EFPxW5N; Thu, 23 Feb 2012 16:04:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24E5B20CDA; Thu, 23 Feb 2012 16:04:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 657391D83428; Thu, 23 Feb 2012 16:04:24 +0100 (CET) Date: Thu, 23 Feb 2012 16:04:24 +0100 From: Juergen Schoenwaelder To: Jonathan.Hansford@generaldynamics.uk.com Message-ID: <20120223150423.GA94626@elstar.local> Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, mbj@tail-f.com, netmod@ietf.org References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <20120223.144754.120969355527331502.mbj@tail-f.com> <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> <20120223145058.GC94243@elstar.local> <83C941F7F59F3F42AC017AD1E65054620672434D@GDUKADH850.uk1.r-org.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83C941F7F59F3F42AC017AD1E65054620672434D@GDUKADH850.uk1.r-org.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 15:04:28 -0000 Jonathan, if you want to start a draft on implementation guidelines, by all means, please do so. I am not saying everything is totally obvious from the specs. (And I guess this is even more true for NETCONF than it is for YANG.) Having a NETCONF / YANG implementation guidelines document at some point in time might really be useful. /js On Thu, Feb 23, 2012 at 02:56:23PM +0000, Jonathan.Hansford@generaldynamics.uk.com wrote: > It might be reasonable to infer from 6020 that an include statement with > a revision statement should look for files with the revision in the > filename. But is it also reasonable to infer that it should look for > files without the revision in the filename? Or to infer that an include > statement without a revision statement should look for files with the > revision in the filename? And those are all inferences that someone > could easily overlook. > > Jonathan Hansford > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 23 February 2012 14:51 > To: Jonathan Hansford > Cc: mbj@tail-f.com; netmod@ietf.org > Subject: Re: [netmod] Filenames, module names and import/include by > revision > > On Thu, Feb 23, 2012 at 02:43:19PM +0000, > Jonathan.Hansford@generaldynamics.uk.com wrote: > > Apologies, but I'm just going to be back up on my soapbox, very > briefly. > > > > This thread started, not because I'm implementing a client of server. > I > > haven't got that far yet. I have been trying to use a free YANG editor > > to get up-to-speed. Unfortunately it doesn't find YANG files with the > > revision in the filename, whether the import includes a revision > > statement or not. 6020 is of no help for a YANG editor as there is no > > server to advertise the revision. Obviously the editor's developer was > > not aware of the need to search for files both with and without the > > revision. > > > > How can they and other developers become aware of this issue without > > some guidance? I only became aware of the original thread from 2009 > > because I don't give up easily (as you've probably noticed). > > It might be reasonable to write some implementation guidelines > document at some point in time. However, import by revision and the > file name layout is defined in RFC 6020 section 5.2. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > > This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Jonathan.Hansford@generaldynamics.uk.com Thu Feb 23 07:12:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AAD21F87D3 for ; Thu, 23 Feb 2012 07:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg+p8C8+uUOf for ; Thu, 23 Feb 2012 07:12:45 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCF121F87CB for ; Thu, 23 Feb 2012 07:12:45 -0800 (PST) Received: from [85.158.136.35:31750] by server-2.bemta-5.messagelabs.com id 6D/3D-20263-C67564F4; Thu, 23 Feb 2012 15:12:44 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-10.tower-125.messagelabs.com!1330009963!19373262!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25377 invoked from network); 23 Feb 2012 15:12:44 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-10.tower-125.messagelabs.com with SMTP; 23 Feb 2012 15:12:44 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 23 Feb 2012 15:12:46 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 15:12:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 15:12:49 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E65054620672435F@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120223150423.GA94626@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczyPHBNeAsgNEmsS8CY3ssKCFETaAAAI2Ow References: <83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <20120223.144754.120969355527331502.mbj@tail-f.com> <5DE0E62DF5C3C544AA1A689942AAECB803AD3776F0@GDUKADH850.uk1.r-org.net> <83C941F7F59F3F42AC017AD1E65054620672432D@GDUKADH850.uk1.r-org.net> <20120223145058.GC94243@elstar.local> <83C941F7F59F3F42AC017AD1E65054620672434D@GDUKADH850.uk1.r-org.net> <20120223150423.GA94626@elstar.local> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 23 Feb 2012 15:12:42.0317 (UTC) FILETIME=[96C2AFD0:01CCF23D] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:12:46 -0000 As I've said, I'm new to both NETCONF and YANG, and haven't implemented anything yet. I'd be willing to help, but you'd be waiting a long time (and get an awful lot of emails from me) before I would even know where to start, let alone have anything to deliver. And I'm sure there are other guidelines buried in the NETMOD Discussion Archive that I haven't unearthed yet. Jonathan Hansford -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: 23 February 2012 15:04 To: Jonathan Hansford Cc: mbj@tail-f.com; netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision Jonathan, if you want to start a draft on implementation guidelines, by all means, please do so. I am not saying everything is totally obvious from the specs. (And I guess this is even more true for NETCONF than it is for YANG.) Having a NETCONF / YANG implementation guidelines document at some point in time might really be useful. /js On Thu, Feb 23, 2012 at 02:56:23PM +0000, Jonathan.Hansford@generaldynamics.uk.com wrote: > It might be reasonable to infer from 6020 that an include statement with > a revision statement should look for files with the revision in the > filename. But is it also reasonable to infer that it should look for > files without the revision in the filename? Or to infer that an include > statement without a revision statement should look for files with the > revision in the filename? And those are all inferences that someone > could easily overlook. >=20 > Jonathan Hansford >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: 23 February 2012 14:51 > To: Jonathan Hansford > Cc: mbj@tail-f.com; netmod@ietf.org > Subject: Re: [netmod] Filenames, module names and import/include by > revision >=20 > On Thu, Feb 23, 2012 at 02:43:19PM +0000, > Jonathan.Hansford@generaldynamics.uk.com wrote: > > Apologies, but I'm just going to be back up on my soapbox, very > briefly. > >=20 > > This thread started, not because I'm implementing a client of server. > I > > haven't got that far yet. I have been trying to use a free YANG editor > > to get up-to-speed. Unfortunately it doesn't find YANG files with the > > revision in the filename, whether the import includes a revision > > statement or not. 6020 is of no help for a YANG editor as there is no > > server to advertise the revision. Obviously the editor's developer was > > not aware of the need to search for files both with and without the > > revision. > > > > How can they and other developers become aware of this issue without > > some guidance? I only became aware of the original thread from 2009 > > because I don't give up easily (as you've probably noticed). >=20 > It might be reasonable to write some implementation guidelines > document at some point in time. However, import by revision and the > file name layout is defined in RFC 6020 section 5.2. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 >=20 > This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From andy@netconfcentral.org Thu Feb 23 09:27:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71221F87C7 for ; Thu, 23 Feb 2012 09:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-9XA254jfmd for ; Thu, 23 Feb 2012 09:27:32 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7170E21F87BE for ; Thu, 23 Feb 2012 09:27:31 -0800 (PST) Received: from cm-omr7 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q1NHRU8f007882 for ; Thu, 23 Feb 2012 12:27:30 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59492] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 73/07-06986-107764F4; Thu, 23 Feb 2012 12:27:30 -0500 Message-ID: <4F467707.8060701@netconfcentral.org> Date: Thu, 23 Feb 2012 09:27:35 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jonathan.Hansford@generaldynamics.uk.com References: <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net><4F4565D2.3050308@netconfcentral.org><83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:27:32 -0000 On 02/23/2012 05:35 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: > But should filenames with the revision be searched for before or after > those without? As stated at the start of this thread, Yuma appears to > search in a different order to that suggested in the original > "import-by-revision guidelines" thread. When the import statement > includes a revision statement, as you say, there is no ambiguity. But > when the import statement doesn't include a revision statement (as is > the case with the YANG modules defined in RFCs), do you search all > search paths for all files with and without revisions? And do you take > the first file found, or the file with the latest revision? > Sounds like the editor you are using does not support revisions at all. If the user requests a specific revision, then the revision-date must be found in the module, and it must match the requested date. Not sure why RFC 6020 says this is a SHOULD instead of a MUST. Sec. 5.2 offers no guidance wrt/ why a compliant implementation can choose not to support it. > Jonathan Hansford Andy > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 23 February 2012 13:22 > To: Jonathan Hansford > Cc: andy@netconfcentral.org; netmod@ietf.org > Subject: Re: [netmod] Filenames, module names and import/include by > revision > > Hi, > > wrote: >> However, for those developing a system management client for use with >> multiple vendors' products, any potential for ambiguity leading to >> conflict is no mere detail. This is further compounded if the client > is >> a generic client that can be used to manage different systems using >> products, in any combination, from a wide range of vendors. > > IMO, how a client finds modules really is an implementation issue. > > One client might use the filesystem and a search path. > > Some other client might store all modules in some kind of database. > > A third client might use the operation defined in RFC > 6022 to dynamically download modules from devices, and just store them > internally. > > In the last two examples there are no filenames involved. > > It is important to remember that if a module uses import/incluce by > revision, there is no amiguity about which version of the (sub)module > it refers to. However, if a client says that it supports a module A > that imports module B w/o revision, a client needs to check which > version of B the device advertises. > > > /martin > > > This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. > > From Jonathan.Hansford@generaldynamics.uk.com Fri Feb 24 01:43:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B42F21F88FB for ; Fri, 24 Feb 2012 01:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lymxrab6PSuf for ; Fri, 24 Feb 2012 01:42:58 -0800 (PST) Received: from mail91.messagelabs.com (mail91.messagelabs.com [194.106.220.35]) by ietfa.amsl.com (Postfix) with SMTP id 3C4FC21F88FA for ; Fri, 24 Feb 2012 01:42:57 -0800 (PST) X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-12.tower-91.messagelabs.com!1330076576!63343288!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20219 invoked from network); 24 Feb 2012 09:42:56 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-12.tower-91.messagelabs.com with SMTP; 24 Feb 2012 09:42:56 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 24 Feb 2012 09:42:58 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 09:42:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 09:42:54 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E6505462067244B6@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F467707.8060701@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Filenames, module names and import/include by revision Thread-Index: AczyUG3XTODBaU8KQ1WbAaFyxOKUjwAiB/lQ References: <83C941F7F59F3F42AC017AD1E6505462067240D7@GDUKADH850.uk1.r-org.net><4F4565D2.3050308@netconfcentral.org><83C941F7F59F3F42AC017AD1E650546206724271@GDUKADH850.uk1.r-org.net> <20120223.142149.929159853946432767.mbj@tail-f.com> <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <4F467707.8060701@netconfcentral.org> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 24 Feb 2012 09:42:56.0166 (UTC) FILETIME=[AFB56460:01CCF2D8] Cc: netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:43:00 -0000 To be fair to the editor, I meant "with and without revisions in the filename", not with and without revision statements.=20 Looking at the code for the emacs and vim editors at YANG Central, they don't appear to parse import/include statements unlike the editor I've been testing. It seeks to validate the source file and generates an error because it doesn't include filenames with revision dates in the search path. I guess if I want to go for a full YANG-aware editor I'll have to get one of the commercial offerings. Jonathan Hansford > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.org] > Sent: 23 February 2012 17:28 > To: Jonathan Hansford > Cc: mbj@tail-f.com; netmod@ietf.org > Subject: Re: [netmod] Filenames, module names and import/include by > revision >=20 > On 02/23/2012 05:35 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: > > But should filenames with the revision be searched for before or after > > those without? As stated at the start of this thread, Yuma appears to > > search in a different order to that suggested in the original > > "import-by-revision guidelines" thread. When the import statement > > includes a revision statement, as you say, there is no ambiguity. But > > when the import statement doesn't include a revision statement (as is > > the case with the YANG modules defined in RFCs), do you search all > > search paths for all files with and without revisions? And do you take > > the first file found, or the file with the latest revision? > > >=20 >=20 > Sounds like the editor you are using does not support revisions at all. >=20 > If the user requests a specific revision, then the revision-date > must be found in the module, and it must match the requested date. >=20 > Not sure why RFC 6020 says this is a SHOULD instead of a MUST. > Sec. 5.2 offers no guidance wrt/ why a compliant implementation > can choose not to support it. >=20 >=20 > > Jonathan Hansford >=20 > Andy This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From mbj@tail-f.com Fri Feb 24 02:17:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A721F8917 for ; Fri, 24 Feb 2012 02:17:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yunP70VRfl+C for ; Fri, 24 Feb 2012 02:17:37 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50E21F8919 for ; Fri, 24 Feb 2012 02:17:37 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C7401200B84; Fri, 24 Feb 2012 11:17:35 +0100 (CET) Date: Fri, 24 Feb 2012 11:17:34 +0100 (CET) Message-Id: <20120224.111734.184992230.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067244B6@GDUKADH850.uk1.r-org.net> References: <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <4F467707.8060701@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462067244B6@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:17:38 -0000 wrote: > I guess if I want to go for a full YANG-aware editor I'll have to get > one of the commercial offerings. If you like emacs, you can combine the yang-mode with flymake, configured to use pyang or yangdump as the syntax checker. It doesn't give you all the bells and whistles that the commercial editors give you, but it might be useful anyway. For pyang, put this in your .emacs: (require 'flymake) (defun flymake-yang-init () (let* ((temp-file (flymake-init-create-temp-buffer-copy 'flymake-create-temp-inplace)) (local-file (file-relative-name temp-file (file-name-directory buffer-file-name)))) (list "pyang" (list local-file)))) ; try this to enforce the canonical form ; (list "pyang" (list "--canonical " local-file)))) (setq flymake-allowed-file-name-masks (cons '(".+\\.yang$" flymake-yang-init flymake-simple-cleanup flymake-get-real-file-name) flymake-allowed-file-name-masks)) Make sure you have pyang in your path, fire up emacs, and open a .yang file. Hoover over the highlighed lines to see the error / warning message. If you try this you will notice that pyang complains about the flymake-generated filename. That should be easy to fix. /martin From lhotka@nic.cz Fri Feb 24 04:00:51 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2151521F888F for ; Fri, 24 Feb 2012 04:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KooupNC8IHKm for ; Fri, 24 Feb 2012 04:00:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6D721F8882 for ; Fri, 24 Feb 2012 04:00:50 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id C7B1F2A02E4; Fri, 24 Feb 2012 13:00:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330084848; bh=0/HDh0/HXbMdgdIxJUIGJDmZ81uE2fSSSgYLZ+4di6g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HbTHp77xvFA8NwHOuI5XtxOKjqIawy+UFuW8Gui9yGeQuQyoLZBS1izicSDoqwc2R 2rfJJePW+ebd43TmjvKdSLlLBq+Ja6Kret/kSX429KDyDMjQXNOsIZHAhUuMpdD+74 MldtEllHElJt+JtM+jm5fEAixRtrKIIB+3G7m6HI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120224.111734.184992230.mbj@tail-f.com> Date: Fri, 24 Feb 2012 13:00:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5735D847-E156-42B8-9815-8195276C874E@nic.cz> References: <83C941F7F59F3F42AC017AD1E6505462067242D6@GDUKADH850.uk1.r-org.net> <4F467707.8060701@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462067244B6@GDUKADH850.uk1.r-org.net> <20120224.111734.184992230.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] Filenames, module names and import/include by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 12:00:51 -0000 On Feb 24, 2012, at 11:17 AM, Martin Bjorklund wrote: > wrote: >> I guess if I want to go for a full YANG-aware editor I'll have to get >> one of the commercial offerings. >=20 > If you like emacs, you can combine the yang-mode with flymake, > configured to use pyang or yangdump as the syntax checker. It doesn't > give you all the bells and whistles that the commercial editors give > you, but it might be useful anyway. Actually, if you don't get sick when seeing XML, you can use emacs + = nxml mode as a really full YANG-aware editor, with context-sensitive = autocompletion of YANG commands and on-the-fly validation. Of course, = the flip side is that you have to write modules in the YIN format. (I do = it all the time.) Just use the RELAX NG schema for YIN which is included in pyang = distribution. Lada =20 >=20 > For pyang, put this in your .emacs: >=20 > (require 'flymake) >=20 > (defun flymake-yang-init () > (let* ((temp-file (flymake-init-create-temp-buffer-copy > 'flymake-create-temp-inplace)) > (local-file (file-relative-name > temp-file > (file-name-directory buffer-file-name)))) > (list "pyang" (list local-file)))) > ; try this to enforce the canonical form > ; (list "pyang" (list "--canonical " local-file)))) >=20 > (setq flymake-allowed-file-name-masks > (cons '(".+\\.yang$" > flymake-yang-init > flymake-simple-cleanup > flymake-get-real-file-name) > flymake-allowed-file-name-masks)) >=20 > Make sure you have pyang in your path, fire up emacs, and open a .yang > file. Hoover over the highlighed lines to see the error / warning > message. If you try this you will notice that pyang complains about > the flymake-generated filename. That should be easy to fix. >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Feb 29 05:11:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F9E21F87E2 for ; Wed, 29 Feb 2012 05:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nip0FwMhuGEQ for ; Wed, 29 Feb 2012 05:11:40 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 40A5921F87E0 for ; Wed, 29 Feb 2012 05:11:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 044B75401E1 for ; Wed, 29 Feb 2012 14:11:34 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Esxqw1WLbwN for ; Wed, 29 Feb 2012 14:11:19 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1EEAD54011F for ; Wed, 29 Feb 2012 14:11:19 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 29 Feb 2012 14:11:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 13:11:41 -0000 Hi, this is my review od the ip-cfg-02 draft module. Some of the issues have already been discussed. *** Proposed changes 1. (ad issue #ip-02.02) Change "ipv4" and "ipv6" nodes into presence containers but keep the "enabled" knob. In the current version, IPv6 is enabled on an interface even if the "ipv6" container is not present and there is no other mention about IPv6. If "ipv6" becomes a presence container, three states of the configuration are possible: - no IPv6 configuration is present => IPv6 is disabled - IPv6 configuration is present but IPv6 disabled via enabled=false. - IPv6 configuration is present and IPv6 enabled. 2. Put the "address" list into a container, e.g. "addresses". Reason: avoid interleaving the addresses with other nodes, e.g.
...
...
...
3. Add boolean leaf "is-router" (or "ip-forwarding") under both "ipv4" and "ipv6". For IPv6, this configuration variable is required by RFC 4861, sec. 6.2.1 and IMO belongs to this module. The other router-specific configuration variables from that section are defined in the 'routing-cfg' module. The leaf "create-global-addresses" then should have a dynamic default equal to not(is-router). 4. Add a config=false list of all addresses on an interface (manually or automatically configured). 5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false for all): - link-mtu - cur-hop-limit - base-reachable-time - reachable-time - retrans-timer 6. Add the following global (i.e. not per-interface) config=false structures as required by RFC 4861, sec. 5.1.: - neighbour cache - routing table Do the same also for IPv4. *** Formal - p. 4: s/familiy/family/ Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Wed Feb 29 13:14:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875921F8798 for ; Wed, 29 Feb 2012 13:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kySkGdMCAA+V for ; Wed, 29 Feb 2012 13:14:57 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3374821F8712 for ; Wed, 29 Feb 2012 13:14:57 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q1TLEAhK025314 for ; Wed, 29 Feb 2012 16:14:55 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:47469] helo=[192.168.0.9]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 32/56-25595-F459E4F4; Wed, 29 Feb 2012 16:14:55 -0500 Message-ID: <4F4E9559.2000008@netconfcentral.org> Date: Wed, 29 Feb 2012 13:15:05 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:14:58 -0000 Hi, I was trying to update the modules on netconfcentral.org, and yangdump is complaining about ietf-routing.yang. 1 fatal error and some warnings. unique "interfaces/interface/name"; Error: list node (interface) within unique stmt 'interfaces/interface/name' for node 'interfaces/interface/name' ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node A unique-stmt for container/list/leaf is not allowed. Only container and leaf are allowed. RFC 6020 may not be clear on this. Martin should fix it ;-) It can work if there is only 1 node in the 'uniqueness tuple and only 1 list in the path. But except for that special case, list cannot deterministically produce a set of instances that belong to the same tuple, for comparison to another tuple. If I comment out the unique-stmt, then I get these warnings from ipv4 and ipv6 modules: Warning: sibling object 'address' already defined in module 'ietf-ipv4-unicast-routing' at line 85 ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling node name from external augment Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment These warnings are because each module does an external augment on the same target, using the same 'route-content' grouping. So all siblings have duplicate local-names in different namespaces. I really think it sets a bad precedent to intentionally cause local-name collisions -- to be as XML namespace dependent as possible. The user-friendly thing to do would be to always add your own sub-container. This is how CLI keeps things straight. E.g.: (note container insertion before 'uses route-content') augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" + "rt:routes/rt:route" { when "../../rt:address-family='ipV4' and " + "../../rt:safi='nlri-unicast'" { description "This augment is valid only for IPv4 unicast."; } description "This augment defines the content of IPv4 unicast routes."; container ipv4-unicast { uses route-content; } } augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" + "rt:routes/rt:route" { when "../../rt:address-family='ipV6' and " + "../../rt:safi='nlri-unicast'" { description "This augment is valid only for IPv6 unicast."; } description "This augment defines the content of IPv6 unicast routes."; container ipv6-unicast { uses route-content; } } } Andy From lhotka@cesnet.cz Wed Feb 29 23:59:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4D321E803E for ; Wed, 29 Feb 2012 23:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-SzNeLzMJ2o for ; Wed, 29 Feb 2012 23:59:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3528E21E8056 for ; Wed, 29 Feb 2012 23:59:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6E5C354095C; Thu, 1 Mar 2012 08:59:10 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvWDeAZX33o7; Thu, 1 Mar 2012 08:59:07 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 012F95400E7; Thu, 1 Mar 2012 08:59:07 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , NETMOD Working Group In-Reply-To: <4F4E9559.2000008@netconfcentral.org> References: <4F4E9559.2000008@netconfcentral.org> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Andy Bierman , NETMOD Working Group Date: Thu, 01 Mar 2012 08:59:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 07:59:15 -0000 On Wed, 29 Feb 2012 13:15:05 -0800, Andy Bierman wrote: > Hi, > > I was trying to update the modules on netconfcentral.org, and yangdump > is complaining about ietf-routing.yang. 1 fatal error and some warnings. > > unique "interfaces/interface/name"; > > Error: list node (interface) within unique stmt 'interfaces/interface/name' for node 'interfaces/interface/name' > ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node > > > A unique-stmt for container/list/leaf is not allowed. Only container and leaf are allowed. > RFC 6020 may not be clear on this. Martin should fix it ;-) I did check the spec before writing that statement, and it doesn't seem to exclude this case. The use case is clear: partition the list of logical interfaces into sublists and make sure the sublists are disjoint. > > It can work if there is only 1 node in the 'uniqueness tuple and only 1 list in the path. > But except for that special case, list cannot deterministically produce a set of instances > that belong to the same tuple, for comparison to another tuple. I think it is a matter of definition, and IMO a reasonable definition is in RFC 6110, sec. 12.16. Of course, I could change the 'unique' statement into 'must' along these lines but that would be much less readable. > > If I comment out the unique-stmt, then I get these warnings from ipv4 and ipv6 modules: > > Warning: sibling object 'address' already defined in module 'ietf-ipv4-unicast-routing' at line 85 > ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 > ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 > ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 > ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 > ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 > ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 > ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment > > These warnings are because each module does an external augment on > the same target, using the same 'route-content' grouping. So all siblings > have duplicate local-names in different namespaces. I don't see it as a problem. We have next-hop for both IPv4 and for IPv6, named v4ur:next-hop and v6ur:next-hop. Moreover, the augments are conditional so that these two can never become siblings - in fact, they cannot be in the same routing table. > > I really think it sets a bad precedent to intentionally cause local-name > collisions -- to be as XML namespace dependent as possible. For me namespaces is one of the few reasons for using XML rather than, e.g., JSON. > The user-friendly thing to do would be to always add your own sub-container. With subcontainers you cannot use leafrefs effectively. That's why we have a flat list of interfaces. > This is how CLI keeps things straight. E.g.: > (note container insertion before 'uses route-content') > Each 'routing-table' already has 'address-family' and 'safi' as its children, so it makes little sense to carry the redundant address family information in each route: ipV6 nlri-unicast ... ... ... With 250K routes this can already make a difference. Lada > > augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" > + "rt:routes/rt:route" { > when "../../rt:address-family='ipV4' and " > + "../../rt:safi='nlri-unicast'" { > description > "This augment is valid only for IPv4 unicast."; > } > description > "This augment defines the content of IPv4 unicast routes."; > > container ipv4-unicast { > uses route-content; > } > } > > augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" > + "rt:routes/rt:route" { > when "../../rt:address-family='ipV6' and " > + "../../rt:safi='nlri-unicast'" { > description > "This augment is valid only for IPv6 unicast."; > } > description > "This augment defines the content of IPv6 unicast routes."; > container ipv6-unicast { > uses route-content; > } > } > } > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C