From simon.leinen@switch.ch Sun Sep 2 13:52: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 4E7DA21F8476 for ; Sun, 2 Sep 2012 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi+-kFUbrWRT for ; Sun, 2 Sep 2012 13:52:53 -0700 (PDT) Received: from elenski.switch.ch (elenski.switch.ch [IPv6:2001:620:0:14::9c]) by ietfa.amsl.com (Postfix) with ESMTP id 383A921F846E for ; Sun, 2 Sep 2012 13:52:52 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:e::69]) by elenski.switch.ch (8.14.3/8.14.3/Debian-9.4) with ESMTP id q82KqpCa011534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 Sep 2012 22:52:52 +0200 Received: from [2001:620:0:26:8088:b839:10a8:d4e4] (helo=Simons-MacBook-Air.local) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1T8HA2-0006nU-S1; Sun, 02 Sep 2012 22:52:50 +0200 From: Simon Leinen To: netmod@ietf.org In-Reply-To: <20120828080525.GA1668@elstar.local> (Juergen Schoenwaelder's message of "Tue, 28 Aug 2012 10:05:25 +0200") References: <454AE524-CCD3-4F84-9D0D-59CFC6B8BB73@tail-f.com> <20120828080525.GA1668@elstar.local> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Sun, 02 Sep 2012 22:52:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-CanIt-Geo: ip=2001:620:0:e::69; country=CH X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [netmod] NETCONF/YANG use with OpenFlow [was: Re: Metro Ethernet Forum publishes YANG modules] 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: Sun, 02 Sep 2012 20:52:54 -0000 Juergen Schoenwaelder writes: > Thanks for letting is know. Its good to see usage of our work. That reminds me: I recently noticed that the Open Networking Foundation also chose to base their separate configuration protocol on NETCONF+YANG: https://www.opennetworking.org/standards/of-config-11 The core OpenFlow protocol is mostly for manipulating flow tables - although it also has a few functions for configuring and observing general switch configuration. It seems optimized for resource efficiency/processing speed. No XML whatsoever. The NETCONF-based OF-config protocol is supposed to be used to manipulate more complex and less time-critical aspects of the configuration. -- Simon. PS. If everybody knew this already, sorry for the noise. PPS. Maybe this has something to do with Rob Enns being at Nicira? From jonathan@hansfords.net Mon Sep 3 03:04: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 3544421F850D for ; Mon, 3 Sep 2012 03:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ3YPxwxPijD for ; Mon, 3 Sep 2012 03:04:55 -0700 (PDT) Received: from avasout02.plus.net (avasout02.plus.net [212.159.14.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2773B21F84EF for ; Mon, 3 Sep 2012 03:04:54 -0700 (PDT) Received: from webmail.plus.net ([212.159.8.87]) by avasout02 with smtp id ua4q1j0091sg6PG01a4rJj; Mon, 03 Sep 2012 11:04:52 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=Hpr06jvS c=1 sm=1 a=w/v6d3Yw9YqO0eqsxHCYQw==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=kc7ddR8fZWEA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=mEJ2tnKKOAMA:10 a=n1r99OXAIAcA:10 a=_ubb1IcO-kAA:10 a=Pa3O_z69d9EA:10 a=IEBFJOIs2_oA:10 a=QPq4kOWgkJQA:10 a=Fjm2GW12xt8A:10 a=GiWGhnCEgLIA:10 a=zfeYaam6jMQA:10 a=ztF9EF-Jay0A:10 a=bHYFy4rKJhcA:10 a=-Mlm8gHJXiwA:10 a=48vgC7mUAAAA:8 a=uOUQaN-WTJq9G2UGfM0A:9 a=QEXdDO2ut3YA:10 a=owtw_3N5FgyTsazsL80A:9 a=_W_S_7VecoQA:10 a=w/v6d3Yw9YqO0eqsxHCYQw==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Mon, 03 Sep 2012 11:04:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c293d33fd98ade3eae11a58312e1d39f" Date: Mon, 03 Sep 2012 11:04:50 +0100 From: Jonathan Hansford To: In-Reply-To: References: Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Subject: Re: [netmod] YANG module for ACL configuration 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, 03 Sep 2012 10:04:56 -0000 --=_c293d33fd98ade3eae11a58312e1d39f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Having just extracted the YANG modules from the document (i.e. not having reviewed the document yet), here are a couple of issues: * RFC6087 states "Each YANG module or submodule contained within an Internet-Draft or RFC is considered to be a code component. The strings '' and '' MUST be used to identify each code component." acl.yang is the only code component that is identified with and none or the code components are identified with * module acl * statement identifies the revision as 2012-08-30 whereas the revision statement identifies it as 2012-08-31 * module acl-ip * The typedef for Comparator is in module acl and should therefore have the appropriate prefix, viz acl:Comparator Jonathan On 01.09.2012 00:03, Alexander Clemm (alex) wrote: > Dear All, > > we have just posted an Internet Draft of a YANG model for ACL configuration: > > http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt [1] > > This document defines a YANG data model for Access Control Lists (ACLs) on a device. An ACL is an ordered set of rules that is used to filter traffic on a networking device. In the draft you will find details of how the model is designed and the corresponding YANG modules. > > We are hoping that this model is of interest to this group. Please take a look and let us know your thoughts and comments. > > Thanks, > > Alex & Lisa Links: ------ [1] http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt --=_c293d33fd98ade3eae11a58312e1d39f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Having just extracted the YANG modules from the document (i.e. not havin= g reviewed the document yet), here are a couple of issues:

  • RFC6087 states "Each YANG module or submodule contained within an Inter= net-Draft or RFC is considered to be a code component. The strings '&l= t;CODE BEGINS>' and '<CODE ENDS>' MUST be used to identify ea= ch code component." acl.yang is the only code component that is identi= fied with <CODE BEGINS> and none or the code components are identifie= d with <CODE ENDS>
  • module acl
    • <CODE BEGINS> statement identifies the revision as 2012-08-30 whe= reas the revision statement identifies it as 2012-08-31
  • module acl-ip
    • The typedef for Comparator is in module acl and should therefore have t= he appropriate prefix, viz acl:Comparator

Jonathan

On 01.09.2012 00:03, Alexander Clemm (alex) wrote:

Dear All,

 

we have just posted an Internet Draft of a YANG m= odel for ACL configuration:

http://www.ietf.org/internet-drafts/draft-huan= g-netmod-acl-00.txt

 

This document defines a YANG data model for Acces= s Control Lists (ACLs) on a device. An ACL is an ordered set of rules that = is used to filter traffic on a networking device. In the draft you will fin= d details of how the model is designed and the corresponding YANG modules= =2E 

 

We are hoping that this model is of interest to t= his group.  Please take a look and let us know your thoughts and comme= nts. 

 

Thanks,

 

Alex & Lisa

 

 

 
--=_c293d33fd98ade3eae11a58312e1d39f-- From brijsman@juniper.net Mon Sep 3 04:17: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 D069F21F84F9; Mon, 3 Sep 2012 04:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Niw3HQFyOL; Mon, 3 Sep 2012 04:17:33 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id EB19F21F84D7; Mon, 3 Sep 2012 04:17:32 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUESRzF6zkcfw+54w0vavS7PJtCpYiM0l@postini.com; Mon, 03 Sep 2012 04:17:33 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Sep 2012 04:15:10 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 3 Sep 2012 07:15:09 -0400 From: Bruno Rijsman To: "netmod@ietf.org" Date: Mon, 3 Sep 2012 07:15:08 -0400 Thread-Topic: A few comments on the draft-ietf-netmod-routing-cfg-04 draft. Thread-Index: Ac2JxWCgGDoHt3+QR+66VvaZlNieRQ== Message-ID: <6A19849347D1D1499E75EB41E82C420A4BCFD2C219@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 03 Sep 2012 04:48:36 -0700 Cc: "irs-discuss@ietf.org" Subject: [netmod] A few comments on the draft-ietf-netmod-routing-cfg-04 draft. 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, 03 Sep 2012 11:17:33 -0000 I have a few comments on the draft-ietf-netmod-routing-cfg-04 draft. 1) Generalize the concept of a next-hop It appears that in the current model, routes can point to an outgoing inter= face and a next-hop address. The concept of next-hops needs to be generaliz= ed. Next-hops can have multiple tuples of outgoing interfaces and next-hop = addresses. The most common reasons is Equal Cost Multi Path (ECMP) where a = single route has multiple next-hops. This is not the same as multi-pathing = in the sense of multiple active routes to the same prefix each contributing= one next-hop. A variation of this is NECMP where the next-hops are differe= nt weights. Another reason for multiple next-hops is fast re-route where th= e next-hops represent alternatives (the first one whose interface is up is = used). Another needed generalization of next-hops is the ability to push an= d pop MPLS labels, VLAN tags, etc. Another is the ability to add a level of= indirection (e.g. BGP indirect next-hop for fast BGP reconvergence). The O= penFlow 1.x documents are a good source to look for generalized next-hop ex= amples.=20 2) Generalize the concept of a prefix Section 4.2 says that the core routing data model only defines the followin= g minimal set of route attributes: destination-prefix, next-hop, outgoing-i= nterface. However, in section 4 there are no destination-prefix or next-hop= . There are only v4ur:dest-prefix, v4ur:next-hop, v6ur:dest-prefix, v6ur:ne= xt-hop. It appears that the destination-prefix and next-hop were removed fr= om the base object and moved to the derived object. In my opinion, it would= make sense to move the destination-prefix (as a simple bit-string and leng= th) and the next-hop back to the base object. The derived object could have= a string object to contain the destination-prefix as a human-readable stri= ng (e.g. "10.0.0.0/8" for an IPv4 prefix). Furthermore, section 4.2 assumes= that the routes are always IP routes (it uses repeatedly uses terms like "= IP prefix"). The routes can be non-IP routes. For example, MPLS routes whic= h are /20 exact matches on a label, or CLNS routes, or other protocols. Som= e VPLS implementations even use the "routing table" abstraction to represen= t Ethernet routes (as exact /48 routes on MAC addresses). 3) Static (and direct) routes for multiple routing tables. Figure 2 appears to imply that static and direct routes can only be inserte= d in the main routing table. Is it possible to install static routes in mul= tiple additional routing tables? =20 4) More attributes for static routes. Configured static routes (routes in the pseudo routing-protocol "static") n= eed more attributes (e.g. metric). 5) Add support for routing-instances. Allow the creation of multiple routing-instances (also known as VRFs) per l= ogical-router. Allow interfaces to be assigned to routing-instances. Allow = multiple instances of routing protocols, scoped by routing-instance. 6) Ability for a client to subscribe to RIB changes It would be very useful for a client to be able to subscribe to route table= changes. (I am not a YANG expert and I don't know if such a thing is even = possible in YANG.) In the subscription, the client could specify one or mor= e routing tables in which it is interested and filter(s) to specify which s= ubset of routes it is interested in. 7) More sophisticated filters Section 4.5 explicitly says that the core routing data model only defines a= skeleton for filtering. It would be "good" for the working group to contin= ue this work and define more sophisticated filtering mechanisms. -- Bruno PS: Cross-post to the Interface to the Routing System (IRS) mailing list be= cause they are discussing very similar functionality. From alex@cisco.com Mon Sep 3 21:21:07 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 D9FD621F85E6 for ; Mon, 3 Sep 2012 21:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUgRdZlHiV2D for ; Mon, 3 Sep 2012 21:21:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 78BD021F8644 for ; Mon, 3 Sep 2012 21:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14008; q=dns/txt; s=iport; t=1346732464; x=1347942064; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=21f6Fyle2xdVnnHZRF7BtCWrb05nWqkC2ZUtySfAjco=; b=fYAkzjxkHgJASjIF63EOZ5zWBAYmIOnobPSuNNS4eldXGfI4gkF0ONLf qMauBSV45Z3PhxDfZzlmKZHflipIic3dKttEQjNxi59CnbjmqD2Hi7fds 0LKSiHE/vMQtUeUwrcXSnql/kZktI5XqRr8TP/TF6Q8XGNB6QfHHj4ypy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGmARVCtJV2b/2dsb2JhbAA7CoJKgzu0MHOBB4IgAQEBBBIBEApcAgEIEQQBAQsdAwICAjAUCQgBAQQBEggBGYdrC5oijRmSZIsNEIYQMmADpAyBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,364,1344211200"; d="scan'208,217";a="114917337" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2012 04:21:03 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q844L2oY026360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 04:21:02 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Mon, 3 Sep 2012 23:21:02 -0500 From: "Alexander Clemm (alex)" To: Jonathan Hansford , "netmod@ietf.org" Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwCGKVAAABvERUA= Date: Tue, 4 Sep 2012 04:21:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.167.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.001 x-tm-as-result: No--51.426700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B570F4C5C9Exmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: Re: [netmod] YANG module for ACL configuration 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, 04 Sep 2012 04:21:07 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B570F4C5C9Exmbrcdx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSm9uYXRoYW4sDQoNCnRoYW5rIHlvdS4gIFRoZXNlIGFyZSBnb29kIGNhdGNoZXMuICBX ZSB3aWxsIGNvcnJlY3QgdGhpcyBpbiB0aGUgbmV4dCByZXZpc2lvbiAob25jZSB3ZSBoYXZlIHJl Y2VpdmVkIGEgbGl0dGxlIG1vcmUgZmVlZGJhY2spLg0KDQpSZWdhcmRzDQotLS0gQWxleA0KDQpG cm9tOiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSm9uYXRoYW4gSGFuc2ZvcmQNClNlbnQ6IE1vbmRheSwgU2VwdGVt YmVyIDAzLCAyMDEyIDM6MDUgQU0NClRvOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb bmV0bW9kXSBZQU5HIG1vZHVsZSBmb3IgQUNMIGNvbmZpZ3VyYXRpb24NCg0KDQpIYXZpbmcganVz dCBleHRyYWN0ZWQgdGhlIFlBTkcgbW9kdWxlcyBmcm9tIHRoZSBkb2N1bWVudCAoaS5lLiBub3Qg aGF2aW5nIHJldmlld2VkIHRoZSBkb2N1bWVudCB5ZXQpLCBoZXJlIGFyZSBhIGNvdXBsZSBvZiBp c3N1ZXM6DQoNCiAgKiAgIFJGQzYwODcgc3RhdGVzICJFYWNoIFlBTkcgbW9kdWxlIG9yIHN1Ym1v ZHVsZSBjb250YWluZWQgd2l0aGluIGFuIEludGVybmV0LURyYWZ0IG9yIFJGQyBpcyBjb25zaWRl cmVkIHRvIGJlIGEgY29kZSBjb21wb25lbnQuIFRoZSBzdHJpbmdzICc8Q09ERSBCRUdJTlM+JyBh bmQgJzxDT0RFIEVORFM+JyBNVVNUIGJlIHVzZWQgdG8gaWRlbnRpZnkgZWFjaCBjb2RlIGNvbXBv bmVudC4iIGFjbC55YW5nIGlzIHRoZSBvbmx5IGNvZGUgY29tcG9uZW50IHRoYXQgaXMgaWRlbnRp ZmllZCB3aXRoIDxDT0RFIEJFR0lOUz4gYW5kIG5vbmUgb3IgdGhlIGNvZGUgY29tcG9uZW50cyBh cmUgaWRlbnRpZmllZCB3aXRoIDxDT0RFIEVORFM+DQogICogICBtb2R1bGUgYWNsDQogICAgICog ICA8Q09ERSBCRUdJTlM+IHN0YXRlbWVudCBpZGVudGlmaWVzIHRoZSByZXZpc2lvbiBhcyAyMDEy LTA4LTMwIHdoZXJlYXMgdGhlIHJldmlzaW9uIHN0YXRlbWVudCBpZGVudGlmaWVzIGl0IGFzIDIw MTItMDgtMzENCiAgKiAgIG1vZHVsZSBhY2wtaXANCiAgICAgKiAgIFRoZSB0eXBlZGVmIGZvciBD b21wYXJhdG9yIGlzIGluIG1vZHVsZSBhY2wgYW5kIHNob3VsZCB0aGVyZWZvcmUgaGF2ZSB0aGUg YXBwcm9wcmlhdGUgcHJlZml4LCB2aXogYWNsOkNvbXBhcmF0b3INCg0KSm9uYXRoYW4NCg0KT24g MDEuMDkuMjAxMiAwMDowMywgQWxleGFuZGVyIENsZW1tIChhbGV4KSB3cm90ZToNCg0KRGVhciBB bGwsDQoNCg0KDQp3ZSBoYXZlIGp1c3QgcG9zdGVkIGFuIEludGVybmV0IERyYWZ0IG9mIGEgWUFO RyBtb2RlbCBmb3IgQUNMIGNvbmZpZ3VyYXRpb246DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1YW5nLW5ldG1vZC1hY2wtMDAudHh0DQoNCg0KDQpUaGlzIGRv Y3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIEFjY2VzcyBDb250cm9sIExpc3Rz IChBQ0xzKSBvbiBhIGRldmljZS4gQW4gQUNMIGlzIGFuIG9yZGVyZWQgc2V0IG9mIHJ1bGVzIHRo YXQgaXMgdXNlZCB0byBmaWx0ZXIgdHJhZmZpYyBvbiBhIG5ldHdvcmtpbmcgZGV2aWNlLiBJbiB0 aGUgZHJhZnQgeW91IHdpbGwgZmluZCBkZXRhaWxzIG9mIGhvdyB0aGUgbW9kZWwgaXMgZGVzaWdu ZWQgYW5kIHRoZSBjb3JyZXNwb25kaW5nIFlBTkcgbW9kdWxlcy4NCg0KDQoNCldlIGFyZSBob3Bp bmcgdGhhdCB0aGlzIG1vZGVsIGlzIG9mIGludGVyZXN0IHRvIHRoaXMgZ3JvdXAuICBQbGVhc2Ug dGFrZSBhIGxvb2sgYW5kIGxldCB1cyBrbm93IHlvdXIgdGhvdWdodHMgYW5kIGNvbW1lbnRzLg0K DQoNCg0KVGhhbmtzLA0KDQoNCg0KQWxleCAmIExpc2ENCg0KDQoNCg0K --_000_DBC595ED2346914F9F81D17DD5C32B570F4C5C9Exmbrcdx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQg NiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5U ZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0MTg5NDU4NTA7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MDk3NTczOTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPg0KPC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5IZWxsbyBKb25hdGhhbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj50aGFuayB5b3UuJm5ic3A7IFRoZXNlIGFyZSBnb29kIGNhdGNoZXMuJm5ic3A7IFdlIHdp bGwgY29ycmVjdCB0aGlzIGluIHRoZSBuZXh0IHJldmlzaW9uIChvbmNlIHdlIGhhdmUgcmVjZWl2 ZWQgYSBsaXR0bGUgbW9yZSBmZWVkYmFjaykuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+LS0tIEFsZXgNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9uYXRoYW4gSGFuc2ZvcmQ8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBTZXB0ZW1iZXIgMDMsIDIwMTIgMzowNSBBTTxicj4NCjxiPlRvOjwvYj4gbmV0 bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBZQU5HIG1vZHVs ZSBmb3IgQUNMIGNvbmZpZ3VyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5IYXZp bmcganVzdCBleHRyYWN0ZWQgdGhlIFlBTkcgbW9kdWxlcyBmcm9tIHRoZSBkb2N1bWVudCAoaS5l LiBub3QgaGF2aW5nIHJldmlld2VkIHRoZSBkb2N1bWVudCB5ZXQpLCBoZXJlIGFyZSBhIGNvdXBs ZSBvZiBpc3N1ZXM6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KICAgICBtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpSRkM2MDg3IHN0 YXRlcyAmcXVvdDtFYWNoIFlBTkcgbW9kdWxlIG9yIHN1Ym1vZHVsZSBjb250YWluZWQgd2l0aGlu IGFuIEludGVybmV0LURyYWZ0IG9yJm5ic3A7UkZDIGlzIGNvbnNpZGVyZWQgdG8gYmUgYSBjb2Rl IGNvbXBvbmVudC4gVGhlIHN0cmluZ3MgJyZsdDtDT0RFJm5ic3A7QkVHSU5TJmd0OycgYW5kICcm bHQ7Q09ERSBFTkRTJmd0OycgTVVTVCBiZSB1c2VkIHRvIGlkZW50aWZ5IGVhY2ggY29kZSZuYnNw O2NvbXBvbmVudC4mcXVvdDsgYWNsLnlhbmcgaXMgdGhlIG9ubHkgY29kZSBjb21wb25lbnQgdGhh dA0KIGlzIGlkZW50aWZpZWQgd2l0aCAmbHQ7Q09ERSBCRUdJTlMmZ3Q7IGFuZCBub25lIG9yIHRo ZSBjb2RlIGNvbXBvbmVudHMgYXJlIGlkZW50aWZpZWQgd2l0aCAmbHQ7Q09ERSBFTkRTJmd0Ozxv OnA+PC9vOnA+DQo8L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCm1vZHVsZSBhY2w8bzpwPjwvbzpwPg0KPHVsIHR5cGU9ImNpcmNsZSI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDoNCiAgICAgIGF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEi Pg0KJmx0O0NPREUgQkVHSU5TJmd0OyBzdGF0ZW1lbnQgaWRlbnRpZmllcyB0aGUgcmV2aXNpb24g YXMgMjAxMi0wOC0zMCB3aGVyZWFzIHRoZSByZXZpc2lvbiBzdGF0ZW1lbnQgaWRlbnRpZmllcyBp dCBhcyAyMDEyLTA4LTMxPG86cD48L286cD4NCjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KbW9kdWxlIGFjbC1p cDxvOnA+PC9vOnA+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0Og0KICAg ICAgYXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQpUaGUgdHlwZWRlZiBmb3IgQ29tcGFy YXRvciBpcyBpbiBtb2R1bGUgYWNsIGFuZCBzaG91bGQgdGhlcmVmb3JlIGhhdmUgdGhlIGFwcHJv cHJpYXRlIHByZWZpeCwgdml6IGFjbDpDb21wYXJhdG9yPG86cD48L286cD4NCjwvbGk+PC91bD4N CjwvbGk+PC91bD4NCjxwPkpvbmF0aGFuPG86cD48L286cD48L3A+DQo8cD5PbiAwMS4wOS4yMDEy IDAwOjAzLCBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICMxMDEwRkYgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDsNCm1hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkRlYXIgQWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij53ZSBoYXZlIGp1 c3QgcG9zdGVkIGFuIEludGVybmV0IERyYWZ0IG9mIGEgWUFORyBtb2RlbCBmb3IgQUNMIGNvbmZp Z3VyYXRpb246DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1YW5nLW5ldG1v ZC1hY2wtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1o dWFuZy1uZXRtb2QtYWNsLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciBBY2Nlc3MgQ29udHJv bCBMaXN0cyAoQUNMcykgb24gYSBkZXZpY2UuIEFuIEFDTCBpcyBhbiBvcmRlcmVkIHNldCBvZiBy dWxlcyB0aGF0IGlzIHVzZWQgdG8gZmlsdGVyIHRyYWZmaWMgb24gYSBuZXR3b3JraW5nIGRldmlj ZS4gSW4gdGhlIGRyYWZ0IHlvdSB3aWxsIGZpbmQgZGV0YWlscyBvZiBob3cgdGhlIG1vZGVsIGlz IGRlc2lnbmVkDQogYW5kIHRoZSBjb3JyZXNwb25kaW5nIFlBTkcgbW9kdWxlcy4mbmJzcDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGFyZSBob3BpbmcgdGhhdCB0aGlzIG1vZGVs IGlzIG9mIGludGVyZXN0IHRvIHRoaXMgZ3JvdXAuJm5ic3A7IFBsZWFzZSB0YWtlIGEgbG9vayBh bmQgbGV0IHVzIGtub3cgeW91ciB0aG91Z2h0cyBhbmQgY29tbWVudHMuJm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5BbGV4ICZhbXA7IExpc2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_DBC595ED2346914F9F81D17DD5C32B570F4C5C9Exmbrcdx05ciscoc_-- From andy@yumaworks.com Tue Sep 4 08:11: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 B90A521F855E for ; Tue, 4 Sep 2012 08:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp9YYKR6r8+M for ; Tue, 4 Sep 2012 08:11:45 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6221F855D for ; Tue, 4 Sep 2012 08:11:45 -0700 (PDT) Received: by qadz3 with SMTP id z3so3122549qad.10 for ; Tue, 04 Sep 2012 08:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZK3M+nJgEa1p1RrJOGwCRzsnlty1EEFwH5HWpPnVCfQ=; b=Nox9mHs0LoCiXNPG4XerLcwvLKIJZ81vp+/y9Yln6KFjeD5jSAb4F1Ez4UiIpInXRF qzpNWDpSMORdLwjn/XYI2pDyvK+KfA/cO9Aj0GhCNbpdKcYoWSgQ4xkx8Zje5k948Rn9 YmL15KfLu+HjcdQ/5kNPkWDAgt/wXgJBO2JxFf+BbJL7CzJsXRBmWp+nF42eIFydK7aZ 60Sf/5sB7XSaEiUDntDpKkPF6UEio7JgjiRhWmKQ/dG0KoWTw9TpYSywdEHvqij6yWas DbawBmqwH0+oVD5yHH7isycZr83jcJ3AeBfrR+AN03vXkkozCCVeQgC2BqMYgwpZtS4D GR2A== MIME-Version: 1.0 Received: by 10.224.77.13 with SMTP id e13mr40433505qak.68.1346771504834; Tue, 04 Sep 2012 08:11:44 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Tue, 4 Sep 2012 08:11:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 08:11:44 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlbBRHeWIOYws6/GgK7CWu2XNDRVPgddsahYm8UdIfJhHYCmJidNaLLtoXbEO022lXoIwQC Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 04 Sep 2012 15:11:49 -0000 On Mon, Sep 3, 2012 at 9:21 PM, Alexander Clemm (alex) wrote: > Hello Jonathan, > > > > thank you. These are good catches. We will correct this in the next > revision (once we have received a little more feedback). > This is a very substantial YANG module. It would be nice to have some example configs and use-cases to demonstrate the YANG module in use. An endless list of groupings makes it hard for readers to visualize instance documents. I don't see how the ACLs hook into the interfaces table. Is is purely by IP address and not interface? I noticed a top-level augment-stmt in the same document as the object being augmented. What is the point of this structure? I noticed a RPC operation. I thought we settled this issue in SNMP in the early 90s. Counters are shared. If 1 client resets them, all the other clients reading them are impacted. Not sure what WG this belongs in, but not NETMOD. Seems like a group of experts will need to go over this rather implementation-specific data model and generalize it for standards use. > > > Regards > > --- Alex > Andy > > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of > Jonathan Hansford > Sent: Monday, September 03, 2012 3:05 AM > To: netmod@ietf.org > Subject: Re: [netmod] YANG module for ACL configuration > > > > Having just extracted the YANG modules from the document (i.e. not having > reviewed the document yet), here are a couple of issues: > > RFC6087 states "Each YANG module or submodule contained within an > Internet-Draft or RFC is considered to be a code component. The strings > '' and '' MUST be used to identify each code > component." acl.yang is the only code component that is identified with > and none or the code components are identified with ENDS> > module acl > > statement identifies the revision as 2012-08-30 whereas the > revision statement identifies it as 2012-08-31 > > module acl-ip > > The typedef for Comparator is in module acl and should therefore have the > appropriate prefix, viz acl:Comparator > > Jonathan > > On 01.09.2012 00:03, Alexander Clemm (alex) wrote: > > Dear All, > > > > we have just posted an Internet Draft of a YANG model for ACL configuration: > > http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt > > > > This document defines a YANG data model for Access Control Lists (ACLs) on a > device. An ACL is an ordered set of rules that is used to filter traffic on > a networking device. In the draft you will find details of how the model is > designed and the corresponding YANG modules. > > > > We are hoping that this model is of interest to this group. Please take a > look and let us know your thoughts and comments. > > > > Thanks, > > > > Alex & Lisa > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From yihuan@cisco.com Tue Sep 4 11:40: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 924B021F8692 for ; Tue, 4 Sep 2012 11:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfAXwzdnLWjW for ; Tue, 4 Sep 2012 11:40:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 75EA321F868A for ; Tue, 4 Sep 2012 11:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=6857; q=dns/txt; s=iport; t=1346784017; x=1347993617; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=L3g8F6ErJ4P1l9RhAGnIWZ3yYUpQqS8fQiGJvS+WVew=; b=Vh+EjcGQnBp4uUy07NZ3kIJ3PVC9vKJiS1mqBJeEdyeeM5kCE3eUMYfj 9pTAPWOedhp7uAw2/ZNcKTyKK/4Dbyz0aXxFEctbfBT4pjBfpDsECF9o8 By2KijcYikIvIoqg5ECTFmn9/l+yM6OnPJbfw8w9kujRaBOzTixvOoAPx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPZJRlCtJXG9/2dsb2JhbAA7CrsjgQeCIAEBAQQBAQEPAScxAwsSAQgRBAEBAR4JLgsUCQgBAQQBDQUJGYdrC5pWoAaLCRCHIgOVWY4zgWeCYw X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208";a="118179524" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 04 Sep 2012 18:40:16 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q84IeGer001219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 18:40:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 13:40:15 -0500 From: "Lisa Huang (yihuan)" To: Andy Bierman , "Alexander Clemm (alex)" Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwCGKVAAABvERUAAIT48AP//xOgA Date: Tue, 4 Sep 2012 18:40:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19162.001 x-tm-as-result: No--48.791400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6BD37652FD324A42BB44FEA7FA7B07DC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 04 Sep 2012 18:40:18 -0000 Thanks, Andy. I marked my response as in line below. On 9/4/12 8:11 AM, "Andy Bierman" wrote: >On Mon, Sep 3, 2012 at 9:21 PM, Alexander Clemm (alex) >wrote: >> Hello Jonathan, >> >> >> >> thank you. These are good catches. We will correct this in the next >> revision (once we have received a little more feedback). >> > >This is a very substantial YANG module. >It would be nice to have some example configs and use-cases >to demonstrate the YANG module in use. Here is an example of ip-acl to demonstrate how to use the Yang module. I can add it to next draft. ACL Example: Denies TELNET traffic from 14.3.6.234 bound for host 6.5.4.1 from leaving. Denies all TFTP traffic bound for TFTP servers. Permits all other IP traffic. ACL CLI: access-list ip iacl 10 deny tcp 14.3.6.234 0.0.0.0 host 6.5.4.1 eq 23 20 deny udp any any eq tftp 30 permit ip any any The edit-config data part is the following: iacl ip-acl false ipv4 =20 10 6 ip 14.3.6.234 0.0.0.0 host 6.5.4.1 eq 23 deny 20 17 any any eq 69 deny 30 any any permit =20 >An endless list of >groupings makes it hard for readers to visualize instance documents. Indeed there are a lot of groupings in the model simply because ACL is large and have a lot of reused part among different types of acl. To make the draft more readable, I have added the design of model section and a full expanded tree to help to get an overview picture of the model. > >I don't see how the ACLs hook into the interfaces table. >Is is purely by IP address and not interface? This draft did not target to address how the ACL apply to the interfaces as mentioned in the draft. One potential way is through the Acl-Ref typedef. Here is a sample usage: import acl { prefix acl; } list myInteface { ... leaf access-group { type acl:Acl-Ref; } ... } I did not add this to the draft since there is no limitation how to use it. > >I noticed a top-level augment-stmt in the same document as the >object being augmented. What is the point of this structure? They are not in the same document. Top level container and acl list are in acl.yang whereas the augment-stmt are in acl-ip.yang, acl-arp.yang, acl-mac.yang. > >I noticed a RPC operation. >I thought we settled this issue in SNMP in the early 90s. >Counters are shared. If 1 client resets them, all the other >clients reading them are impacted. > >Not sure what WG this belongs in, but not NETMOD. >Seems like a group of experts will need to go over this >rather implementation-specific data model and generalize >it for standards use. > > >> >> >> Regards >> >> --- Alex >> > >Andy > >> >> >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On >>Behalf Of >> Jonathan Hansford >> Sent: Monday, September 03, 2012 3:05 AM >> To: netmod@ietf.org >> Subject: Re: [netmod] YANG module for ACL configuration >> >> >> >> Having just extracted the YANG modules from the document (i.e. not >>having >> reviewed the document yet), here are a couple of issues: >> >> RFC6087 states "Each YANG module or submodule contained within an >> Internet-Draft or RFC is considered to be a code component. The strings >> '' and '' MUST be used to identify each code >> component." acl.yang is the only code component that is identified with >> and none or the code components are identified with > ENDS> >> module acl >> >> statement identifies the revision as 2012-08-30 whereas >>the >> revision statement identifies it as 2012-08-31 >> >> module acl-ip >> >> The typedef for Comparator is in module acl and should therefore have >>the >> appropriate prefix, viz acl:Comparator >> >> Jonathan >> >> On 01.09.2012 00:03, Alexander Clemm (alex) wrote: >> >> Dear All, >> >> >> >> we have just posted an Internet Draft of a YANG model for ACL >>configuration: >> >> http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt >> >> >> >> This document defines a YANG data model for Access Control Lists (ACLs) >>on a >> device. An ACL is an ordered set of rules that is used to filter >>traffic on >> a networking device. In the draft you will find details of how the >>model is >> designed and the corresponding YANG modules. >> >> >> >> We are hoping that this model is of interest to this group. Please >>take a >> look and let us know your thoughts and comments. >> >> >> >> Thanks, >> >> >> >> Alex & Lisa >> >> >> >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From alex@cisco.com Tue Sep 4 13:08:34 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 AE43D21F84CF for ; Tue, 4 Sep 2012 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw9j2T35+2KY for ; Tue, 4 Sep 2012 13:08:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3121F84CE for ; Tue, 4 Sep 2012 13:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=7090; q=dns/txt; s=iport; t=1346789313; x=1347998913; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PpqziEj+9Hi3Gxe9SsLnGw00MvGJLnJYLWR6mDrBPK4=; b=P1Pq54z65awvaYEff9bzniSSTrpbXo9g4exFO8C/9ds7oDwC8QBsOXXK 2jdRJlgBUJz3UtK7TvakbZOvs0oqayoPCH8NM8VyFhnbIKzIOZ1KKLKF2 Hfu2jeRMyPhSubfSMPyudK8airlFJYuj637DGlnJBevt0Ev9CrSDh2Qvl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAD1fRlCtJXG8/2dsb2JhbAA7CoYFtCh3gQeCIAEBAQMBAQEBDwEQETcDCwwEAgEIEQQBAQECAgYdAwICAiULFAEICAEBBA4FCAEZh2UGC5pSjRmTAIEhiWgQhhAyYAOkDIFngmM X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; d="scan'208";a="118211495" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 04 Sep 2012 20:08:27 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q84K8R25015991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 20:08:27 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 4 Sep 2012 15:08:26 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwCGKVAAABvERUAAIT48AAAAxCIw Date: Tue, 4 Sep 2012 20:08:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19162.001 x-tm-as-result: No--57.572600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 04 Sep 2012 20:08:34 -0000 SGkgQW5keSwNCg0KTGlzYSBhbHJlYWR5IHJlc3BvbmRlZCB0byBtb3N0IG9mIHRoZSBpdGVtcyB5 b3UgcmFpc2VkLg0KDQpSZWdhcmRpbmcgdGhlIHJlc2V0dGluZyBvZiBjb3VudGVyczogIFRoaXMg YWN0dWFsbHkgdG91Y2hlcyBvbiB0d28gaXNzdWVzLiAgVGhlIGZpcnN0IGlzc3VlIGNvbmNlcm5z IHdoZXRoZXIgdG8gaW5jbHVkZSBzdXBwb3J0IGZvciBjb3VudGVycyBhbmQgYmFzaWMgc3RhdGlz dGljcyBhdCBhbGwsIG9yIGp1c3QgZm9jdXMgb24gY29uZmlndXJhdGlvbi4gIFdlIHdlcmUgZGVi YXRpbmcgd2l0aCBvdXJzZWx2ZXMsIGJ1dCBpbiB0aGUgZW5kIGZlbHQgdGhhdCBiYXNpYyBzdGF0 aXN0aWNzIGFyZSBnZW5lcmFsbHkganVzdCBwYXJ0IG9mIEFDTCBtYW5hZ2VtZW50IGFuZCB3aGls ZSB0aGV5IGNvdWxkIGJlIGJyb2tlbiBvdXQsIHRvIGp1c3QgaW5jbHVkZSB0aGVtLiBJZiB0aGUg c2VudGltZW50IGlzIHRoYXQgdGhleSBzaG91bGQgYmUgcmVtb3ZlZCwgd2UgY2FuIGNlcnRhaW5s eSBkbyBzby4gIA0KDQpUaGUgc2Vjb25kIGlzc3VlIGNvbmNlcm5zIHRoZSByZXNldCBpc3N1ZSBw ZXIgc2UuICBJIGFtIGNlcnRhaW5seSBhd2FyZSBvZiB0aGUgY29ycmVzcG9uZGluZyBkaXNjdXNz aW9uIGluIGNvbmp1bmN0aW9uIHdpdGggU05NUC4gIEFnYWluLCB0aGUgcXVlc3Rpb24gaXMgd2hl dGhlciB0byBvZmZlciBzdWNoIGEgZmFjaWxpdHkgYXQgYWxsLiAgQ2VydGFpbmx5LCB0aGUgYXJn dW1lbnQgb2Ygd2FudGluZyB0byBhdm9pZCBjbGllbnRzIG5lZWRpbmcgdG8gYmUgYXdhcmUgb2Yg cmVzZXRzIGlzIHZhbGlkIGFzIHdlbGwuICBBdCB0aGUgc2FtZSB0aW1lLCB0aGUgY29udGV4dCBv ZiBOZXRjb25mIG1ha2VzIHNvbWUgdGhpbmdzIGFyZ3VhYmx5IGEgbGl0dGxlIGRpZmZlcmVudC4g IEZvciBvbmUsIHdlIGhhdmUgdGhlIGFiaWxpdHkgdG8gaW52b2tlIGEgc2VwYXJhdGUgcmVzZXQg ImFjdGlvbiIsIHdoaWNoIHJlc2V0cyB0aGUgdmFsdWUgYXMgYSAic2lkZSBlZmZlY3QiIGFzIG9w cG9zZWQgdG8gc2V0dGluZyBpdCBkaXJlY3RseS4gIFRoaXMgYWN0aW9uIGNhbiBjZXJ0YWlubHkg aGF2ZSBvdGhlciAic2lkZSBlZmZlY3RzIiwgc3VjaCBhcyByZWNvcmRpbmcgdGhlIHRpbWUgdGhl IGxhc3QgcmVzZXQgb2NjdXJyZWQgYW5kIGEgImNvdW50ZXIgcmVzZXQiIG5vdGlmaWNhdGlvbi4g IChBcmd1YWJseSwgdGhvc2UgbmVlZCB0byBiZSBpbnRyb2R1Y2VkLCBidXQgZ29vZCB0byBoYXZl IGEgZGlzY3Vzc2lvbiBvbiB0aGlzIHVwIGZyb250KS4gIEFsc28sIFNOTVAgd2FzIGNvbm5lY3Rp b25sZXNzLCB1bnJlbGlhYmxlIGV0YywgdW5saWtlIE5ldGNvbmYsIHNvIHRoZXJlIGlzIGxlc3Mg b2YgYW4gaXNzdWUgb2YgY2xpZW50cyBtaXNzaW5nIG5vdGlmaWNhdGlvbnMuICBBbnl3YXksIGl0 IG1heSBiZSBnb29kIHRvIGhhdmUgYW4gY2xlYXIgcG9saWN5IGhlcmUgLSBpcyBpdCB0aGUgZXhw ZWN0YXRpb24gdGhhdCB0aGUgU05NUCBwb2xpY3kgaXMgc3RpbGwgaW4gZWZmZWN0LCBvciBzaG91 bGQgaXQgYmUgYWRqdXN0ZWQ/ICAgIA0KDQpSZWdhcmRpbmcgdGhlIHdvcmtpbmcgZ3JvdXAsIHdo aWNoIG90aGVyIHdvcmtpbmcgZ3JvdXAgd291bGQgaXQgZml0IGluPyAgVG8gdXMsIE5ldG1vZCBh cHBlYXJlZCBhIGxvZ2ljYWwgY2FuZGlkYXRlLCBhcyBpdCBpcyBjbGVhcmx5IGludm9sdmVkIGlu ICJjb250ZW50cyBsaWJyYXJpZXMiLiAgQ2xlYXJseSwgdGhlIGludGVudCBpcyBmb3IgdGhpcyBp cyB0byBiZSBnZW5lcmFsaXplZCBmb3Igc3RhbmRhcmRzLXVzZS4gIA0KDQpUaGFua3MNCi0tLSBB bGV4DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFuZHkgQmllcm1hbiBb bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQs IDIwMTIgODoxMiBBTQ0KVG86IEFsZXhhbmRlciBDbGVtbSAoYWxleCkNCkNjOiBKb25hdGhhbiBI YW5zZm9yZDsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2R1 bGUgZm9yIEFDTCBjb25maWd1cmF0aW9uDQoNCk9uIE1vbiwgU2VwIDMsIDIwMTIgYXQgOToyMSBQ TSwgQWxleGFuZGVyIENsZW1tIChhbGV4KSA8YWxleEBjaXNjby5jb20+IHdyb3RlOg0KPiBIZWxs byBKb25hdGhhbiwNCj4NCj4NCj4NCj4gdGhhbmsgeW91LiAgVGhlc2UgYXJlIGdvb2QgY2F0Y2hl cy4gIFdlIHdpbGwgY29ycmVjdCB0aGlzIGluIHRoZSBuZXh0DQo+IHJldmlzaW9uIChvbmNlIHdl IGhhdmUgcmVjZWl2ZWQgYSBsaXR0bGUgbW9yZSBmZWVkYmFjaykuDQo+DQoNClRoaXMgaXMgYSB2 ZXJ5IHN1YnN0YW50aWFsIFlBTkcgbW9kdWxlLg0KSXQgd291bGQgYmUgbmljZSB0byBoYXZlIHNv bWUgZXhhbXBsZSBjb25maWdzIGFuZCB1c2UtY2FzZXMNCnRvIGRlbW9uc3RyYXRlIHRoZSBZQU5H IG1vZHVsZSBpbiB1c2UuICBBbiBlbmRsZXNzIGxpc3Qgb2YNCmdyb3VwaW5ncyBtYWtlcyBpdCBo YXJkIGZvciByZWFkZXJzIHRvIHZpc3VhbGl6ZSBpbnN0YW5jZSBkb2N1bWVudHMuDQoNCkkgZG9u J3Qgc2VlIGhvdyB0aGUgQUNMcyBob29rIGludG8gdGhlIGludGVyZmFjZXMgdGFibGUuDQpJcyBp cyBwdXJlbHkgYnkgSVAgYWRkcmVzcyBhbmQgbm90IGludGVyZmFjZT8NCg0KSSBub3RpY2VkIGEg dG9wLWxldmVsIGF1Z21lbnQtc3RtdCBpbiB0aGUgc2FtZSBkb2N1bWVudCBhcyB0aGUNCm9iamVj dCBiZWluZyBhdWdtZW50ZWQuICBXaGF0IGlzIHRoZSBwb2ludCBvZiB0aGlzIHN0cnVjdHVyZT8N Cg0KSSBub3RpY2VkIGEgPHJlc2V0LW1hdGNoLWNvdW50ZXI+IFJQQyBvcGVyYXRpb24uDQpJIHRo b3VnaHQgd2Ugc2V0dGxlZCB0aGlzIGlzc3VlIGluIFNOTVAgaW4gdGhlIGVhcmx5IDkwcy4NCkNv dW50ZXJzIGFyZSBzaGFyZWQuICBJZiAxIGNsaWVudCByZXNldHMgdGhlbSwgYWxsIHRoZSBvdGhl cg0KY2xpZW50cyByZWFkaW5nIHRoZW0gYXJlIGltcGFjdGVkLg0KDQpOb3Qgc3VyZSB3aGF0IFdH IHRoaXMgYmVsb25ncyBpbiwgYnV0IG5vdCBORVRNT0QuDQpTZWVtcyBsaWtlIGEgZ3JvdXAgb2Yg ZXhwZXJ0cyB3aWxsIG5lZWQgdG8gZ28gb3ZlciB0aGlzDQpyYXRoZXIgaW1wbGVtZW50YXRpb24t c3BlY2lmaWMgZGF0YSBtb2RlbCBhbmQgZ2VuZXJhbGl6ZQ0KaXQgZm9yIHN0YW5kYXJkcyB1c2Uu DQoNCg0KPg0KPg0KPiBSZWdhcmRzDQo+DQo+IC0tLSBBbGV4DQo+DQoNCkFuZHkNCg0KPg0KPg0K PiBGcm9tOiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gSm9uYXRoYW4gSGFuc2ZvcmQNCj4gU2VudDogTW9uZGF5 LCBTZXB0ZW1iZXIgMDMsIDIwMTIgMzowNSBBTQ0KPiBUbzogbmV0bW9kQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5HIG1vZHVsZSBmb3IgQUNMIGNvbmZpZ3VyYXRpb24NCj4N Cj4NCj4NCj4gSGF2aW5nIGp1c3QgZXh0cmFjdGVkIHRoZSBZQU5HIG1vZHVsZXMgZnJvbSB0aGUg ZG9jdW1lbnQgKGkuZS4gbm90IGhhdmluZw0KPiByZXZpZXdlZCB0aGUgZG9jdW1lbnQgeWV0KSwg aGVyZSBhcmUgYSBjb3VwbGUgb2YgaXNzdWVzOg0KPg0KPiBSRkM2MDg3IHN0YXRlcyAiRWFjaCBZ QU5HIG1vZHVsZSBvciBzdWJtb2R1bGUgY29udGFpbmVkIHdpdGhpbiBhbg0KPiBJbnRlcm5ldC1E cmFmdCBvciBSRkMgaXMgY29uc2lkZXJlZCB0byBiZSBhIGNvZGUgY29tcG9uZW50LiBUaGUgc3Ry aW5ncw0KPiAnPENPREUgQkVHSU5TPicgYW5kICc8Q09ERSBFTkRTPicgTVVTVCBiZSB1c2VkIHRv IGlkZW50aWZ5IGVhY2ggY29kZQ0KPiBjb21wb25lbnQuIiBhY2wueWFuZyBpcyB0aGUgb25seSBj b2RlIGNvbXBvbmVudCB0aGF0IGlzIGlkZW50aWZpZWQgd2l0aA0KPiA8Q09ERSBCRUdJTlM+IGFu ZCBub25lIG9yIHRoZSBjb2RlIGNvbXBvbmVudHMgYXJlIGlkZW50aWZpZWQgd2l0aCA8Q09ERQ0K PiBFTkRTPg0KPiBtb2R1bGUgYWNsDQo+DQo+IDxDT0RFIEJFR0lOUz4gc3RhdGVtZW50IGlkZW50 aWZpZXMgdGhlIHJldmlzaW9uIGFzIDIwMTItMDgtMzAgd2hlcmVhcyB0aGUNCj4gcmV2aXNpb24g c3RhdGVtZW50IGlkZW50aWZpZXMgaXQgYXMgMjAxMi0wOC0zMQ0KPg0KPiBtb2R1bGUgYWNsLWlw DQo+DQo+IFRoZSB0eXBlZGVmIGZvciBDb21wYXJhdG9yIGlzIGluIG1vZHVsZSBhY2wgYW5kIHNo b3VsZCB0aGVyZWZvcmUgaGF2ZSB0aGUNCj4gYXBwcm9wcmlhdGUgcHJlZml4LCB2aXogYWNsOkNv bXBhcmF0b3INCj4NCj4gSm9uYXRoYW4NCj4NCj4gT24gMDEuMDkuMjAxMiAwMDowMywgQWxleGFu ZGVyIENsZW1tIChhbGV4KSB3cm90ZToNCj4NCj4gRGVhciBBbGwsDQo+DQo+DQo+DQo+IHdlIGhh dmUganVzdCBwb3N0ZWQgYW4gSW50ZXJuZXQgRHJhZnQgb2YgYSBZQU5HIG1vZGVsIGZvciBBQ0wg Y29uZmlndXJhdGlvbjoNCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaHVhbmctbmV0bW9kLWFjbC0wMC50eHQNCj4NCj4NCj4NCj4gVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciBBY2Nlc3MgQ29udHJvbCBMaXN0cyAoQUNMcykg b24gYQ0KPiBkZXZpY2UuIEFuIEFDTCBpcyBhbiBvcmRlcmVkIHNldCBvZiBydWxlcyB0aGF0IGlz IHVzZWQgdG8gZmlsdGVyIHRyYWZmaWMgb24NCj4gYSBuZXR3b3JraW5nIGRldmljZS4gSW4gdGhl IGRyYWZ0IHlvdSB3aWxsIGZpbmQgZGV0YWlscyBvZiBob3cgdGhlIG1vZGVsIGlzDQo+IGRlc2ln bmVkIGFuZCB0aGUgY29ycmVzcG9uZGluZyBZQU5HIG1vZHVsZXMuDQo+DQo+DQo+DQo+IFdlIGFy ZSBob3BpbmcgdGhhdCB0aGlzIG1vZGVsIGlzIG9mIGludGVyZXN0IHRvIHRoaXMgZ3JvdXAuICBQ bGVhc2UgdGFrZSBhDQo+IGxvb2sgYW5kIGxldCB1cyBrbm93IHlvdXIgdGhvdWdodHMgYW5kIGNv bW1lbnRzLg0KPg0KPg0KPg0KPiBUaGFua3MsDQo+DQo+DQo+DQo+IEFsZXggJiBMaXNhDQo+DQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo= From j.schoenwaelder@jacobs-university.de Tue Sep 4 15:36:59 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 953A321E8082 for ; Tue, 4 Sep 2012 15:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAN19ni3oLV0 for ; Tue, 4 Sep 2012 15:36:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8175921E805A for ; Tue, 4 Sep 2012 15:36:58 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 036CF20C2E; Wed, 5 Sep 2012 00:36:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ojyVRfhKzacV; Wed, 5 Sep 2012 00:36:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FD5720C2D; Wed, 5 Sep 2012 00:36:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7FE20218E716; Wed, 5 Sep 2012 00:36:51 +0200 (CEST) Date: Wed, 5 Sep 2012 00:36:51 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20120904223650.GA57966@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Andy Bierman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 04 Sep 2012 22:36:59 -0000 On Tue, Sep 04, 2012 at 08:08:25PM +0000, Alexander Clemm (alex) wrote: >=20 > The second issue concerns the reset issue per se. I am certainly aware o= f the corresponding discussion in conjunction with SNMP. Again, the questi= on is whether to offer such a facility at all. Certainly, the argument of = wanting to avoid clients needing to be aware of resets is valid as well. A= t the same time, the context of Netconf makes some things arguably a little= different. For one, we have the ability to invoke a separate reset "actio= n", which resets the value as a "side effect" as opposed to setting it dire= ctly. This action can certainly have other "side effects", such as recordi= ng the time the last reset occurred and a "counter reset" notification. (A= rguably, those need to be introduced, but good to have a discussion on this= up front). Also, SNMP was connectionless, unreliable etc, unlike Netconf,= so there is less of an issue of clients missing notifications. Anyway, it= may be good to have an clear policy here - is it the expectation that the = SNMP policy is st > ill in effect, or should it be adjusted? =20 >=20 Counters have discontinuities. This is true even in SNMP land and hence we have so called discontinuity indicators in various MIB modules, sysUpTime being the default. That said, in SNMP land we tried to minimize discontinuities since, as Andy said, counters are often read by multiple applications and every discontinuities bites other applications a bit. In SNMP land, the following principles were applied: a) A single counter reading has no meaning. You need to read a counter twice and calculate the rate of change. b) While reading counters to calculate the rate of change, you have to check any discontinuity objects in order to throw away readings in case a discontinuity occured. It is because of b) that you want to minimize discontinuities. [I know that we have zero-based counters where a single reading may be meaningful but that is not the point here.] The question which transport a network management protocol uses has nothing to do with this. A proper SNMP implementation (and not all programs get a) and b) done correctly) will deal with discontinuities by (at the end) discarding values. I believe these basic principles really did not change since the late 80s. If you share counters, minimize any discontinuities. [Even if you do down the path of inventing a notification and you mandate that notification support is in every application reading counters and the notification records the counter value before the reset, the value after the reset, and the timestamp, you still have a problem because the timestamp recorded at the server is only up to a certain precision synchronized with the timestamps maintained by the client.] /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Tue Sep 4 15:59: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 35C7F21E8082 for ; Tue, 4 Sep 2012 15:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y76EGDnEZERF for ; Tue, 4 Sep 2012 15:59:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA2B21E805A for ; Tue, 4 Sep 2012 15:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3927; q=dns/txt; s=iport; t=1346799548; x=1348009148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DUm9h+bbO8Wn02x9p5qoPmCjUB8rjf5Mq1KYyw7xB/s=; b=nJd7Jfvi40fp6dc3HMcYGnz3H7up7088E8A8WR9DdRmo/Lw4hfasb5Qr +WNWzR08voRfVrVGwlz3bigMegEeYbemD7bQHpgUzadiQq24RxzjA8Cf/ fMX+QGJsyI0WgqXto2DaX7SQ+C6iaj6xhbxzfTbt3mGp4yE2+5oCTgkQP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPCGRlCtJV2c/2dsb2JhbABCA7skgQeCIAEBAQQSASc/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAIEDgUIGodrmnOgLASLBYQRgkFgA6QMgWeCYw X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; d="scan'208";a="118228462" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2012 22:59:07 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q84Mx7HH015249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 22:59:07 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 17:59:07 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwCGKVAAABvERUAAIT48AAAAxCIwAA7HhYAACforUA== Date: Tue, 4 Sep 2012 22:59:06 +0000 Message-ID: References: <20120904223650.GA57966@elstar.local> In-Reply-To: <20120904223650.GA57966@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19162.001 x-tm-as-result: No--41.551100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 04 Sep 2012 22:59:09 -0000 Thank your for the response. =20 So, in summary, no reset capability for counters, regardless of protocol, m= echanism through which reset occurs, and auxiliary mechanisms to deal with = discontinuities. =20 I do agree with the argument and we've taken a note to take it out in the n= ext revision. =20 While on that topic, what is the sentiment on having counters/statistics at= all? One "best practice" could presumably be to restrict modules used for= configuration to configuration, leaving statistics as a completely separat= e topic. =20 --- Alex -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, September 04, 2012 3:37 PM To: Alexander Clemm (alex) Cc: Andy Bierman; netmod@ietf.org Subject: Re: [netmod] YANG module for ACL configuration On Tue, Sep 04, 2012 at 08:08:25PM +0000, Alexander Clemm (alex) wrote: >=20 > The second issue concerns the reset issue per se. I am certainly aware o= f the corresponding discussion in conjunction with SNMP. Again, the questi= on is whether to offer such a facility at all. Certainly, the argument of = wanting to avoid clients needing to be aware of resets is valid as well. A= t the same time, the context of Netconf makes some things arguably a little= different. For one, we have the ability to invoke a separate reset "actio= n", which resets the value as a "side effect" as opposed to setting it dire= ctly. This action can certainly have other "side effects", such as recordi= ng the time the last reset occurred and a "counter reset" notification. (A= rguably, those need to be introduced, but good to have a discussion on this= up front). Also, SNMP was connectionless, unreliable etc, unlike Netconf,= so there is less of an issue of clients missing notifications. Anyway, it= may be good to have an clear policy here - is it the expectation that the = SNMP policy is st > ill in effect, or should it be adjusted? =20 >=20 Counters have discontinuities. This is true even in SNMP land and hence we have so called discontinuity indicators in various MIB modules, sysUpTime being the default. That said, in SNMP land we tried to minimize discontinuities since, as Andy said, counters are often read by multiple applications and every discontinuities bites other applications a bit. In SNMP land, the following principles were applied: a) A single counter reading has no meaning. You need to read a counter twice and calculate the rate of change. b) While reading counters to calculate the rate of change, you have to check any discontinuity objects in order to throw away readings in case a discontinuity occured. It is because of b) that you want to minimize discontinuities. [I know that we have zero-based counters where a single reading may be meaningful but that is not the point here.] The question which transport a network management protocol uses has nothing to do with this. A proper SNMP implementation (and not all programs get a) and b) done correctly) will deal with discontinuities by (at the end) discarding values. I believe these basic principles really did not change since the late 80s. If you share counters, minimize any discontinuities. [Even if you do down the path of inventing a notification and you mandate that notification support is in every application reading counters and the notification records the counter value before the reset, the value after the reset, and the timestamp, you still have a problem because the timestamp recorded at the server is only up to a certain precision synchronized with the timestamps maintained by the client.] /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Sep 4 21:47: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 9978721F843F for ; Tue, 4 Sep 2012 21:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giMhq2FPTvHe for ; Tue, 4 Sep 2012 21:47:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BE32821F842B for ; Tue, 4 Sep 2012 21:47:01 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2C6620C32; Wed, 5 Sep 2012 06:47:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZOGOuRJnkay4; Wed, 5 Sep 2012 06:47:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40E0520C2A; Wed, 5 Sep 2012 06:47:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43FD4218E8FB; Wed, 5 Sep 2012 06:46:55 +0200 (CEST) Date: Wed, 5 Sep 2012 06:46:55 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20120905044654.GA58332@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Andy Bierman , "netmod@ietf.org" References: <20120904223650.GA57966@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] YANG module for ACL configuration 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, 05 Sep 2012 04:47:02 -0000 On Tue, Sep 04, 2012 at 10:59:06PM +0000, Alexander Clemm (alex) wrote: > While on that topic, what is the sentiment on having > counters/statistics at all? One "best practice" could presumably be > to restrict modules used for configuration to configuration, leaving > statistics as a completely separate topic. I think there is no clear "best practice". I assume once we have a solution how to deal with operational state, this will find an answer as well. /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 Wed Sep 5 00:30:31 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 3637521F8546; Wed, 5 Sep 2012 00:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpPR1vNCclGx; Wed, 5 Sep 2012 00:30:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD97A21F854C; Wed, 5 Sep 2012 00:30:30 -0700 (PDT) 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: 4.34 Message-ID: <20120905073030.22648.86754.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 00:30:30 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-06.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, 05 Sep 2012 07:30:31 -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 Working Gr= oup of the IETF. Title : A YANG Data Model for Interface Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-06.txt Pages : 33 Date : 2012-09-05 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Sep 5 00:32:48 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 2AA9921F8650; Wed, 5 Sep 2012 00:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TGkJLLguDCS; Wed, 5 Sep 2012 00:32:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96EC21F8630; Wed, 5 Sep 2012 00:32:47 -0700 (PDT) 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: 4.34 Message-ID: <20120905073247.29975.72307.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 00:32:47 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-06.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, 05 Sep 2012 07:32:48 -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 Working Gr= oup of the IETF. Title : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-06.txt Pages : 20 Date : 2012-09-05 Abstract: This document defines a YANG data model for configuration of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Wed Sep 5 00:55: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 ABF0921F866A for ; Wed, 5 Sep 2012 00:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JaoSkO93GjQ for ; Wed, 5 Sep 2012 00:55:36 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EA26C21F865F for ; Wed, 5 Sep 2012 00:55:35 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5DFFD12008D2 for ; Wed, 5 Sep 2012 09:55:34 +0200 (CEST) Date: Wed, 05 Sep 2012 09:55:34 +0200 (CEST) Message-Id: <20120905.095534.845848821252289168.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] interface and ip 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, 05 Sep 2012 07:55:36 -0000 Hi, I have published new versions (-06) of these documents. The biggest change is that all IF-MIB counters are added to the interface document. Please review to make sure the wglc comments are properly addressed. /martin From dromasca@avaya.com Wed Sep 5 02:57: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 737B621F846D for ; Wed, 5 Sep 2012 02:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ6X7lI3scqQ for ; Wed, 5 Sep 2012 02:57:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4419521F846A for ; Wed, 5 Sep 2012 02:57:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACMgR1DGmAcF/2dsb2JhbABFuxyBB4IgAQEBAQIBEh4KPwUHBAIBCA0EBAEBCwYMCwEGAUUJCAIEARIIGodlBp0fnSqLEYYiYAObWooZgmU X-IronPort-AV: E=Sophos;i="4.80,373,1344225600"; d="scan'208";a="323499566" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Sep 2012 05:53:45 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Sep 2012 05:51:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Sep 2012 11:57:34 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwCGKVAAABvERUAAIT48AAAAxCIwAA7HhYAACforUAADDw+w References: <20120904223650.GA57966@elstar.local> From: "Romascanu, Dan (Dan)" To: "Alexander Clemm (alex)" , "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] YANG module for ACL configuration 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, 05 Sep 2012 09:57:46 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Alexander Clemm (alex) > Sent: Wednesday, September 05, 2012 1:59 AM > To: Juergen Schoenwaelder > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG module for ACL configuration >=20 > Thank your for the response. > So, in summary, no reset capability for counters, regardless of > protocol, mechanism through which reset occurs, and auxiliary mechanisms > to deal with discontinuities. > I do agree with the argument and we've taken a note to take it out in > the next revision. [[DR]] This is much better, for all the good reasons already mentioned in the discussion.=20 > While on that topic, what is the sentiment on having counters/statistics > at all? One "best practice" could presumably be to restrict modules > used for configuration to configuration, leaving statistics as a > completely separate topic. [[DR]] We do not have yet enough practice, so we cannot assess what is the best. But this asks the question - what you exactly mean by 'leaving statistics as a completely separate topic'? Not using NETCONF at all for statistics, or defining as separate YANG modules.=20 Regards, Dan > --- Alex >=20 From yihuan@cisco.com Wed Sep 5 22:03:57 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 0D39921F853B for ; Wed, 5 Sep 2012 22:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j3sW74PuOKD for ; Wed, 5 Sep 2012 22:03:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AB27D21F8534 for ; Wed, 5 Sep 2012 22:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2317; q=dns/txt; s=iport; t=1346907835; x=1348117435; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Q10KGuYtMNrEJAzIvjug+RC9ja0L35zFlhLmGMcGVQU=; b=bd1xfkE6/Y9gYlV/Mc9CYQ8JWYiaVgU46nHSIF5HCOv5AmFhFj55bhiv gHmQG9kccbuaRn5r89gsHmXi6KJgciJodHV7ANCwYQazOYSfuxhTiSDQc fBPPiYrTX0MLKuVhj8O67sBXCDbbVHFbCCXnGYNmPhDOLLs2sx6fy7B7S k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABIuSFCtJV2a/2dsb2JhbABFuyOBB4IiAQQBAQEPASc0BBkBCA4oNwslAgQBEiKHawuaUqASBJFWA5VZjjOBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="118528318" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2012 05:03:55 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8653tkH022599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 05:03:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 00:03:54 -0500 From: "Lisa Huang (yihuan)" To: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] interface and ip Thread-Index: AQHNizvZbhukMpHxdESX2BeGt0Sy1Zd8oaoA Date: Thu, 6 Sep 2012 05:03:54 +0000 Message-ID: In-Reply-To: <20120905.095534.845848821252289168.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.166.126] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.004 x-tm-as-result: No--38.279400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <370815C5761AF540A7932586237F7F8F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] interface and ip 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, 06 Sep 2012 05:03:57 -0000 Martin, I have two comments for the choice of ipv4 subnet. First comment: The ipv4 container has a choice of subnet which I believe you mean choice of prefix-length or netmask. Adding a case statement will make the choice more clear. Here is the choice snippet. choice subnet { default prefix-length; description "The subnet can be specified as a prefix-length, or, if the server supports non-contiguous netmasks, as a netmask. The default subnet is a prefix-length of 32."; leaf prefix-length { type uint8 { range "0..32"; } default 32; description "The length of the subnet prefix."; } leaf netmask { if-feature non-contiguous-netmasks; type inet:ipv4-address; description "The subnet specified as a netmask."; } } >From the RFC, I could not derive the syntax means "prefix-length or net mask" when case statement is omitted. Here are some statement I quote from RFC6020 7.9.2: "The "case" statement is used to define branches of the choice." "As a shorthand, the "case" statement can be omitted if the branch contains a single "anyxml", "container", "leaf", "list", or "leaf-list" statement. In this case, the identifier of the case node is the same as the identifier in the branch statement." However, 0..n leaf can be the substatment of choice in section 7.9.1. Second comment: This is more a question than a comment. Prefix-length has type uint8, and netmask has type ipv4-address. Does ipv4-prefix in ietf-inet-types has any relationship with these two leaves? Thanks, Lisa On 9/5/12 12:55 AM, "Martin Bjorklund" wrote: >Hi, > >I have published new versions (-06) of these documents. The biggest >change is that all IF-MIB counters are added to the interface >document. > >Please review to make sure the wglc comments are properly addressed. > > >/martin >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Thu Sep 6 04:05: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 5965721F863C for ; Thu, 6 Sep 2012 04:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc2wWiIj2ahv for ; Thu, 6 Sep 2012 04:05:50 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C171F21F863B for ; Thu, 6 Sep 2012 04:05:50 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 998C01200AE5; Thu, 6 Sep 2012 13:05:48 +0200 (CEST) Date: Thu, 06 Sep 2012 13:05:48 +0200 (CEST) Message-Id: <20120906.130548.1911039463275512904.mbj@tail-f.com> To: yihuan@cisco.com From: Martin Bjorklund In-Reply-To: References: <20120905.095534.845848821252289168.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interface and ip 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, 06 Sep 2012 11:05:51 -0000 Hi, "Lisa Huang (yihuan)" wrote: > Martin, > > I have two comments for the choice of ipv4 subnet. > > First comment: The ipv4 container has a choice of subnet which I believe > you mean choice of prefix-length or netmask. Adding a case statement will > make the choice more clear. Ok. > Here is the choice snippet. > > choice subnet { > default prefix-length; > description > "The subnet can be specified as a prefix-length, or, > if the server supports non-contiguous netmasks, as > a netmask. > > The default subnet is a prefix-length of 32."; > leaf prefix-length { > type uint8 { > range "0..32"; > } > default 32; > description > "The length of the subnet prefix."; > } > leaf netmask { > if-feature non-contiguous-netmasks; > type inet:ipv4-address; > description > "The subnet specified as a netmask."; > } > } > > > From the RFC, I could not derive the syntax means "prefix-length or net > mask" when case statement is omitted. Here are some statement I quote from > RFC6020 7.9.2: > > > "The "case" statement is used to define branches of the choice." > > > "As a shorthand, the "case" statement can be omitted if the branch > contains a single "anyxml", "container", "leaf", "list", or > "leaf-list" statement. In this case, the identifier of the case node > is the same as the identifier in the branch statement." > > However, 0..n leaf can be the substatment of choice in section 7.9.1. Right. So, it says that if you have a branch with a single leaf, such as: choice subnet { case prefix-length { leaf prefix-length { ... } } case ... } you can omit the case statement: choice subnet { leaf prefix-length { ... } case ... } > Second comment: This is more a question than a comment. Prefix-length has > type uint8, and netmask has type ipv4-address. Does ipv4-prefix in > ietf-inet-types has any relationship with these two leaves? The ipv4-prefix type could have been used to indicate the subnet in the 'prefix-length' case, but then you'd have to enter duplicate info, and it wouldn't work with the 'netmask' case. With the ipv4-prefix type: 10.0.0.1 10.0.0.0/24 With the current model: 10.0.0.1 24 /martin From lhotka@nic.cz Thu Sep 6 04:48: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 1F9EA21F8570 for ; Thu, 6 Sep 2012 04:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cghZAay-IXWJ for ; Thu, 6 Sep 2012 04:48:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F821F8552 for ; Thu, 6 Sep 2012 04:48:35 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5A2B713F952 for ; Thu, 6 Sep 2012 13:48:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1346932114; bh=7hFz8giWXlQf92NIPTMoWSSiCsuzJoF4bgseye7ayjI=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=UvpUi5Ho3XAEU5IFDW0BGq2GxqbXyVgZ9jp5wySATlcNQMs/vZB1ezUfPwTIje4Q9 QQYpJiFvvRlYhCT8JIa5Yl3rAlHif3xBOzombkLOekW21Uu24NoH3IkRFIdaFVusJ/ Dq4AFijYTTK3XObizSXTOVZ17A4JHQTG0aJgLacU= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 6 Sep 2012 13:48:33 +0200 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] routing-cfg issues 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, 06 Sep 2012 11:48:36 -0000 Hi, the WGLC for the routing-cfg document resulted in several open issues = where I am not sure how to proceed. I am summarising these issues below = and listing the available options that are known to me. Please express = your opinions. Thanks, Lada 1. Multiple router instances ---------------------------- Phil Shafer argued that the present attempt to provide a list of router = instances as a "one size fits all" means for implementing various forms = of router virtualisation (complete logical routers, VRF instances for = MLPS etc.) is doomed to failure. He proposed to get rid of this list and = deal with just a single router instance in the core model. Every = virtualisation style then would define its own data model, possibly = repeating some data nodes from the core model. On the other hand, previously I received positive feedback on having the = list of router instances in the core model. Options: 1.1. Do nothing. 1.2. Add the "type" leaf under "router" so that router instances of = different virtualisation types can coexist in the same list, have their = specific data etc. 1.3. Remove the list and have just one router instance. 2. Required list entries ------------------------ The core routing model requires that certain objects (typically list = entries) exist in every implementation - for example the main routing = table, or the "direct" routing protocol. These objects are supposed to = be provided by the device, so they are in fact operational state data. = However, other entries in the same type may be configured by the client. = It is necessary to be able to refer from the same location (a leafref = node) both to the system-provided entry and to the configured entries. Options: 2.1. Implementations will supply the mandatory objects as entries of a = config=3Dtrue list but declare them read-only so that they cannot be = deleted by the client. 2.2. The mandatory entries will exist as state data, but outside the = core data model. A client wanting to refer to them will have to = explicitly configure a corresponding dummy entry in the config=3Dtrue = list and refer to this entry. 3. Designating the main routing table ------------------------------------- The core routing model requires that every implementation have the main = routing table for each protocol family, which is the destination for = direct routes and default destination for other routes. The text = currently fixes the name of the main routing table (using SHOULD) to = "main-ipv4-unicast" etc. So this is the way how the main table can be = recognised among other routing tables. Several different changes have = been proposed during the WGLC: Martin and Wes proposed to make the name = a MUST instead of SHOULD, whilst Andy argued that semantics should not = be encoded in the name.=20 Options: 3.1. Really fix the main routing table name, i.e. make it a MUST. 3.2. Introduce a new leaf node, e.g. "main-routing-table", pointing to = the main table.=20 3.3. Add the "type" leaf under "routing-table" and use it for = distinguishing the main routing table from the rest. =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From yihuan@cisco.com Thu Sep 6 08:34:45 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 9FE0921F86EE for ; Thu, 6 Sep 2012 08:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQb2qkASJJXT for ; Thu, 6 Sep 2012 08:34:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9521F85AC for ; Thu, 6 Sep 2012 08:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3047; q=dns/txt; s=iport; t=1346945685; x=1348155285; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2OGUuT30G++xQ08dp8Dt6z6LPT++dqkOUZpWIWWnhFE=; b=VXOV2Ov3jEOSoycKPBSIbtAsQjlmUvH6jV/WiEMbjM+zm00qsovlkkYE 0gjBVlI9md/eQLxSSqG0Vj8LFtL/Rwj/EkoDwK7X235l967+NOXingCEe TiKR+UK6m1xpmrSbracy8o7K/muVXmrA1ueZ3FSpmB530nZ5T4iR8H2vA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKDBSFCtJV2b/2dsb2JhbABFuyKBB4IgAQEBBBIBJzgHEgEIDgoeQiUCBA4FIodrmwKgIpFWA5VZjjOBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="118947534" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 06 Sep 2012 15:34:44 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q86FYibP027943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 15:34:44 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 10:34:44 -0500 From: "Lisa Huang (yihuan)" To: Martin Bjorklund Thread-Topic: [netmod] interface and ip Thread-Index: AQHNizvZbhukMpHxdESX2BeGt0Sy1Zd8oaoAgADa0wD//9XQAA== Date: Thu, 6 Sep 2012 15:34:43 +0000 Message-ID: In-Reply-To: <20120906.130548.1911039463275512904.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.166.54] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.005 x-tm-as-result: No--37.449900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 06 Sep 2012 15:34:45 -0000 Thanks, Martin. I think the example in the RFC need to be updated to make it more clear. Not related to this I-D though. On 9/6/12 4:05 AM, "Martin Bjorklund" wrote: >Hi, > >"Lisa Huang (yihuan)" wrote: >> Martin, >>=20 >> I have two comments for the choice of ipv4 subnet. >>=20 >> First comment: The ipv4 container has a choice of subnet which I believe >> you mean choice of prefix-length or netmask. Adding a case statement >>will >> make the choice more clear. > >Ok. > >> Here is the choice snippet. >>=20 >> choice subnet { >> default prefix-length; >> description >> "The subnet can be specified as a prefix-length, or, >> if the server supports non-contiguous netmasks, as >> a netmask. >>=20 >> The default subnet is a prefix-length of 32."; >> leaf prefix-length { >> type uint8 { >> range "0..32"; >> } >> default 32; >> description >> "The length of the subnet prefix."; >> } >> leaf netmask { >> if-feature non-contiguous-netmasks; >> type inet:ipv4-address; >> description >> "The subnet specified as a netmask."; >> } >> } >>=20 >>=20 >> From the RFC, I could not derive the syntax means "prefix-length or net >> mask" when case statement is omitted. Here are some statement I quote >>from >> RFC6020 7.9.2: >>=20 >>=20 >> "The "case" statement is used to define branches of the choice." >>=20 >>=20 >> "As a shorthand, the "case" statement can be omitted if the branch >> contains a single "anyxml", "container", "leaf", "list", or >> "leaf-list" statement. In this case, the identifier of the case node >> is the same as the identifier in the branch statement." >>=20 >> However, 0..n leaf can be the substatment of choice in section 7.9.1. > >Right. So, it says that if you have a branch with a single leaf, such >as: > > choice subnet { > case prefix-length { > leaf prefix-length { > ... > } > } > case ... > } > >you can omit the case statement: > > choice subnet { > leaf prefix-length { > ... > } > case ... > } > > >> Second comment: This is more a question than a comment. Prefix-length >>has >> type uint8, and netmask has type ipv4-address. Does ipv4-prefix in >> ietf-inet-types has any relationship with these two leaves? > >The ipv4-prefix type could have been used to indicate the subnet in >the 'prefix-length' case, but then you'd have to enter duplicate info, >and it wouldn't work with the 'netmask' case. > >With the ipv4-prefix type: > > 10.0.0.1 > 10.0.0.0/24 > >With the current model: > > 10.0.0.1 > 24 > > > >/martin From j.schoenwaelder@jacobs-university.de Fri Sep 7 02:31: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 2DC9C21F8767 for ; Fri, 7 Sep 2012 02:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acZzxY2M5fui for ; Fri, 7 Sep 2012 02:31:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2679721F8766 for ; Fri, 7 Sep 2012 02:31:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1283B20C87; Fri, 7 Sep 2012 11:31:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4k6B3WIrdvQL; Fri, 7 Sep 2012 11:31:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F3B720C64; Fri, 7 Sep 2012 11:31:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AEE70219478C; Fri, 7 Sep 2012 11:31:34 +0200 (CEST) Date: Fri, 7 Sep 2012 11:31:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120907093134.GA63128@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Help the NomCom: Nominations and Feedback 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, 07 Sep 2012 09:31:42 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please help the NOMCOM to do its important work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --EVF5PPMfhYS0aIcm Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS04.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.318.1; Thu, 6 Sep 2012 02:21:27 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 449AB20C00 for ; Thu, 6 Sep 2012 02:21:36 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 402F994 for ; Thu, 6 Sep 2012 02:21:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Authentication-Results: demetrius3.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id oipJX-ZtXKkO for ; Thu, 6 Sep 2012 02:21:34 +0200 (CEST) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -7.6 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by atlas2a.jacobs-university.de (Postfix) with ESMTP for ; Thu, 6 Sep 2012 02:21:34 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBBF21F8717; Wed, 5 Sep 2012 17:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1346890892; bh=Arzig7coUtTTccKN5bJqrvD7gGRE64NMEfB+uhbql1U=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=SRx+amRirpWhC1cupVgpZnKkeFhg90bz1QcmSjsF1cVwiInKfXIa99clvsOrgblx+ nn6dzjnkXaAPE/3+qLaYnbxN3HroXTBcKVEkDZcdrMqa6OxBU6C4cSoT3wZ4CAkjK5 0UAFS7pL+FXQ61h0lxMFb1w/A1ofLwrOGEPPckZo= X-Original-To: wgchairs@ietfa.amsl.com Delivered-To: wgchairs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5131721F8714 for ; Wed, 5 Sep 2012 17:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8wiyhqbCzNa for ; Wed, 5 Sep 2012 17:21:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E6621F8570 for ; Wed, 5 Sep 2012 17:21:29 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: NomCom Chair To: Working Group Chairs Subject: Help the NomCom: Nominations and Feedback X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> Date: Wed, 5 Sep 2012 17:21:29 -0700 X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Errors-To: wgchairs-bounces@ietf.org Return-Path: wgchairs-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS04.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 The IETF Nominations Committee (NomCom) is currently seeking=20 nominations for individuals to serve on the IESG, IAB, and IAOC.=20 Additionally, this is an announcement that the NomCom is seeking=20 feedback on individuals who have accepted nominations for IETF=20 leadership positions.=20 It is very important to the NomCom process that we get input from a=20 broad spectrum of the community. Therefore, in case members of your=20 working group do not read the IETF announcement and discussion lists,=20 the NomCom would appreciate your help in disseminating the following=20 information. The NomCom website contains information about this year's NomCom=20 including the positions we are seeking to fill, and the qualifications=20 required for these positions: https://www.ietf.org/group/nomcom/2012/ The NomCom is accepting nominations until September 24. Nominations=20 for any position can be made using the following web tool: https://www.ietf.org/group/nomcom/2012/nominate Feedback about individuals who the NomCom is considering can be=20 providing using the following web tool: https://www.ietf.org/group/nomcom/2012/input The feedback tool provides a list of individuals who have agreed to be=20 considered for each position. We will be updating this list in the coming=20 weeks as more individuals accept nominations. Feedback provided to the NomCom is kept strictly confidential! Note that use of the NomCom web tools require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ As an alternative to using the web tools, you can send email to the NomCom at nomcom12@ietf.org to make a nomination or provide input to the committee. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org --EVF5PPMfhYS0aIcm-- From lhotka@nic.cz Fri Sep 7 05:57:47 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 9518621F86F4 for ; Fri, 7 Sep 2012 05:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKFCmNpga4PH for ; Fri, 7 Sep 2012 05:57:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A94FB21F86EC for ; Fri, 7 Sep 2012 05:57:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E7D7F5405B4 for ; Fri, 7 Sep 2012 14:57:44 +0200 (CEST) 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 aqwU65wuxnuU for ; Fri, 7 Sep 2012 14:57:34 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 56A365405A2 for ; Fri, 7 Sep 2012 14:57:33 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120905.095534.845848821252289168.mbj@tail-f.com> References: <20120905.095534.845848821252289168.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 07 Sep 2012 14:57:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 12:57:47 -0000 Hi, I have some concerns regarding transferrability of interface configurations. For example, one may want to replace a router with a similar one from a different vendor, or simply replace an Ethernet card with another brand. In both cases, the names of physical interface(s) might change. It would be nice to be able to take the old configuration and use it with the new hardware, perhaps after making a few trivial changes. With the current interfaces module it is not that easy because: 1. interface name is the list key, so it cannot be updated in place, 2. all references via "interface-ref" will have to be updated. So my suggestion is to introduce an indirection by means of adding another leaf, e.g. "physical-name". "name" will remain the list key but it will be an arbitrary client-selected identifier. Another option is to have an extra list in the role of a translation table: The server could fill in the real physical interface names (= state data, and keys of this list), and the client would add an interface-ref to each entry defining the mapping. Lada Martin Bjorklund writes: > Hi, > > I have published new versions (-06) of these documents. The biggest > change is that all IF-MIB counters are added to the interface > document. > > Please review to make sure the wglc comments are properly addressed. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From pgili@cisco.com Fri Sep 7 06:14:48 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 E271221F86C2 for ; Fri, 7 Sep 2012 06:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwwIhkpoqaXq for ; Fri, 7 Sep 2012 06:14:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3243F21F858F for ; Fri, 7 Sep 2012 06:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1347023688; x=1348233288; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=08zFh7r2U42NmiiNlDfAvHl5bpkh2rlO1fQZ3r/4js8=; b=k+aaJospqnRN5VYAIagCg9qBm4MXjhBvhIZrxEYDt8V103XID+6qmW57 Wv4y+nZnDhG8BuNys4Cgt0RxRjMW9y9gEGbXD0al41j10M67U67COxChk eiOCSQDeQfT5bMvERdu+XURLLPwG5Wwfb+9JcraAO4Zex5S8FV2hWDV83 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABzzSVCtJV2Y/2dsb2JhbABFuzmBB4IgAQEBAwEBAQEPASc0EAcEAgEIEQQBAQsUCQcnCxQJCAIEAQkJCBqHaAYLmxagQwSLEoVUYAOkEoFngmQ X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="119305798" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 07 Sep 2012 13:14:26 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q87DEQpb002859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 13:14:26 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Fri, 7 Sep 2012 08:14:26 -0500 From: "Patrick Gili (pgili)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] interface and ip Thread-Index: AQHNjPhYbhukMpHxdESX2BeGt0Sy1Zd+2xCg Date: Fri, 7 Sep 2012 13:14:25 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB04E741@xmb-aln-x14.cisco.com> References: <20120905.095534.845848821252289168.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.102] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--38.795800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 13:14:49 -0000 Lada, I think you are referring to the equivalent of the ifAlias defined by the I= F-MIB. There is mention of it in the ietf-interfaces YANG module, but as pa= rt of the description element, which I thought was somewhat strange. -Patrick -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Ladislav Lhotka Sent: Friday, September 07, 2012 8:58 AM To: netmod@ietf.org Subject: Re: [netmod] interface and ip Hi, I have some concerns regarding transferrability of interface configurations= . For example, one may want to replace a router with a similar one from a d= ifferent vendor, or simply replace an Ethernet card with another brand. In = both cases, the names of physical interface(s) might change. It would be nice to be able to take the old configuration and use it with t= he new hardware, perhaps after making a few trivial changes. With the curre= nt interfaces module it is not that easy because: 1. interface name is the list key, so it cannot be updated in place, 2. all references via "interface-ref" will have to be updated. So my suggestion is to introduce an indirection by means of adding another = leaf, e.g. "physical-name". "name" will remain the list key but it will be = an arbitrary client-selected identifier.=20 Another option is to have an extra list in the role of a translation table:= The server could fill in the real physical interface names (=3D state data= , and keys of this list), and the client would add an interface-ref to each= entry defining the mapping. Lada Martin Bjorklund writes: > Hi, > > I have published new versions (-06) of these documents. The biggest=20 > change is that all IF-MIB counters are added to the interface=20 > document. > > Please review to make sure the wglc comments are properly addressed. > > > /martin > _______________________________________________ > 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 Fri Sep 7 06:31: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 4F91221F856D for ; Fri, 7 Sep 2012 06:31:43 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EZH+NEw5Ohg for ; Fri, 7 Sep 2012 06:31:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 70BDB21F8568 for ; Fri, 7 Sep 2012 06:31:42 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id CD191140421; Fri, 7 Sep 2012 15:31:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347024700; bh=2GauLV0/Sfil4i68uiqo1XhsvtQ9TDNM6HI+WVf0dGo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ghbn/mb3lprRLPVHScwH0CxLxjYgEYR1coANMGP/yuZz/sNUJ//sZKW4NH9xF8jrN Ft39wyjK5bAPKD7IV6/+N+Ct2JPDAHtX3Ki4kWEapmQFE4++NxElBHc5hSBcSjksk0 AoLmiaSPOSiRHqzKmW4UhbkoTRvXbNHzo9g1NynM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB04E741@xmb-aln-x14.cisco.com> Date: Fri, 7 Sep 2012 15:31:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34A1A1DF-39EA-4F1B-A8D2-BB596A497D26@nic.cz> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB04E741@xmb-aln-x14.cisco.com> To: "Patrick Gili (pgili)" X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 13:31:43 -0000 On Sep 7, 2012, at 3:14 PM, "Patrick Gili (pgili)" = wrote: > Lada, >=20 > I think you are referring to the equivalent of the ifAlias defined by = the IF-MIB. There is mention of it in the ietf-interfaces YANG module, = but as part of the description element, which I thought was somewhat = strange. Yes, but an important point is also what the list key is. My suggestion = is to have a non-volatile client-selected name (which is indeed what = ifAlias is) as the key for the interface list.=20 Lada >=20 > -Patrick >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On = Behalf Of Ladislav Lhotka > Sent: Friday, September 07, 2012 8:58 AM > To: netmod@ietf.org > Subject: Re: [netmod] interface and ip >=20 > Hi, >=20 > I have some concerns regarding transferrability of interface = configurations. For example, one may want to replace a router with a = similar one from a different vendor, or simply replace an Ethernet card = with another brand. In both cases, the names of physical interface(s) = might change. >=20 > It would be nice to be able to take the old configuration and use it = with the new hardware, perhaps after making a few trivial changes. With = the current interfaces module it is not that easy because: >=20 > 1. interface name is the list key, so it cannot be updated in place, >=20 > 2. all references via "interface-ref" will have to be updated. >=20 > So my suggestion is to introduce an indirection by means of adding = another leaf, e.g. "physical-name". "name" will remain the list key but = it will be an arbitrary client-selected identifier.=20 >=20 > Another option is to have an extra list in the role of a translation = table: The server could fill in the real physical interface names (=3D = state data, and keys of this list), and the client would add an = interface-ref to each entry defining the mapping. >=20 > Lada >=20 > Martin Bjorklund writes: >=20 >> Hi, >>=20 >> I have published new versions (-06) of these documents. The biggest=20= >> change is that all IF-MIB counters are added to the interface=20 >> document. >>=20 >> Please review to make sure the wglc comments are properly addressed. >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From pgili@cisco.com Fri Sep 7 06:33: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 9DBE521E8051 for ; Fri, 7 Sep 2012 06:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyc4teAy2psJ for ; Fri, 7 Sep 2012 06:33:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3721E8050 for ; Fri, 7 Sep 2012 06:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3093; q=dns/txt; s=iport; t=1347024782; x=1348234382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CJ5oGwpaYDDWOVfD81AgSbghWd+egGR7RaoMiI7o3Xs=; b=X7Jhy7SbXdoFiTh+WQGhSsS6+gzH5p9GJ9oLH3b1/5Rbcy2TW79c9PAt 93+6Wuah754SYKfNzRBN6kqu8c+E8ztYWQKXh5iDBIT2pDUoV6ZjDr3t5 UA4dnEqJ24Uqliqkv0pHkPUth5S+49O6vPQc1FGhbsom0wFBDTFutZJUA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHn2SVCtJXG8/2dsb2JhbABFuzmBB4IgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgCBAoEBQgah2gGC5saoEMEixKFVGADpBKBZ4Jk X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="119309627" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 07 Sep 2012 13:33:02 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q87DX22k014825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 13:33:02 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Fri, 7 Sep 2012 08:33:01 -0500 From: "Patrick Gili (pgili)" To: Ladislav Lhotka Thread-Topic: [netmod] interface and ip Thread-Index: AQHNjPhYbhukMpHxdESX2BeGt0Sy1Zd+2xCggABZCgD//6xZQA== Date: Fri, 7 Sep 2012 13:33:01 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB04E798@xmb-aln-x14.cisco.com> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB04E741@xmb-aln-x14.cisco.com> <34A1A1DF-39EA-4F1B-A8D2-BB596A497D26@nic.cz> In-Reply-To: <34A1A1DF-39EA-4F1B-A8D2-BB596A497D26@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.102] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--46.627700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 13:33:03 -0000 Lada, It is always possible to create another list that references interfaces but= keys off something like description or alias or whatever. -Patrick -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Friday, September 07, 2012 9:32 AM To: Patrick Gili (pgili) Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip On Sep 7, 2012, at 3:14 PM, "Patrick Gili (pgili)" wrote: > Lada, >=20 > I think you are referring to the equivalent of the ifAlias defined by the= IF-MIB. There is mention of it in the ietf-interfaces YANG module, but as = part of the description element, which I thought was somewhat strange. Yes, but an important point is also what the list key is. My suggestion is = to have a non-volatile client-selected name (which is indeed what ifAlias i= s) as the key for the interface list.=20 Lada >=20 > -Patrick >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On=20 > Behalf Of Ladislav Lhotka > Sent: Friday, September 07, 2012 8:58 AM > To: netmod@ietf.org > Subject: Re: [netmod] interface and ip >=20 > Hi, >=20 > I have some concerns regarding transferrability of interface configuratio= ns. For example, one may want to replace a router with a similar one from a= different vendor, or simply replace an Ethernet card with another brand. I= n both cases, the names of physical interface(s) might change. >=20 > It would be nice to be able to take the old configuration and use it with= the new hardware, perhaps after making a few trivial changes. With the cur= rent interfaces module it is not that easy because: >=20 > 1. interface name is the list key, so it cannot be updated in place, >=20 > 2. all references via "interface-ref" will have to be updated. >=20 > So my suggestion is to introduce an indirection by means of adding anothe= r leaf, e.g. "physical-name". "name" will remain the list key but it will b= e an arbitrary client-selected identifier.=20 >=20 > Another option is to have an extra list in the role of a translation tabl= e: The server could fill in the real physical interface names (=3D state da= ta, and keys of this list), and the client would add an interface-ref to ea= ch entry defining the mapping. >=20 > Lada >=20 > Martin Bjorklund writes: >=20 >> Hi, >>=20 >> I have published new versions (-06) of these documents. The biggest=20 >> change is that all IF-MIB counters are added to the interface=20 >> document. >>=20 >> Please review to make sure the wglc comments are properly addressed. >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Sep 7 06:38: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 80DF721E8051 for ; Fri, 7 Sep 2012 06:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXolGAFf3c4q for ; Fri, 7 Sep 2012 06:38:54 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id F0B0221E8050 for ; Fri, 7 Sep 2012 06:38:53 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7979E1200D29; Fri, 7 Sep 2012 15:38:52 +0200 (CEST) Date: Fri, 07 Sep 2012 15:38:52 +0200 (CEST) Message-Id: <20120907.153852.1650771442949102026.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120905.095534.845848821252289168.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interface and ip 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, 07 Sep 2012 13:38:54 -0000 Ladislav Lhotka wrote: > Hi, > > I have some concerns regarding transferrability of interface > configurations. For example, one may want to replace a router with a > similar one from a different vendor, or simply replace an Ethernet > card with another brand. In both cases, the names of physical > interface(s) might change. > > It would be nice to be able to take the old configuration and use it > with the new hardware, perhaps after making a few trivial > changes. With the current interfaces module it is not that easy > because: > > 1. interface name is the list key, so it cannot be updated in place, > > 2. all references via "interface-ref" will have to be updated. > > So my suggestion is to introduce an indirection by means of adding > another leaf, e.g. "physical-name". "name" will remain the list key > but it will be an arbitrary client-selected identifier. If the key "name" is truly arbitrary and all implementations MUST handle this, then a "physical-name" is not really needed. Note that we already have "type" and "location", so with an arbitrary name you could create a new interface like this: my-new-interface ethernet 0/1 If a vendor needs an indirection or not would be an implementation detail. A vendor could of course also add a "internal-name" config false leaf through an augmentation, if it helps the operator. The original reason for the text on "name" A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. was to make it easier to implement. /martin From mbj@tail-f.com Fri Sep 7 06:43: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 468A921F8545 for ; Fri, 7 Sep 2012 06:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj31ilD55MGu for ; Fri, 7 Sep 2012 06:43:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 54A0621F854C for ; Fri, 7 Sep 2012 06:43:03 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A24881200D73; Fri, 7 Sep 2012 15:43:02 +0200 (CEST) Date: Fri, 07 Sep 2012 15:43:02 +0200 (CEST) Message-Id: <20120907.154302.2116569857132336859.mbj@tail-f.com> To: pgili@cisco.com From: Martin Bjorklund In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB04E798@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB04E741@xmb-aln-x14.cisco.com> <34A1A1DF-39EA-4F1B-A8D2-BB596A497D26@nic.cz> <50E64ADF99EAEE4CACEC18958F0FC0AB04E798@xmb-aln-x14.cisco.com> X-Mailer: Mew version 6.4 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] interface and ip 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, 07 Sep 2012 13:43:05 -0000 Hi, "Patrick Gili (pgili)" wrote: > It is always possible to create another list that references > interfaces but keys off something like description or alias or > whatever. The problem Lada is describing is that the key in the interface list will be used by other data models referring to a specific interface. So these interface names will be scattered all over, when you do or . This means that if vendor X enforces a different naming scheme than vendor Y, it will be difficult to move configuration snippets from one vendor to the other. With arbitrary names this would not be a problem. /martin From lhotka@nic.cz Fri Sep 7 06:45: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 1172921F8629 for ; Fri, 7 Sep 2012 06:45:40 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RE5xqp4RNR7 for ; Fri, 7 Sep 2012 06:45:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF3121F8554 for ; Fri, 7 Sep 2012 06:45:39 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 3E120140421; Fri, 7 Sep 2012 15:45:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347025538; bh=MLuNDeJ+442PRlrzBMViuecdxuwV+MMj8HwuWNwyI9o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZNYaWeplZKjGHwN52dLn+iZnKmLVWeipUkiWjeQA9fI9u7hLFELMtJtpJecY+cUvw uem0wTrFJREDNpMnBhn9NLLKaJGoZQ6JUExViJpJ4hQ5jfpLKt3cYkoYM9k27nnsgZ I5fANos5uORtrn3brOw6VzqzsWUMO8qoYStOSkZA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB04E798@xmb-aln-x14.cisco.com> Date: Fri, 7 Sep 2012 15:45:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C94F015-EED4-45A5-8799-95C27065DD99@nic.cz> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB04E741@xmb-aln-x14.cisco.com> <34A1A1DF-39EA-4F1B-A8D2-BB596A497D26@nic.cz> <50E64ADF99EAEE4CACEC18958F0FC0AB04E798@xmb-aln-x14.cisco.com> To: "Patrick Gili (pgili)" X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 13:45:40 -0000 On Sep 7, 2012, at 3:33 PM, "Patrick Gili (pgili)" = wrote: > Lada, >=20 > It is always possible to create another list that references = interfaces but keys off something like description or alias or whatever. Do you mean that I can use "description" for referring to an interface = via a leafref node? This is true but the draft recommends to use the = interface-ref type for such references. Lada =20 >=20 > -Patrick >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Friday, September 07, 2012 9:32 AM > To: Patrick Gili (pgili) > Cc: netmod@ietf.org > Subject: Re: [netmod] interface and ip >=20 >=20 > On Sep 7, 2012, at 3:14 PM, "Patrick Gili (pgili)" = wrote: >=20 >> Lada, >>=20 >> I think you are referring to the equivalent of the ifAlias defined by = the IF-MIB. There is mention of it in the ietf-interfaces YANG module, = but as part of the description element, which I thought was somewhat = strange. >=20 > Yes, but an important point is also what the list key is. My = suggestion is to have a non-volatile client-selected name (which is = indeed what ifAlias is) as the key for the interface list.=20 >=20 > Lada >=20 >>=20 >> -Patrick >>=20 >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On=20 >> Behalf Of Ladislav Lhotka >> Sent: Friday, September 07, 2012 8:58 AM >> To: netmod@ietf.org >> Subject: Re: [netmod] interface and ip >>=20 >> Hi, >>=20 >> I have some concerns regarding transferrability of interface = configurations. For example, one may want to replace a router with a = similar one from a different vendor, or simply replace an Ethernet card = with another brand. In both cases, the names of physical interface(s) = might change. >>=20 >> It would be nice to be able to take the old configuration and use it = with the new hardware, perhaps after making a few trivial changes. With = the current interfaces module it is not that easy because: >>=20 >> 1. interface name is the list key, so it cannot be updated in place, >>=20 >> 2. all references via "interface-ref" will have to be updated. >>=20 >> So my suggestion is to introduce an indirection by means of adding = another leaf, e.g. "physical-name". "name" will remain the list key but = it will be an arbitrary client-selected identifier.=20 >>=20 >> Another option is to have an extra list in the role of a translation = table: The server could fill in the real physical interface names (=3D = state data, and keys of this list), and the client would add an = interface-ref to each entry defining the mapping. >>=20 >> Lada >>=20 >> Martin Bjorklund writes: >>=20 >>> Hi, >>>=20 >>> I have published new versions (-06) of these documents. The biggest=20= >>> change is that all IF-MIB counters are added to the interface=20 >>> document. >>>=20 >>> Please review to make sure the wglc comments are properly addressed. >>>=20 >>>=20 >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Fri Sep 7 06:46: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 2287E21F8694 for ; Fri, 7 Sep 2012 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgJ6C1pKxn3a for ; Fri, 7 Sep 2012 06:46:42 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1B21F8554 for ; Fri, 7 Sep 2012 06:46:39 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUEn6vhMM2MWhTFm+cZ9X8KGPAMx5pdLX@postini.com; Fri, 07 Sep 2012 06:46:42 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 7 Sep 2012 06:42:11 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q87DgAh50382; Fri, 7 Sep 2012 06:42:10 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q87DfF8w083911; Fri, 7 Sep 2012 09:41:33 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201209071341.q87DfF8w083911@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <34A1A1DF-39EA-4F1B-A8D2-BB596A497D26@nic.cz> Date: Fri, 7 Sep 2012 09:41:15 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 13:46:43 -0000 Ladislav Lhotka writes: >Yes, but an important point is also what the list key is. My suggestion is to have a non >-volatile client-selected name (which is indeed what ifAlias is) as the key for the inte >rface list. Forcing use of ifAlias would be fairly shocking to your user population and the benefits would only be when swapping devices from distinct vendors, which turns out to be a fairly rare event. And even when that event occurs, the real underlaying device name would need to be fixed, limiting that benefit. And forcing this would result in >99.999% of operators using an alias identical to the underlaying interface name ;^) What might be more apropros would be something like what we've just added to junos: a wildcarded regex-based name replacement operation, so I can say "turn all references to '10.1.2.3' to '10.4.5.6'". It's more useful, generic, and allows one to make global change/replace operations like interface name substitutions without requiring non-specific user-defined interface names. Thanks, Phil From lhotka@nic.cz Fri Sep 7 07:24: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 3D98E21F853C for ; Fri, 7 Sep 2012 07:24:04 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97b9eXED1WSg for ; Fri, 7 Sep 2012 07:24:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7809E21F8539 for ; Fri, 7 Sep 2012 07:24:03 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 1C72A14103F; Fri, 7 Sep 2012 16:24:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347027842; bh=sar7GPWyxFZwZZXnCxqLu7EQF/waMYr0MlukmlLxRWA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XxT0//KhSQB8G99WEiKmfO9sdoFnjVzlIyqJJ9yDWxb+LcTgcU3/+zdBytQ7od0fS 8A7ubsGxuCABXlzrxuXoqpEwNl7zrnSsgvwhB4DI8Yoy0PeX21KiaDfUkzzlJ+1GJx iF0MPr/3+/EA5vCMAoiHdk0ZSiDMCI4XXvb5Xw8Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120907.153852.1650771442949102026.mbj@tail-f.com> Date: Fri, 7 Sep 2012 16:24:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 14:24:04 -0000 On Sep 7, 2012, at 3:38 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >>=20 >> I have some concerns regarding transferrability of interface >> configurations. For example, one may want to replace a router with a >> similar one from a different vendor, or simply replace an Ethernet >> card with another brand. In both cases, the names of physical >> interface(s) might change. >>=20 >> It would be nice to be able to take the old configuration and use it >> with the new hardware, perhaps after making a few trivial >> changes. With the current interfaces module it is not that easy >> because: >>=20 >> 1. interface name is the list key, so it cannot be updated in place, >>=20 >> 2. all references via "interface-ref" will have to be updated. >>=20 >> So my suggestion is to introduce an indirection by means of adding >> another leaf, e.g. "physical-name". "name" will remain the list key >> but it will be an arbitrary client-selected identifier. >=20 > If the key "name" is truly arbitrary and all implementations MUST > handle this, then a "physical-name" is not really needed. Note that > we already have "type" and "location", so with an arbitrary name you > could create a new interface like this: >=20 > my-new-interface > ethernet > 0/1 This is fine for routers where interface names are formed directly from = "type" and "location". But for a device based on Linux it would be = useful to see (and be able to configure) that it is "eth0" rather than = an Ethernet interface at a certain PCI address. Also, "physical-name" (or "local-name") could be mapped to "ifName" and = "name" to "ifAlias". The mapping proposed in the module (name->ifName, = description->ifAlias) looks like an ugly hack.=20 >=20 > If a vendor needs an indirection or not would be an implementation > detail. A vendor could of course also add a "internal-name" config > false leaf through an augmentation, if it helps the operator. >=20 > The original reason for the text on "name"=20 >=20 > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. Yes, this and the following paragraphs in the description of "name" = suggest pretty strongly that it is supposed to be the real interface = name. IMO such a practice should be discouraged. >=20 > was to make it easier to implement. Well, implementing such an indirection is quite trivial. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Sep 7 07:39:47 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 B070C21E8099 for ; Fri, 7 Sep 2012 07:39:47 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AOULKpsx2BM for ; Fri, 7 Sep 2012 07:39:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A58A621E8051 for ; Fri, 7 Sep 2012 07:39:45 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id D5E54140421; Fri, 7 Sep 2012 16:39:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347028784; bh=hew+x1uff6ibnRFGm7Uu00ya/0OclzR8cgRN6+RbYJ4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s1erX94CcUi6ZP904C3GAlaUuN9duMGEHFgbjwWSiBzo5A1cszHs8+6cW5uHWYVrJ 9c+Rak6tJQslhRGnYNo2wFPoz7x7WsJas0mm34x3RizP3nJt9VnXl6u7Xs2sxrbqhp 0dFYzGfZ9Gsus3i9n0k1okIlm1MuG6oOYDTOicj0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <201209071341.q87DfF8w083911@idle.juniper.net> Date: Fri, 7 Sep 2012 16:39:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209071341.q87DfF8w083911@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 07 Sep 2012 14:39:47 -0000 On Sep 7, 2012, at 3:41 PM, Phil Shafer wrote: > Ladislav Lhotka writes: >> Yes, but an important point is also what the list key is. My = suggestion is to have a non >> -volatile client-selected name (which is indeed what ifAlias is) as = the key for the inte >> rface list.=20 >=20 > Forcing use of ifAlias would be fairly shocking to your user > population and the benefits would only be when swapping devices Do you mean my user population or your user population? :-) > from distinct vendors, which turns out to be a fairly rare event. Imagine a network port fails and you just want to reconnect the cable to = the next free port. On Linux it happens quite easily that a newly added card gets "eth0" and = the old "eth0" becomes "eth1". Also, I believe, on BSD system the = interface name encodes the device driver name. Lada > And even when that event occurs, the real underlaying device name > would need to be fixed, limiting that benefit. >=20 > And forcing this would result in >99.999% of operators using an > alias identical to the underlaying interface name ;^) >=20 > What might be more apropros would be something like what we've just > added to junos: a wildcarded regex-based name replacement operation, > so I can say "turn all references to '10.1.2.3' to '10.4.5.6'". > It's more useful, generic, and allows one to make global = change/replace > operations like interface name substitutions without requiring > non-specific user-defined interface names. >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Fri Sep 7 14:56:34 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 CB0E421E80E8; Fri, 7 Sep 2012 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMiPzjURPfIZ; Fri, 7 Sep 2012 14:56:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3021E80DE; Fri, 7 Sep 2012 14:56:34 -0700 (PDT) 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: 4.34 Message-ID: <20120907215634.17212.3009.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 14:56:34 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-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: Fri, 07 Sep 2012 21:56:35 -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 Working Gr= oup of the IETF. Title : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-03.txt Pages : 30 Date : 2012-09-07 Abstract: This document defines a YANG data model for the configuration and identification of the management system of a device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Sun Sep 9 08:47: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 1E7FF21F851B for ; Sun, 9 Sep 2012 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V3NZT8zCkRv for ; Sun, 9 Sep 2012 08:47:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDA21F8518 for ; Sun, 9 Sep 2012 08:46:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7A4F20CA6; Sun, 9 Sep 2012 17:46:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YaZFqHt8k69G; Sun, 9 Sep 2012 17:46:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12CF620C97; Sun, 9 Sep 2012 17:46:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5A1A21ADAA3; Sun, 9 Sep 2012 17:46:52 +0200 (CEST) Date: Sun, 9 Sep 2012 17:46:52 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120909154652.GA51118@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120907.153852.1650771442949102026.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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: Sun, 09 Sep 2012 15:47:02 -0000 On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: > > If the key "name" is truly arbitrary and all implementations MUST > handle this, then a "physical-name" is not really needed. Note that > we already have "type" and "location", so with an arbitrary name you > could create a new interface like this: > > my-new-interface > ethernet > 0/1 > > If a vendor needs an indirection or not would be an implementation > detail. A vendor could of course also add a "internal-name" config > false leaf through an augmentation, if it helps the operator. > > The original reason for the text on "name" > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. > > was to make it easier to implement. > So we have devices that can arbitrarily rename interfaces and we have devices that cannot. Since we likely won't succeed in making all devices support interface renaming, I think we should go for a data model where devices that can rename interfaces can take advantage of it but other devices are fine to implement our data model without adding such a feature to their OS. Do we agree with that? If so, what is missing or broken with the current I-D? On my linux box, you really invoke an operation to rename an interface. But we do not have operations that can be triggered when a configuration is loaded. So we would have to have a mapping. Can we make it a separate data model feature that only those who really care implement? Or even better, we leave it out and if in say 2-3 years there are multiple proprietary implementations of such a mechanism, someone can go an standardize an extension of the data model? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Sep 10 03:00: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 1703B21F8639 for ; Mon, 10 Sep 2012 03:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vGUBoUqrgR5 for ; Mon, 10 Sep 2012 03:00:18 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2091521F8624 for ; Mon, 10 Sep 2012 03:00:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 39FAC5405AF for ; Mon, 10 Sep 2012 12:00:16 +0200 (CEST) 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 JDk4aOS6drfu for ; Mon, 10 Sep 2012 12:00:08 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1A633540558 for ; Mon, 10 Sep 2012 12:00:07 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120909154652.GA51118@elstar.local> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 10 Sep 2012 12:00:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 10:00:19 -0000 Juergen Schoenwaelder writes: > On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: >> >> If the key "name" is truly arbitrary and all implementations MUST >> handle this, then a "physical-name" is not really needed. Note that >> we already have "type" and "location", so with an arbitrary name you >> could create a new interface like this: >> >> my-new-interface >> ethernet >> 0/1 >> >> If a vendor needs an indirection or not would be an implementation >> detail. A vendor could of course also add a "internal-name" config >> false leaf through an augmentation, if it helps the operator. >> >> The original reason for the text on "name" >> >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >> >> was to make it easier to implement. >> > > So we have devices that can arbitrarily rename interfaces and we have > devices that cannot. Since we likely won't succeed in making all > devices support interface renaming, I think we should go for a data > model where devices that can rename interfaces can take advantage of > it but other devices are fine to implement our data model without > adding such a feature to their OS. Do we agree with that? I think that renaming an interface is more a user interface issue and could be implemented as an optional "alias" leaf. My comment was more about making the key of the "interface" list, which is also the link anchor for the "interface-ref" type, non-volatile. It could even be an opaque value. As soon as the key is used in a configuration, it is difficult to change it. > > If so, what is missing or broken with the current I-D? On my linux > box, you really invoke an operation to rename an interface. But we do > not have operations that can be triggered when a configuration is > loaded. So we would have to have a mapping. Can we make it a separate > data model feature that only those who really care implement? Or even > better, we leave it out and if in say 2-3 years there are multiple > proprietary implementations of such a mechanism, someone can go an > standardize an extension of the data model? For all implementations, the interface key should either be the local name, which may change or disappear if the hardware changes, or something else. This should probably be decided now. Lada > > /js > > -- > 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 j.schoenwaelder@jacobs-university.de Mon Sep 10 03:22: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 B97AD21F854F for ; Mon, 10 Sep 2012 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWEv8MmGPU1n for ; Mon, 10 Sep 2012 03:22:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE221F8585 for ; Mon, 10 Sep 2012 03:22:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 621CB20CBC; Mon, 10 Sep 2012 12:22:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hp0y5ZRnhMaB; Mon, 10 Sep 2012 12:22:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03B1020CBA; Mon, 10 Sep 2012 12:22:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C880F21AE9B0; Mon, 10 Sep 2012 12:22:32 +0200 (CEST) Date: Mon, 10 Sep 2012 12:22:32 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120910102232.GB52355@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@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) Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 10:22:40 -0000 On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: > >> > >> If the key "name" is truly arbitrary and all implementations MUST > >> handle this, then a "physical-name" is not really needed. Note that > >> we already have "type" and "location", so with an arbitrary name you > >> could create a new interface like this: > >> > >> my-new-interface > >> ethernet > >> 0/1 > >> > >> If a vendor needs an indirection or not would be an implementation > >> detail. A vendor could of course also add a "internal-name" config > >> false leaf through an augmentation, if it helps the operator. > >> > >> The original reason for the text on "name" > >> > >> A device MAY restrict the allowed values for this leaf, > >> possibly depending on the type and location. > >> > >> was to make it easier to implement. > >> > > > > So we have devices that can arbitrarily rename interfaces and we have > > devices that cannot. Since we likely won't succeed in making all > > devices support interface renaming, I think we should go for a data > > model where devices that can rename interfaces can take advantage of > > it but other devices are fine to implement our data model without > > adding such a feature to their OS. Do we agree with that? > > I think that renaming an interface is more a user interface issue > and could be implemented as an optional "alias" leaf. My comment was > more about making the key of the "interface" list, which is also the > link anchor for the "interface-ref" type, non-volatile. It could > even be an opaque value. As soon as the key is used in a > configuration, it is difficult to change it. The leaf is config true and hence the volatility of this is determined by the datastore. I am still not sure what your concern really is. Here is the definition: leaf name { type string; 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. If a NETCONF server that implements this restriction is sent a value that doesn't match the restriction, it MUST reply with an rpc-error with the error-tag 'invalid-value'."; reference "RFC 2863: The Interfaces Group MIB - ifName"; } Do you think this text prevents implementation on devices that have the ability to rename interfaces? I think this definition allows to have an interface configuration "foo" and when I rename 'eth5' to "foo" it will apply just fine, no? > > If so, what is missing or broken with the current I-D? On my linux > > box, you really invoke an operation to rename an interface. But we do > > not have operations that can be triggered when a configuration is > > loaded. So we would have to have a mapping. Can we make it a separate > > data model feature that only those who really care implement? Or even > > better, we leave it out and if in say 2-3 years there are multiple > > proprietary implementations of such a mechanism, someone can go an > > standardize an extension of the data model? > > For all implementations, the interface key should either be the local name, which may change or disappear if the hardware changes, or something else. This should probably be decided now. > So your issue really is that the current definition does not force one or the other? I personally doubt we can do this if we want to achieve wide implementation and deployment of this standard. What systems can or can not do wrt. interface names is not likely to change just because a new network management data model comes along. /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 Mon Sep 10 05:36:14 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 64EC821F86B1 for ; Mon, 10 Sep 2012 05:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFGgvYysikWt for ; Mon, 10 Sep 2012 05:36:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5CE21F86AF for ; Mon, 10 Sep 2012 05:36:13 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B8A35140513; Mon, 10 Sep 2012 14:36:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347280571; bh=Y6gzRPAxS659rbsBI0Hgley0q1/O/yMLjfGR+PUpqf0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iwxGR+50S1F6B/KT5GxRg2uCS892WJoomXTJCCbPSyAuPI5ESS633nCXs17VfwVKe vcK1dzyl1MDYCRD1b5EHTBzD1bM9hbMsi3CGNaohKPcyrGuHsTqaa9mcHJ5pLjTZMD Diza1lGHzbQkTapVEL6Mw1ftpuLQHH2C/63OieDo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120910102232.GB52355@elstar.local> Date: Mon, 10 Sep 2012 14:36:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 12:36:14 -0000 On Sep 10, 2012, at 12:22 PM, Juergen Schoenwaelder = wrote: > On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: >>>>=20 >>>> If the key "name" is truly arbitrary and all implementations MUST >>>> handle this, then a "physical-name" is not really needed. Note = that >>>> we already have "type" and "location", so with an arbitrary name = you >>>> could create a new interface like this: >>>>=20 >>>> my-new-interface >>>> ethernet >>>> 0/1 >>>>=20 >>>> If a vendor needs an indirection or not would be an implementation >>>> detail. A vendor could of course also add a "internal-name" config >>>> false leaf through an augmentation, if it helps the operator. >>>>=20 >>>> The original reason for the text on "name"=20 >>>>=20 >>>> A device MAY restrict the allowed values for this leaf, >>>> possibly depending on the type and location. >>>>=20 >>>> was to make it easier to implement. >>>>=20 >>>=20 >>> So we have devices that can arbitrarily rename interfaces and we = have >>> devices that cannot. Since we likely won't succeed in making all >>> devices support interface renaming, I think we should go for a data >>> model where devices that can rename interfaces can take advantage of >>> it but other devices are fine to implement our data model without >>> adding such a feature to their OS. Do we agree with that? >>=20 >> I think that renaming an interface is more a user interface issue >> and could be implemented as an optional "alias" leaf. My comment was >> more about making the key of the "interface" list, which is also the >> link anchor for the "interface-ref" type, non-volatile. It could >> even be an opaque value. As soon as the key is used in a >> configuration, it is difficult to change it. >=20 > The leaf is config true and hence the volatility of this is determined > by the datastore. I am still not sure what your concern really > is. Here is the definition: Assume a physical interface with name "X". You configure it with IP = addresses, and then create some tunnels, VLANs, bonds, packet filters = etc. - configuration of all these refer to "X". Now you want to transfer = that configuration to another physical interface "Y". Currently the only = option (and also the only option with most CLIs) is to copy-and-paste = the configuration from entry "X" to entry "Y" and also change all = references from "X" to "Y". If the interface key was an indirect = identifier "Z", you could just say that it now represents physical = interface "Y" instead of "X" and no other changes will be necessary. >=20 > leaf name { > type string; > description > "An arbitrary name for the interface. >=20 > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. >=20 > 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'. >=20 > 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. > If a NETCONF server that implements this restriction is > sent a value that doesn't match the restriction, it MUST > reply with an rpc-error with the error-tag > 'invalid-value'."; > reference > "RFC 2863: The Interfaces Group MIB - ifName"; > } >=20 > Do you think this text prevents implementation on devices that have > the ability to rename interfaces? I think this definition allows to > have an interface configuration "foo" and when I rename 'eth5' to > "foo" it will apply just fine, no? The problem I am talking about is that you have an interface = configuration for "eth0" and you want to make it into configuration of = "eth1". You cannot rename the key of a list entry using , = and even if you could, some "interface-ref" leafs could be left in the = configuration pointing to the old name. Of course, it would work if the = device allows for renaming "eth1" to "eth0", but I don't think this is = generally possible - in JUNOS and IOS the interface names are formed = from the type and location. It would be possible to have an RPC method "rename-interface", which = could also find all occurrences of the old name in a configuration and = change them to the new one, as Phil suggested. However, I think it is = cleaner to have the indirection explicitly in the data model because the = semantics of RPC methods cannot be precisely defined. >=20 >>> If so, what is missing or broken with the current I-D? On my linux >>> box, you really invoke an operation to rename an interface. But we = do >>> not have operations that can be triggered when a configuration is >>> loaded. So we would have to have a mapping. Can we make it a = separate >>> data model feature that only those who really care implement? Or = even >>> better, we leave it out and if in say 2-3 years there are multiple >>> proprietary implementations of such a mechanism, someone can go an >>> standardize an extension of the data model? >>=20 >> For all implementations, the interface key should either be the local = name, which may change or disappear if the hardware changes, or = something else. This should probably be decided now. >>=20 >=20 > So your issue really is that the current definition does not force one > or the other? I personally doubt we can do this if we want to achieve > wide implementation and deployment of this standard. What systems can > or can not do wrt. interface names is not likely to change just > because a new network management data model comes along. The NETCONF server could resolve indirect references to local interface = names, so the indirection doesn't require the device to have the native = ability to rename interfaces. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Sep 10 05:48: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 6214321F8646 for ; Mon, 10 Sep 2012 05:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AATYYOUDM+7z for ; Mon, 10 Sep 2012 05:48:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6521F863F for ; Mon, 10 Sep 2012 05:48:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E59B20C30; Mon, 10 Sep 2012 14:48:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ADjkJP3BZ-rp; Mon, 10 Sep 2012 14:48:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0597320CBF; Mon, 10 Sep 2012 14:48:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 001D421AF15B; Mon, 10 Sep 2012 14:48:17 +0200 (CEST) Date: Mon, 10 Sep 2012 14:48:17 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120910124817.GA52800@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@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] interface and ip 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, 10 Sep 2012 12:48:24 -0000 On Mon, Sep 10, 2012 at 02:36:11PM +0200, Ladislav Lhotka wrote: > > On Sep 10, 2012, at 12:22 PM, Juergen Schoenwaelder wrote: > > > On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder writes: > >> > >>> On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: > >>>> > >>>> If the key "name" is truly arbitrary and all implementations MUST > >>>> handle this, then a "physical-name" is not really needed. Note that > >>>> we already have "type" and "location", so with an arbitrary name you > >>>> could create a new interface like this: > >>>> > >>>> my-new-interface > >>>> ethernet > >>>> 0/1 > >>>> > >>>> If a vendor needs an indirection or not would be an implementation > >>>> detail. A vendor could of course also add a "internal-name" config > >>>> false leaf through an augmentation, if it helps the operator. > >>>> > >>>> The original reason for the text on "name" > >>>> > >>>> A device MAY restrict the allowed values for this leaf, > >>>> possibly depending on the type and location. > >>>> > >>>> was to make it easier to implement. > >>>> > >>> > >>> So we have devices that can arbitrarily rename interfaces and we have > >>> devices that cannot. Since we likely won't succeed in making all > >>> devices support interface renaming, I think we should go for a data > >>> model where devices that can rename interfaces can take advantage of > >>> it but other devices are fine to implement our data model without > >>> adding such a feature to their OS. Do we agree with that? > >> > >> I think that renaming an interface is more a user interface issue > >> and could be implemented as an optional "alias" leaf. My comment was > >> more about making the key of the "interface" list, which is also the > >> link anchor for the "interface-ref" type, non-volatile. It could > >> even be an opaque value. As soon as the key is used in a > >> configuration, it is difficult to change it. > > > > The leaf is config true and hence the volatility of this is determined > > by the datastore. I am still not sure what your concern really > > is. Here is the definition: > > Assume a physical interface with name "X". You configure it with IP addresses, and then create some tunnels, VLANs, bonds, packet filters etc. - configuration of all these refer to "X". Now you want to transfer that configuration to another physical interface "Y". Currently the only option (and also the only option with most CLIs) is to copy-and-paste the configuration from entry "X" to entry "Y" and also change all references from "X" to "Y". If the interface key was an indirect identifier "Z", you could just say that it now represents physical interface "Y" instead of "X" and no other changes will be necessary. Whenever you choose a value for a key that is referenced in other parts of the data model, you will have this same problem, no? Have we operational experience tell us that is an important enough problem to be solved? If so, would a generic mechanism to rename keys and everything pointing to it not be the way to go? > > leaf name { > > type string; > > 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. > > If a NETCONF server that implements this restriction is > > sent a value that doesn't match the restriction, it MUST > > reply with an rpc-error with the error-tag > > 'invalid-value'."; > > reference > > "RFC 2863: The Interfaces Group MIB - ifName"; > > } > > > > Do you think this text prevents implementation on devices that have > > the ability to rename interfaces? I think this definition allows to > > have an interface configuration "foo" and when I rename 'eth5' to > > "foo" it will apply just fine, no? > > The problem I am talking about is that you have an interface configuration for "eth0" and you want to make it into configuration of "eth1". You cannot rename the key of a list entry using , and even if you could, some "interface-ref" leafs could be left in the configuration pointing to the old name. Of course, it would work if the device allows for renaming "eth1" to "eth0", but I don't think this is generally possible - in JUNOS and IOS the interface names are formed from the type and location. > > It would be possible to have an RPC method "rename-interface", which could also find all occurrences of the old name in a configuration and change them to the new one, as Phil suggested. However, I think it is cleaner to have the indirection explicitly in the data model because the semantics of RPC methods cannot be precisely defined. > I am not sure what the issue with RPC semantics is. That said, I am still not clear what exactly the change is that you propose. > >>> If so, what is missing or broken with the current I-D? On my linux > >>> box, you really invoke an operation to rename an interface. But we do > >>> not have operations that can be triggered when a configuration is > >>> loaded. So we would have to have a mapping. Can we make it a separate > >>> data model feature that only those who really care implement? Or even > >>> better, we leave it out and if in say 2-3 years there are multiple > >>> proprietary implementations of such a mechanism, someone can go an > >>> standardize an extension of the data model? > >> > >> For all implementations, the interface key should either be the local name, which may change or disappear if the hardware changes, or something else. This should probably be decided now. > >> > > > > So your issue really is that the current definition does not force one > > or the other? I personally doubt we can do this if we want to achieve > > wide implementation and deployment of this standard. What systems can > > or can not do wrt. interface names is not likely to change just > > because a new network management data model comes along. > > The NETCONF server could resolve indirect references to local interface names, so the indirection doesn't require the device to have the native ability to rename interfaces. > NETCONF will co-exist with other management interfaces for a long time to come and even though the NETCONF might to magic translations, if at the end your eth1 configuration does not relate to you eth1 data you see on your CLI or the SNMP interface, we might have created a problem rather than solved one. But then, I have not understood the details of your proposal yet, so I do not know for sure. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Mon Sep 10 06:12:39 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 19C0121F8592 for ; Mon, 10 Sep 2012 06:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILUcWq4-ba10 for ; Mon, 10 Sep 2012 06:12:38 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9521F8585 for ; Mon, 10 Sep 2012 06:12:38 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKUE3nRcqOUZI1gG+X/ukHvWTSATBsmavU@postini.com; Mon, 10 Sep 2012 06:12:38 PDT Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by alpmlip11.e2k.ad.ge.com with ESMTP; 10 Sep 2012 09:12:35 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Sep 2012 09:12:34 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Sep 2012 09:12:34 -0400 Received: from CINMBAPD02.e2k.ad.ge.com (3.159.212.68) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 10 Sep 2012 09:12:33 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.232]) by CINMBAPD02.e2k.ad.ge.com ([169.254.8.44]) with mapi id 14.02.0309.002; Mon, 10 Sep 2012 09:12:34 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-06.txt Thread-Index: AQHNizhmO6PSbKyqEUGMpdmhquBmp5eDlJbQ Date: Mon, 10 Sep 2012 13:12:32 +0000 Message-ID: References: <20120905073030.22648.86754.idtracker@ietfa.amsl.com> In-Reply-To: <20120905073030.22648.86754.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2012 13:12:34.0481 (UTC) FILETIME=[F12C3210:01CD8F55] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-06.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, 10 Sep 2012 13:12:39 -0000 Looking over the latest interfaces YANG file, shouldn't the speed leaf be c= onfig false? leaf speed {=09 type yang:gauge64;=09 units "bits / second";=09 description=09 "An estimate of the interface's current bandwidth in bits= =09 per second. For interfaces which do not vary in=09 bandwidth or for those where no accurate estimation can=09 be made, this node should contain the nominal bandwidth.= =09 For interfaces that has no concept of bandwidth, this=09 node is not present.";=09 reference=09 "RFC 2863: The Interfaces Group MIB -=09 ifSpeed, ifHighSpeed";=09 } I don't think I want a user telling me what they estimate my bandwidth is i= n bits / second. -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 05, 2012 3:31 AM > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the NETCONF Data Modeling Language Working > Group of the IETF. >=20 > Title : A YANG Data Model for Interface Management > Author(s) : Martin Bjorklund > Filename : draft-ietf-netmod-interfaces-cfg-06.txt > Pages : 33 > Date : 2012-09-05 >=20 > Abstract: > This document defines a YANG data model for the management of network > interfaces. It is expected that interface type specific data models > augment the generic interfaces data model defined in this document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Mon Sep 10 06:20:25 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 B6B9621F8600 for ; Mon, 10 Sep 2012 06:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1dJbQN0FcHk for ; Mon, 10 Sep 2012 06:20:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 266CD21F85C0 for ; Mon, 10 Sep 2012 06:20:20 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 276991200D40; Mon, 10 Sep 2012 15:20:19 +0200 (CEST) Date: Mon, 10 Sep 2012 15:20:18 +0200 (CEST) Message-Id: <20120910.152018.1038136514591860914.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20120905073030.22648.86754.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.4 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] I-D Action: draft-ietf-netmod-interfaces-cfg-06.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, 10 Sep 2012 13:20:25 -0000 "Lange, Jeffrey K (GE Energy)" wrote: > Looking over the latest interfaces YANG file, shouldn't the speed > leaf be config false? Yes it should! Thanks, I will fix this. /martin From andy@yumaworks.com Mon Sep 10 08:09: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 0ED2E21F8700 for ; Mon, 10 Sep 2012 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFxPqrsSZhbh for ; Mon, 10 Sep 2012 08:09:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 683A421F8569 for ; Mon, 10 Sep 2012 08:09:47 -0700 (PDT) Received: by qcac10 with SMTP id c10so1355508qca.31 for ; Mon, 10 Sep 2012 08:09:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=4vCLAbK6r92lqrWyXh8K6KE4CPFbALAjY+23+8mNQAg=; b=MSFcAEbt9uragbN9uIoB0KqDpPaQdR5PBpczlUT53gDgeY+IySpRyr1MfPBn1RBvKz W29/4JDr6czGevyzDZhgOLYABi620aVNi/c2pMNDXQeJv4CEoNhU3WY6DF/LFZ6qAXL4 /5LO4tLVh3E2+dupYoDC6pYzeb66ljurBBtH2RTi8oqbwGD40vMDt6U4OsTnKbUAsXkQ ua2+/F7q1DOzXfUYQMzbrTPKA6HhjsQGPoBb3Z3ONIxJa82L8Gf5Q5MmRWc6Wd8uYhGP iu//KKyuj7zkT4/Pyi9SGOjJ3z1TLb+/JVFPhzqKafgTLI4bEnfgEcfxtzmRE6G/qAuT 0QuQ== MIME-Version: 1.0 Received: by 10.229.111.156 with SMTP id s28mr1235886qcp.93.1347289786582; Mon, 10 Sep 2012 08:09:46 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 08:09:46 -0700 (PDT) In-Reply-To: <20120910102232.GB52355@elstar.local> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> Date: Mon, 10 Sep 2012 08:09:46 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQke441OZyDH92ehmEC05Pm9Pzpmm8OoJXXZ9O/IvM8eW6dRi5uIhIiCTnXNIF87XYMA96AX Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 15:09:49 -0000 I strongly object to the notion of replacing keys in YANG lists. When you change keys, you delete the old entry and create a new one. Period. That is the only interpretation. I strongly object to undocumented vendor-specific value sets, as identified in this text: A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. This is exactly the type of NMS data-silo design we are trying to avoid in standards. It is less objectionable to do this sort of vendor-specific variant for config=false. But for config=true, it means an application developer will have to figure out from trial and error or perhaps some ad-hoc vendor documentation what values are allowed on each server. This does not promote multi-vendor interoperability. The YANG data type definition is normative. The server must implement the specified syntax (modulo too-big errors, etc.). There cannot be some secret patterns that the server accepts that are not documented in the YANG type-stmt. Andy On Mon, Sep 10, 2012 at 3:22 AM, Juergen Schoenwaelder wrote: > On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >> >> > On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: >> >> >> >> If the key "name" is truly arbitrary and all implementations MUST >> >> handle this, then a "physical-name" is not really needed. Note that >> >> we already have "type" and "location", so with an arbitrary name you >> >> could create a new interface like this: >> >> >> >> my-new-interface >> >> ethernet >> >> 0/1 >> >> >> >> If a vendor needs an indirection or not would be an implementation >> >> detail. A vendor could of course also add a "internal-name" config >> >> false leaf through an augmentation, if it helps the operator. >> >> >> >> The original reason for the text on "name" >> >> >> >> A device MAY restrict the allowed values for this leaf, >> >> possibly depending on the type and location. >> >> >> >> was to make it easier to implement. >> >> >> > >> > So we have devices that can arbitrarily rename interfaces and we have >> > devices that cannot. Since we likely won't succeed in making all >> > devices support interface renaming, I think we should go for a data >> > model where devices that can rename interfaces can take advantage of >> > it but other devices are fine to implement our data model without >> > adding such a feature to their OS. Do we agree with that? >> >> I think that renaming an interface is more a user interface issue >> and could be implemented as an optional "alias" leaf. My comment was >> more about making the key of the "interface" list, which is also the >> link anchor for the "interface-ref" type, non-volatile. It could >> even be an opaque value. As soon as the key is used in a >> configuration, it is difficult to change it. > > The leaf is config true and hence the volatility of this is determined > by the datastore. I am still not sure what your concern really > is. Here is the definition: > > leaf name { > type string; > 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. > If a NETCONF server that implements this restriction is > sent a value that doesn't match the restriction, it MUST > reply with an rpc-error with the error-tag > 'invalid-value'."; > reference > "RFC 2863: The Interfaces Group MIB - ifName"; > } > > Do you think this text prevents implementation on devices that have > the ability to rename interfaces? I think this definition allows to > have an interface configuration "foo" and when I rename 'eth5' to > "foo" it will apply just fine, no? > >> > If so, what is missing or broken with the current I-D? On my linux >> > box, you really invoke an operation to rename an interface. But we do >> > not have operations that can be triggered when a configuration is >> > loaded. So we would have to have a mapping. Can we make it a separate >> > data model feature that only those who really care implement? Or even >> > better, we leave it out and if in say 2-3 years there are multiple >> > proprietary implementations of such a mechanism, someone can go an >> > standardize an extension of the data model? >> >> For all implementations, the interface key should either be the local name, which may change or disappear if the hardware changes, or something else. This should probably be decided now. >> > > So your issue really is that the current definition does not force one > or the other? I personally doubt we can do this if we want to achieve > wide implementation and deployment of this standard. What systems can > or can not do wrt. interface names is not likely to change just > because a new network management data model comes along. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Mon Sep 10 08:20: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 8A4A121F869F for ; Mon, 10 Sep 2012 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXCMDB9DLn+V for ; Mon, 10 Sep 2012 08:20:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56E21F86AB for ; Mon, 10 Sep 2012 08:20:19 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A05B6140513; Mon, 10 Sep 2012 17:20:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347290418; bh=XSo2KP75m7Dhf0wT10dYsMK6EENHVkV6YxNF5L00KAI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vVnBMhhGV+mMqVPZyZlOUrBA+iFxgNdqyKIAUrSOGsp/3AoY+FA4+QxTmCMtyHS+T Ejf0YdB/8dFqjMK8KoqapMTn/o1qinb0hpXNjlxoMOssWkb5X4/ZB5ZKR48kDnHAJh XklWLSxE4iUGpR4PvBZK2I/KQzpz7t4nCMWFYfrA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120910124817.GA52800@elstar.local> Date: Mon, 10 Sep 2012 17:20:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94B333AE-5BEC-47DC-B40D-5D3124617C17@nic.cz> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> <20120910124817.GA52800@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 15:20:21 -0000 On Sep 10, 2012, at 2:48 PM, Juergen Schoenwaelder = wrote: > On Mon, Sep 10, 2012 at 02:36:11PM +0200, Ladislav Lhotka wrote: >>=20 >> On Sep 10, 2012, at 12:22 PM, Juergen Schoenwaelder = wrote: >>=20 >>> On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: >>>>>>=20 >>>>>> If the key "name" is truly arbitrary and all implementations MUST >>>>>> handle this, then a "physical-name" is not really needed. Note = that >>>>>> we already have "type" and "location", so with an arbitrary name = you >>>>>> could create a new interface like this: >>>>>>=20 >>>>>> my-new-interface >>>>>> ethernet >>>>>> 0/1 >>>>>>=20 >>>>>> If a vendor needs an indirection or not would be an = implementation >>>>>> detail. A vendor could of course also add a "internal-name" = config >>>>>> false leaf through an augmentation, if it helps the operator. >>>>>>=20 >>>>>> The original reason for the text on "name"=20 >>>>>>=20 >>>>>> A device MAY restrict the allowed values for this leaf, >>>>>> possibly depending on the type and location. >>>>>>=20 >>>>>> was to make it easier to implement. >>>>>>=20 >>>>>=20 >>>>> So we have devices that can arbitrarily rename interfaces and we = have >>>>> devices that cannot. Since we likely won't succeed in making all >>>>> devices support interface renaming, I think we should go for a = data >>>>> model where devices that can rename interfaces can take advantage = of >>>>> it but other devices are fine to implement our data model without >>>>> adding such a feature to their OS. Do we agree with that? >>>>=20 >>>> I think that renaming an interface is more a user interface issue >>>> and could be implemented as an optional "alias" leaf. My comment = was >>>> more about making the key of the "interface" list, which is also = the >>>> link anchor for the "interface-ref" type, non-volatile. It could >>>> even be an opaque value. As soon as the key is used in a >>>> configuration, it is difficult to change it. >>>=20 >>> The leaf is config true and hence the volatility of this is = determined >>> by the datastore. I am still not sure what your concern really >>> is. Here is the definition: >>=20 >> Assume a physical interface with name "X". You configure it with IP = addresses, and then create some tunnels, VLANs, bonds, packet filters = etc. - configuration of all these refer to "X". Now you want to transfer = that configuration to another physical interface "Y". Currently the only = option (and also the only option with most CLIs) is to copy-and-paste = the configuration from entry "X" to entry "Y" and also change all = references from "X" to "Y". If the interface key was an indirect = identifier "Z", you could just say that it now represents physical = interface "Y" instead of "X" and no other changes will be necessary. >=20 > Whenever you choose a value for a key that is referenced in other > parts of the data model, you will have this same problem, no? Have we No. If the local (native) name of an interface changes, or the client = wants to move the configuration between two interfaces, it is sufficient = to issue an edit-config, where the interface entry is selected by the = key ("Z" in my example) and the value of "local-name" is changed to "Y". =20 > operational experience tell us that is an important enough problem to > be solved? If so, would a generic mechanism to rename keys and > everything pointing to it not be the way to go? Yes, this would solve the problem, although it can be an expensive = operation. >=20 >>> leaf name { >>> type string; >>> description >>> "An arbitrary name for the interface. >>>=20 >>> A device MAY restrict the allowed values for this leaf, >>> possibly depending on the type and location. >>>=20 >>> 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'. >>>=20 >>> 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. >>> If a NETCONF server that implements this restriction is >>> sent a value that doesn't match the restriction, it MUST >>> reply with an rpc-error with the error-tag >>> 'invalid-value'."; >>> reference >>> "RFC 2863: The Interfaces Group MIB - ifName"; >>> } >>>=20 >>> Do you think this text prevents implementation on devices that have >>> the ability to rename interfaces? I think this definition allows to >>> have an interface configuration "foo" and when I rename 'eth5' to >>> "foo" it will apply just fine, no? >>=20 >> The problem I am talking about is that you have an interface = configuration for "eth0" and you want to make it into configuration of = "eth1". You cannot rename the key of a list entry using , = and even if you could, some "interface-ref" leafs could be left in the = configuration pointing to the old name. Of course, it would work if the = device allows for renaming "eth1" to "eth0", but I don't think this is = generally possible - in JUNOS and IOS the interface names are formed = from the type and location. >>=20 >> It would be possible to have an RPC method "rename-interface", which = could also find all occurrences of the old name in a configuration and = change them to the new one, as Phil suggested. However, I think it is = cleaner to have the indirection explicitly in the data model because the = semantics of RPC methods cannot be precisely defined. >>=20 >=20 > I am not sure what the issue with RPC semantics is. That said, I am > still not clear what exactly the change is that you propose. I propose to avoid using the local interface name as the key for = "interface". One way to do it is to use a new key, say "id", containing = an arbitrary string, so "name" would not be the key anymore, so it can = be changed via . The definition of the "interface-ref" would be typedef interface-ref { type leafref { path "/if:interfaces/if:interface/if:id"; } }=20 >=20 >>>>> If so, what is missing or broken with the current I-D? On my linux >>>>> box, you really invoke an operation to rename an interface. But we = do >>>>> not have operations that can be triggered when a configuration is >>>>> loaded. So we would have to have a mapping. Can we make it a = separate >>>>> data model feature that only those who really care implement? Or = even >>>>> better, we leave it out and if in say 2-3 years there are multiple >>>>> proprietary implementations of such a mechanism, someone can go an >>>>> standardize an extension of the data model? >>>>=20 >>>> For all implementations, the interface key should either be the = local name, which may change or disappear if the hardware changes, or = something else. This should probably be decided now. >>>>=20 >>>=20 >>> So your issue really is that the current definition does not force = one >>> or the other? I personally doubt we can do this if we want to = achieve >>> wide implementation and deployment of this standard. What systems = can >>> or can not do wrt. interface names is not likely to change just >>> because a new network management data model comes along. >>=20 >> The NETCONF server could resolve indirect references to local = interface names, so the indirection doesn't require the device to have = the native ability to rename interfaces. >>=20 >=20 > NETCONF will co-exist with other management interfaces for a long time > to come and even though the NETCONF might to magic translations, if at > the end your eth1 configuration does not relate to you eth1 data you > see on your CLI or the SNMP interface, we might have created a problem > rather than solved one. But then, I have not understood the details of > your proposal yet, so I do not know for sure. In get operations, the client can still select an interface using the = "name" leaf, e.g. in a subtree filter. The "id" would have to be used in = edit-config, but a client application could shield the user from this = additional complexity. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Sep 10 08:22:39 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 C9D1621F850C for ; Mon, 10 Sep 2012 08:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nHXCAeI2TXU for ; Mon, 10 Sep 2012 08:22:36 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 460B121F84EC for ; Mon, 10 Sep 2012 08:22:36 -0700 (PDT) Received: by qcac10 with SMTP id c10so1378278qca.31 for ; Mon, 10 Sep 2012 08:22:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=mf4I3f2FwyphbI0ejFO3JLkzdrJZAOwtyjqc2tqjwGY=; b=nw9Nv8ThH0Bfy5A4WDiu5u+sR5jewlUy3FjaIiAZGqB2FUDr+iyE/V5MaPmOWy6Sh3 bLyd5V287witQbsxYLHRftILmyxFMR3ITdv07uMd27mtuNn+6auQSqu0frb2ph4zRq2F Pu5GOhWifK2Q1F2vhjT/yjWeCxDrI6FVdq+k5lgE4WGQ69qORZ0d3yO3xsDVvdvD/f8+ D8mUeGPzxfgAyCWndfZxdKakbsf/sukgLwRWPBnqIbp+QW2QijFPfdtdk++/fOgGliiW fi21rfKlBCoEWOJKsR1GP+3wAuw6fVfbTFiGrRBErPRDvUDNIKKtEpaK1Vq8SZCk3k7a GknQ== MIME-Version: 1.0 Received: by 10.224.191.130 with SMTP id dm2mr7141973qab.98.1347290554513; Mon, 10 Sep 2012 08:22:34 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 08:22:34 -0700 (PDT) In-Reply-To: References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> Date: Mon, 10 Sep 2012 08:22:34 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkL1W1SlCxdwvAFvRU7LCX41uLqD/yb3svI9l/0jy6mLYZjEKbQyG6yw92vHOvStsjDUw9L Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 15:22:39 -0000 ... > The problem I am talking about is that you have an interface configuratio= n for "eth0" and you want to make it into configuration of "eth1". You cann= ot rename the key of a list entry using , and even if you coul= d, some "interface-ref" leafs could be left in the configuration pointing t= o the old name. Of course, it would work if the device allows for renaming = "eth1" to "eth0", but I don't think this is generally possible - in JUNOS a= nd IOS the interface names are formed from the type and location. > > It would be possible to have an RPC method "rename-interface", which coul= d also find all occurrences of the old name in a configuration and change t= hem to the new one, as Phil suggested. However, I think it is cleaner to ha= ve the indirection explicitly in the data model because the semantics of RP= C methods cannot be precisely defined. > So what happens to any leafref objects in other data models that are pointi= ng at leafs within the 'eth0' entry? Do they all get auto-magically changed t= oo, or do they all break? Same question for any NACM rules configured for that interface. Consider the impact on the entire data model when you change the list keys. > Ladislav Lhotka, CZ.NIC Labs Andy From j.schoenwaelder@jacobs-university.de Mon Sep 10 08:24:47 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 4A24C21E8034 for ; Mon, 10 Sep 2012 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ4RsaaNlsC9 for ; Mon, 10 Sep 2012 08:24:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5532211E808D for ; Mon, 10 Sep 2012 08:24:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B37ED20C8B; Mon, 10 Sep 2012 17:24:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g4MmPTDZla9v; Mon, 10 Sep 2012 17:24:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4656B20C53; Mon, 10 Sep 2012 17:24:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C2DD21B0644; Mon, 10 Sep 2012 17:24:41 +0200 (CEST) Date: Mon, 10 Sep 2012 17:24:41 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120910152441.GA53468@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@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] interface and ip 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, 10 Sep 2012 15:24:47 -0000 On Mon, Sep 10, 2012 at 08:09:46AM -0700, Andy Bierman wrote: > I strongly object to undocumented vendor-specific value sets, > as identified in this text: > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. > > This is exactly the type of NMS data-silo design we are trying to > avoid in standards. > It is less objectionable to do this sort of vendor-specific variant > for config=false. > But for config=true, it means an application developer will have to > figure out from trial and error > or perhaps some ad-hoc vendor documentation what values are allowed on > each server. > > This does not promote multi-vendor interoperability. > The YANG data type definition is normative. The server must implement > the specified syntax (modulo too-big errors, etc.). There cannot be some > secret patterns that the server accepts that are not documented > in the YANG type-stmt. I think it is a fact of life that several boxes do have restrictions on interface names. Even if we claim there are not any restrictions, they will be there. I doubt big vendors will change interface naming schemes that have grown over years just because there is this shiny new YANG data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Sep 10 08:28:31 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 EF34921F86F7 for ; Mon, 10 Sep 2012 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xxn5xnyoNUC5 for ; Mon, 10 Sep 2012 08:28:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E01E721F86F3 for ; Mon, 10 Sep 2012 08:28:30 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 04DBE140513; Mon, 10 Sep 2012 17:28:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347290910; bh=clJ4KL24jIXr4I6lpOqIpwNUueIDq+Dek+Dq3yjjTrY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jx56fEVQQpBvyWMi+L59Tjc4aksXfNYi3tqFMxrXgnUWhCOc2es1OGGqKLbugH1/6 VCR4uSnseFjCcsR77PVXoX6b/ubf5S4GDHFzHqgSPqxl+pe0vc4TB7K/AUodSkbdDo 2WFB5HzktkGYeydnyrzcWY82YNhzQdoUjsPHy+3k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Sep 2012 17:28:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 15:28:32 -0000 On Sep 10, 2012, at 5:09 PM, Andy Bierman wrote: > I strongly object to the notion of replacing keys in YANG lists. > When you change keys, you delete the old entry and create a new one. > Period. That is the only interpretation. >=20 > I strongly object to undocumented vendor-specific value sets, > as identified in this text: >=20 > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. >=20 > This is exactly the type of NMS data-silo design we are trying to > avoid in standards. > It is less objectionable to do this sort of vendor-specific variant > for config=3Dfalse. > But for config=3Dtrue, it means an application developer will have to > figure out from trial and error > or perhaps some ad-hoc vendor documentation what values are allowed on > each server. >=20 > This does not promote multi-vendor interoperability. > The YANG data type definition is normative. The server must implement > the specified syntax (modulo too-big errors, etc.). There cannot be = some > secret patterns that the server accepts that are not documented > in the YANG type-stmt. >=20 I agree, and for all this I propose to avoid using vendor-specific name = as the list key. It can be part of the data but as a non-key leaf. Lada=20 >=20 > Andy >=20 >=20 > On Mon, Sep 10, 2012 at 3:22 AM, Juergen Schoenwaelder > wrote: >> On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >>>=20 >>>> On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: >>>>>=20 >>>>> If the key "name" is truly arbitrary and all implementations MUST >>>>> handle this, then a "physical-name" is not really needed. Note = that >>>>> we already have "type" and "location", so with an arbitrary name = you >>>>> could create a new interface like this: >>>>>=20 >>>>> my-new-interface >>>>> ethernet >>>>> 0/1 >>>>>=20 >>>>> If a vendor needs an indirection or not would be an implementation >>>>> detail. A vendor could of course also add a "internal-name" = config >>>>> false leaf through an augmentation, if it helps the operator. >>>>>=20 >>>>> The original reason for the text on "name" >>>>>=20 >>>>> A device MAY restrict the allowed values for this leaf, >>>>> possibly depending on the type and location. >>>>>=20 >>>>> was to make it easier to implement. >>>>>=20 >>>>=20 >>>> So we have devices that can arbitrarily rename interfaces and we = have >>>> devices that cannot. Since we likely won't succeed in making all >>>> devices support interface renaming, I think we should go for a data >>>> model where devices that can rename interfaces can take advantage = of >>>> it but other devices are fine to implement our data model without >>>> adding such a feature to their OS. Do we agree with that? >>>=20 >>> I think that renaming an interface is more a user interface issue >>> and could be implemented as an optional "alias" leaf. My comment was >>> more about making the key of the "interface" list, which is also the >>> link anchor for the "interface-ref" type, non-volatile. It could >>> even be an opaque value. As soon as the key is used in a >>> configuration, it is difficult to change it. >>=20 >> The leaf is config true and hence the volatility of this is = determined >> by the datastore. I am still not sure what your concern really >> is. Here is the definition: >>=20 >> leaf name { >> type string; >> description >> "An arbitrary name for the interface. >>=20 >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >>=20 >> 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'. >>=20 >> 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. >> If a NETCONF server that implements this restriction is >> sent a value that doesn't match the restriction, it MUST >> reply with an rpc-error with the error-tag >> 'invalid-value'."; >> reference >> "RFC 2863: The Interfaces Group MIB - ifName"; >> } >>=20 >> Do you think this text prevents implementation on devices that have >> the ability to rename interfaces? I think this definition allows to >> have an interface configuration "foo" and when I rename 'eth5' to >> "foo" it will apply just fine, no? >>=20 >>>> If so, what is missing or broken with the current I-D? On my linux >>>> box, you really invoke an operation to rename an interface. But we = do >>>> not have operations that can be triggered when a configuration is >>>> loaded. So we would have to have a mapping. Can we make it a = separate >>>> data model feature that only those who really care implement? Or = even >>>> better, we leave it out and if in say 2-3 years there are multiple >>>> proprietary implementations of such a mechanism, someone can go an >>>> standardize an extension of the data model? >>>=20 >>> For all implementations, the interface key should either be the = local name, which may change or disappear if the hardware changes, or = something else. This should probably be decided now. >>>=20 >>=20 >> So your issue really is that the current definition does not force = one >> or the other? I personally doubt we can do this if we want to achieve >> wide implementation and deployment of this standard. What systems can >> or can not do wrt. interface names is not likely to change just >> because a new network management data model comes along. >>=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Sep 10 08:42: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 705B921F84DE for ; Mon, 10 Sep 2012 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imjZ7ki6qX0y for ; Mon, 10 Sep 2012 08:42:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7821F84C4 for ; Mon, 10 Sep 2012 08:42:28 -0700 (PDT) Received: by qcac10 with SMTP id c10so1411004qca.31 for ; Mon, 10 Sep 2012 08:42:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=1CbpOGPqsEUkIrUb7IjibGINLAaHt005PVrLtkekvg8=; b=Gzo/T4+0Exu5SLOUxt37VLBS0a8XMjECVPtRlLNnW6yz2HFVQiZ0O3CUwZZzomh4y1 tuu9r1B3/lZp3s1/YvmLFQLde+Bc1TI09T07aUNR2iDwsol9AQcQyRDb0ld6OCyAzVni bkpa/I/5f9DT/D5aqgduxjnw7wxogzJO3NYY4+UNIzG16PGTWFBZMxq7ABs6iJGx/0In JB3QUIAiI7Nh9QppUIAE+kiiZpPIrdDRsyvWtnMQJL3yS+954Kkad14N+PofKW+pMmC4 4OOML2iRNisnT/Me7Suh0Iiaq61Ielkf4k4fFj4hlxhZ1rQgZWgnIqpSoYWnHBuvnt5S 7t0Q== MIME-Version: 1.0 Received: by 10.229.135.76 with SMTP id m12mr4086759qct.68.1347291747759; Mon, 10 Sep 2012 08:42:27 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 08:42:27 -0700 (PDT) In-Reply-To: <20120910152441.GA53468@elstar.local> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> <20120910152441.GA53468@elstar.local> Date: Mon, 10 Sep 2012 08:42:27 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmb6dju4uRQZYs24jwkpzue4W95IS72ke+oJSC+wN1JDrQmxVwQObSK5SjpxQ5hlnJe8UoQ Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 15:42:33 -0000 On Mon, Sep 10, 2012 at 8:24 AM, Juergen Schoenwaelder wrote: > On Mon, Sep 10, 2012 at 08:09:46AM -0700, Andy Bierman wrote: > >> I strongly object to undocumented vendor-specific value sets, >> as identified in this text: >> >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >> >> This is exactly the type of NMS data-silo design we are trying to >> avoid in standards. >> It is less objectionable to do this sort of vendor-specific variant >> for config=false. >> But for config=true, it means an application developer will have to >> figure out from trial and error >> or perhaps some ad-hoc vendor documentation what values are allowed on >> each server. >> >> This does not promote multi-vendor interoperability. >> The YANG data type definition is normative. The server must implement >> the specified syntax (modulo too-big errors, etc.). There cannot be some >> secret patterns that the server accepts that are not documented >> in the YANG type-stmt. > > I think it is a fact of life that several boxes do have restrictions > on interface names. Even if we claim there are not any restrictions, > they will be there. I doubt big vendors will change interface naming > schemes that have grown over years just because there is this shiny > new YANG data model. It means that some things are not appropriate for standards, or that we have not written the standard correctly. Servers cannot be allowed to return an 'invalid-value' (or any non-resource related error-tag) for values that are valid according to the YANG data-def-stmt. What if there was an rpc like so the client could pass in the type and location parameters, and the server will return a name it will accept for the interface. My objection is to making the client data-silo all the details to produce a valid name, not to vendors using hard-wired naming schemes. I agree that is not going to change. > > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From andy@yumaworks.com Mon Sep 10 09:05: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 DE52B21F870A for ; Mon, 10 Sep 2012 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5olHrkt9bNgV for ; Mon, 10 Sep 2012 09:05:32 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2092A21F8697 for ; Mon, 10 Sep 2012 09:05:32 -0700 (PDT) Received: by qcac10 with SMTP id c10so1449237qca.31 for ; Mon, 10 Sep 2012 09:05:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=F6vgxNZs3/rGUmE0J332vnbneilGEgYxKOAepqcs6CU=; b=WFe5nhG1zlKGJG55oIAiqN0l2A8WSQXj4owp8GrijioCASWs+dKVTqGxR3uU+Fk+g1 28Dkg49vwt6p3/IdJOCzUpkaHW4Jm2rqh8waTVvD3+Is4SQ38ql06+vQU+VXGIL6mnH/ GKSp1Ue//KGURJBrx+/Ooh8/ywYF6yn/9MrfhlM3Omp7d//MEtNRDqCiKvx857HzdjaK bck2v3KT6F3QFmP1GXFwyeKXEqNhbDSamGkhq5khv0nPn6F80QnlAd1PLgrPh30Xg8mn xi1S6Oa7HHJZkKQh1uI5rMwL+uNegP/XmHu1Lzfx0NL2eMXV/vszxpcTShSiNwhswhCE mRZQ== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr16421754qaf.2.1347293131645; Mon, 10 Sep 2012 09:05:31 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 09:05:31 -0700 (PDT) In-Reply-To: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> Date: Mon, 10 Sep 2012 09:05:31 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlwoxIjdvqJjzKhdxD2exxqjtE18SUUCFaUGdZz/ZbzcmtUZQIYpryrZupqCZXQLo+as2LT Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 16:05:33 -0000 On Mon, Sep 10, 2012 at 8:28 AM, Ladislav Lhotka wrote: > > On Sep 10, 2012, at 5:09 PM, Andy Bierman wrote: > >> I strongly object to the notion of replacing keys in YANG lists. >> When you change keys, you delete the old entry and create a new one. >> Period. That is the only interpretation. >> >> I strongly object to undocumented vendor-specific value sets, >> as identified in this text: >> >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >> >> This is exactly the type of NMS data-silo design we are trying to >> avoid in standards. >> It is less objectionable to do this sort of vendor-specific variant >> for config=false. >> But for config=true, it means an application developer will have to >> figure out from trial and error >> or perhaps some ad-hoc vendor documentation what values are allowed on >> each server. >> >> This does not promote multi-vendor interoperability. >> The YANG data type definition is normative. The server must implement >> the specified syntax (modulo too-big errors, etc.). There cannot be some >> secret patterns that the server accepts that are not documented >> in the YANG type-stmt. >> > > I agree, and for all this I propose to avoid using vendor-specific name as the list key. It can be part of the data but as a non-key leaf. > That would solve it, but so many other data models reference interface names. Isn't the 'location' string also vendor-specific? It does not contain any text about how the server MAY restrict values. If the client provides an initial value, the server MUST use it, according to the YANG that is there. This whole thread really demonstrates that the REST-full way of solving this problem is so much better than NETCONF. Client POSTs new resource, server returns CREATED 201 and a Location header identifying the new resource. So much cleaner! YANG-API has the 'optional-key' YANG extension to solve this problem. Maybe a API is needed, since standard is going to be vendor-specific. That way, app developers can choose the interoperable but very limited or they can create the vendor-specific interface entry directly with . If vendors can pick their own secret patterns for strings, then they can also change them, right? So a name that works today in the "standard" is in no way guaranteed to work in the future? I think the current key for the interface list needs more work. > Lada > Andy From lhotka@nic.cz Mon Sep 10 09:50: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 1616121E804B for ; Mon, 10 Sep 2012 09:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKHNznb582Bn for ; Mon, 10 Sep 2012 09:50:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0BED621E8041 for ; Mon, 10 Sep 2012 09:50:14 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 29589140513; Mon, 10 Sep 2012 18:50:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347295813; bh=Xw4iiebaJs007+focaS9mJLemAglWztwtWSbgH5yyMM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sazcvoueEhmEaqNe8Y+fSxKQAqCacaCVOn0YJOVck7JEeLd6urjAneoYFohE+LPql Hv5JhPJUroi984s4+ZF7zeLHCwBtcn7uCu1uJGXT870cPpANa2P9DS2eO5JQVdIwoo FUIzg3nYEIv6oNC9DFw2tfaH7bxDdWGi7RH3ycy8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Sep 2012 18:50:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <808C1751-F4AD-4E24-BDCD-3D876AFAE423@nic.cz> References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 16:50:15 -0000 On Sep 10, 2012, at 5:22 PM, Andy Bierman wrote: > ... >> The problem I am talking about is that you have an interface = configuration for "eth0" and you want to make it into configuration of = "eth1". You cannot rename the key of a list entry using , = and even if you could, some "interface-ref" leafs could be left in the = configuration pointing to the old name. Of course, it would work if the = device allows for renaming "eth1" to "eth0", but I don't think this is = generally possible - in JUNOS and IOS the interface names are formed = from the type and location. >>=20 >> It would be possible to have an RPC method "rename-interface", which = could also find all occurrences of the old name in a configuration and = change them to the new one, as Phil suggested. However, I think it is = cleaner to have the indirection explicitly in the data model because the = semantics of RPC methods cannot be precisely defined. >>=20 >=20 > So what happens to any leafref objects in other data models that are = pointing > at leafs within the 'eth0' entry? Do they all get auto-magically = changed too, > or do they all break? Same question for any NACM rules configured for > that interface. Yes, it would have to search the entire data tree. This is expensive = because there are no backward refs leading to all leafrefs that point to = a given node. >=20 > Consider the impact on the entire data model when you change the list = keys. Yes, but it is not what I am proposing. Lada >=20 >=20 >> Ladislav Lhotka, CZ.NIC Labs >=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Mon Sep 10 10:09: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 2D34521E8045 for ; Mon, 10 Sep 2012 10:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSwV+GCGxqyI for ; Mon, 10 Sep 2012 10:09:52 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with ESMTP id D250F21E8037 for ; Mon, 10 Sep 2012 10:09:51 -0700 (PDT) Received: from cinmlip12.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKUE4e3qp2sCehAAJpHQK1L3PiO4aQfmsJ@postini.com; Mon, 10 Sep 2012 10:09:51 PDT Received: from unknown (HELO cinmlef09.e2k.ad.ge.com) ([3.159.213.56]) by cinmlip12.e2k.ad.ge.com with ESMTP; 10 Sep 2012 13:09:50 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Sep 2012 13:09:49 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Sep 2012 13:09:47 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 10 Sep 2012 13:09:37 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.232]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.158]) with mapi id 14.02.0309.002; Mon, 10 Sep 2012 13:09:37 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Ladislav Lhotka , Andy Bierman Thread-Topic: [netmod] interface and ip Thread-Index: AQHNizvX76fOgHmVpkeebIiQVygCDJd/HUeAgAALiwCAA0htAIABMXIAgAAGRQCAAFBBAIAABTqA///Xg7A= Date: Mon, 10 Sep 2012 17:09:36 +0000 Message-ID: References: <20120905.095534.845848821252289168.mbj@tail-f.com> <20120907.153852.1650771442949102026.mbj@tail-f.com> <20120909154652.GA51118@elstar.local> <20120910102232.GB52355@elstar.local> <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> In-Reply-To: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2012 17:09:47.0442 (UTC) FILETIME=[14ADB120:01CD8F77] Cc: "netmod@ietf.org" Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 17:09:53 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Ladislav Lhotka > Sent: Monday, September 10, 2012 11:28 AM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] interface and ip >=20 >=20 > On Sep 10, 2012, at 5:09 PM, Andy Bierman wrote: >=20 > > I strongly object to the notion of replacing keys in YANG lists. > > When you change keys, you delete the old entry and create a new one. > > Period. That is the only interpretation. > > > > I strongly object to undocumented vendor-specific value sets, as > > identified in this text: > > > > A device MAY restrict the allowed values for this leaf, > > possibly depending on the type and location. > > > > This is exactly the type of NMS data-silo design we are trying to > > avoid in standards. > > It is less objectionable to do this sort of vendor-specific variant > > for config=3Dfalse. > > But for config=3Dtrue, it means an application developer will have to > > figure out from trial and error or perhaps some ad-hoc vendor > > documentation what values are allowed on each server. > > What if there was a config=3Dfalse list of the physical interfaces on a mac= hine, then new entries in the /interfaces table could point to the physical= device that it is actually using? This would solve the problem of vendors= having name restriction on physical devices, and at the same time allow us= ers to create interface entries with whatever names they wanted? -Jeff > > This does not promote multi-vendor interoperability. > > The YANG data type definition is normative. The server must implement > > the specified syntax (modulo too-big errors, etc.). There cannot be > > some secret patterns that the server accepts that are not documented > > in the YANG type-stmt. > > >=20 > I agree, and for all this I propose to avoid using vendor-specific name a= s the > list key. It can be part of the data but as a non-key leaf. >=20 > Lada >=20 > > > > Andy > > > > > > On Mon, Sep 10, 2012 at 3:22 AM, Juergen Schoenwaelder > > wrote: > >> On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote: > >>> Juergen Schoenwaelder writes: > >>> > >>>> On Fri, Sep 07, 2012 at 03:38:52PM +0200, Martin Bjorklund wrote: > >>>>> > >>>>> If the key "name" is truly arbitrary and all implementations MUST > >>>>> handle this, then a "physical-name" is not really needed. Note > >>>>> that we already have "type" and "location", so with an arbitrary > >>>>> name you could create a new interface like this: > >>>>> > >>>>> my-new-interface > >>>>> ethernet > >>>>> 0/1 > >>>>> > >>>>> If a vendor needs an indirection or not would be an implementation > >>>>> detail. A vendor could of course also add a "internal-name" > >>>>> config false leaf through an augmentation, if it helps the operator= . > >>>>> > >>>>> The original reason for the text on "name" > >>>>> > >>>>> A device MAY restrict the allowed values for this leaf, > >>>>> possibly depending on the type and location. > >>>>> > >>>>> was to make it easier to implement. > >>>>> > >>>> > >>>> So we have devices that can arbitrarily rename interfaces and we > >>>> have devices that cannot. Since we likely won't succeed in making > >>>> all devices support interface renaming, I think we should go for a > >>>> data model where devices that can rename interfaces can take > >>>> advantage of it but other devices are fine to implement our data > >>>> model without adding such a feature to their OS. Do we agree with th= at? > >>> > >>> I think that renaming an interface is more a user interface issue > >>> and could be implemented as an optional "alias" leaf. My comment was > >>> more about making the key of the "interface" list, which is also the > >>> link anchor for the "interface-ref" type, non-volatile. It could > >>> even be an opaque value. As soon as the key is used in a > >>> configuration, it is difficult to change it. > >> > >> The leaf is config true and hence the volatility of this is > >> determined by the datastore. I am still not sure what your concern > >> really is. Here is the definition: > >> > >> leaf name { > >> type string; > >> 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 fo= r > >> this leaf so that it matches the restrictions of ifName. > >> If a NETCONF server that implements this restriction is > >> sent a value that doesn't match the restriction, it MUST > >> reply with an rpc-error with the error-tag > >> 'invalid-value'."; > >> reference > >> "RFC 2863: The Interfaces Group MIB - ifName"; > >> } > >> > >> Do you think this text prevents implementation on devices that have > >> the ability to rename interfaces? I think this definition allows to > >> have an interface configuration "foo" and when I rename 'eth5' to > >> "foo" it will apply just fine, no? > >> > >>>> If so, what is missing or broken with the current I-D? On my linux > >>>> box, you really invoke an operation to rename an interface. But we > >>>> do not have operations that can be triggered when a configuration > >>>> is loaded. So we would have to have a mapping. Can we make it a > >>>> separate data model feature that only those who really care > >>>> implement? Or even better, we leave it out and if in say 2-3 years > >>>> there are multiple proprietary implementations of such a mechanism, > >>>> someone can go an standardize an extension of the data model? > >>> > >>> For all implementations, the interface key should either be the local > name, which may change or disappear if the hardware changes, or something > else. This should probably be decided now. > >>> > >> > >> So your issue really is that the current definition does not force > >> one or the other? I personally doubt we can do this if we want to > >> achieve wide implementation and deployment of this standard. What > >> systems can or can not do wrt. interface names is not likely to > >> change just because a new network management data model comes along. > >> > >> /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 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Mon Sep 10 12:04: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 6155F21E8063 for ; Mon, 10 Sep 2012 12:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEJNetEfS2Qu for ; Mon, 10 Sep 2012 12:04:26 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2D1411E808E for ; Mon, 10 Sep 2012 12:04:26 -0700 (PDT) Received: by qcac10 with SMTP id c10so1663729qca.31 for ; Mon, 10 Sep 2012 12:04:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=OK35Zwu+DHN7JxwUp+eNe1xnPTu42HkYggTZYGAxZ2k=; b=O8q8ZokEVqkhz1i85L/zgzI1aXnV1HkPLePgerEfTe8uPeMeQxnEEDhXZSxvePuRF9 i1RIyuLGAVlNpM1c1/qlsPzjg7RUOxUGsR4j/nPh7rcTjMLZPJUgHIND2nxtkGjYa2I0 EuhSc0p791MmgAZ5Y6L+w/iI9HgecVVGfdC2kPupmrqxsopGuaRo1iWo/RAWqtNlykLF cOIq9djza+NEzK+Iu0x9p+Z5ziXL57BJllt+mh3AWRNwmZkcnq+jjYtoSSUfjJYDjK7D m2TxuSNp8pr9yv93JFZAndMqeW8wcPWVcGtwZM71sdnBXjMvbfk0+MIiBQawLNlgtBJR OSXQ== MIME-Version: 1.0 Received: by 10.224.52.139 with SMTP id i11mr4068983qag.11.1347303866230; Mon, 10 Sep 2012 12:04:26 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 12:04:26 -0700 (PDT) Date: Mon, 10 Sep 2012 12:04:26 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkAOxvNBCdtYHZvF2jS7yKJr7edv7VD42pKesUWqwv/xh0u/OyvyiTrErJ2lmOFxmhFtabF Subject: [netmod] Issue tracker 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, 10 Sep 2012 19:04:27 -0000 Hi, It is getting hard to follow all the detailed discussions on all the drafts in progress in the WG. I think it is time for issue tracker to help us get done faster. Did you know we already have an issue tracker? http://tools.ietf.org/wg/netmod/trac/report We should consider using it. Andy From mbj@tail-f.com Mon Sep 10 13:07: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 113C021F867E for ; Mon, 10 Sep 2012 13:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc765Cr0pkbE for ; Mon, 10 Sep 2012 13:07:03 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1B11021F861F for ; Mon, 10 Sep 2012 13:06:57 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 68FE21200D0F; Mon, 10 Sep 2012 22:06:55 +0200 (CEST) Date: Mon, 10 Sep 2012 22:06:55 +0200 (CEST) Message-Id: <20120910.220655.433664319.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> 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] interface and ip 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, 10 Sep 2012 20:07:04 -0000 Andy Bierman wrote: > On Mon, Sep 10, 2012 at 8:28 AM, Ladislav Lhotka wrote: > > > > On Sep 10, 2012, at 5:09 PM, Andy Bierman wrote: > > > >> I strongly object to the notion of replacing keys in YANG lists. > >> When you change keys, you delete the old entry and create a new one. > >> Period. That is the only interpretation. > >> > >> I strongly object to undocumented vendor-specific value sets, > >> as identified in this text: > >> > >> A device MAY restrict the allowed values for this leaf, > >> possibly depending on the type and location. > >> > >> This is exactly the type of NMS data-silo design we are trying to > >> avoid in standards. > >> It is less objectionable to do this sort of vendor-specific variant > >> for config=false. > >> But for config=true, it means an application developer will have to > >> figure out from trial and error > >> or perhaps some ad-hoc vendor documentation what values are allowed on > >> each server. > >> > >> This does not promote multi-vendor interoperability. > >> The YANG data type definition is normative. The server must implement > >> the specified syntax (modulo too-big errors, etc.). There cannot be some > >> secret patterns that the server accepts that are not documented > >> in the YANG type-stmt. > >> > > > > I agree, and for all this I propose to avoid using vendor-specific name as > > the list key. It can be part of the data but as a non-key leaf. > > > > That would solve it, but so many other data models reference interface names. > > Isn't the 'location' string also vendor-specific? Yes. > It does not contain any text about how the server MAY restrict > values. It says: The device-specific location of the interface of a particular type. The format of the location string depends on the interface type and the device. The text also says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. > If the client provides an initial value, the server MUST use it, according > to the YANG that is there. I think it makes perfect sense for a device to reject a location string with the value "hi mom". > This whole thread really demonstrates that the REST-full way > of solving this problem is so much better than NETCONF. > Client POSTs new resource, server returns CREATED 201 and > a Location header identifying the new resource. So much cleaner! Well, I agree that this feature is nice, but I fail to see how it would help here. > YANG-API has the 'optional-key' YANG extension to solve this > problem. You still need the location, so it doesn't really solve the problem. > Maybe a API is needed, since standard > is going to be vendor-specific. That way, app developers can choose > the interoperable but very limited or they can create the > vendor-specific interface entry directly with . > > If vendors can pick their own secret patterns for strings, then they can > also change them, right? So a name that works today in the "standard" > is in no way guaranteed to work in the future? I think the current key > for the interface list needs more work. Even if the name is arbitrary, you will still have the problem that different devices have different hardware, and thus different "locations". Again, making the name arbitrary doesn't solve *this* problem. /martin From mbj@tail-f.com Mon Sep 10 13:15:59 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 DA4D111E80A2 for ; Mon, 10 Sep 2012 13:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAqPYCzydWtp for ; Mon, 10 Sep 2012 13:15:59 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 58E1111E808A for ; Mon, 10 Sep 2012 13:15:59 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 82E6D1200D5B; Mon, 10 Sep 2012 22:15:58 +0200 (CEST) Date: Mon, 10 Sep 2012 22:15:58 +0200 (CEST) Message-Id: <20120910.221558.166970929.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> 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] interface and ip 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, 10 Sep 2012 20:16:00 -0000 "Lange, Jeffrey K (GE Energy)" wrote: > What if there was a config=false list of the physical interfaces on a machine, > then new entries in the /interfaces table could point to the physical device > that it is actually using? This would solve the problem of vendors having > name restriction on physical devices, and at the same time allow users to > create interface entries with whatever names they wanted? It would be great with some mechanism a client can use to discover the naming scheme / locations available on a device. But a simple config false list of physical interfaces won't solve this. It might be possible to hot-plug new interfaces for example, and you may want to pre-provision those. Also, even with such a list, an operator can not just use these locations as opaque values - somehow you have to know which physical interface a particular cable is connected to... /martin From mbj@tail-f.com Mon Sep 10 13:25: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 C16D811E80BF for ; Mon, 10 Sep 2012 13:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz9cN0LZg2XJ for ; Mon, 10 Sep 2012 13:25:33 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E5E9A11E809C for ; Mon, 10 Sep 2012 13:25:32 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DCD361200D40; Mon, 10 Sep 2012 22:25:31 +0200 (CEST) Date: Mon, 10 Sep 2012 22:25:31 +0200 (CEST) Message-Id: <20120910.222531.428149139.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <94B333AE-5BEC-47DC-B40D-5D3124617C17@nic.cz> References: <20120910124817.GA52800@elstar.local> <94B333AE-5BEC-47DC-B40D-5D3124617C17@nic.cz> 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] interface and ip 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, 10 Sep 2012 20:25:33 -0000 Ladislav Lhotka wrote: > I propose to avoid using the local interface name as the key for > "interface". One way to do it is to use a new key, say "id", containing an > arbitrary string, so "name" would not be the key anymore, so it can be changed > via . If this really is what we want to do, it is much simpler to remove the text about restrictions on the name, and just say that the name is arbitrary. But it is not clear to me that this solves a real problem. I agree with Juergen that devices will have their naming schemes regardless of what we write in this document, and it seems to be error prone to use a different name in the config and the rest of the system (syslog, snmp, logs, cli messages etc). /martin From andy@yumaworks.com Mon Sep 10 13:33: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 DD1D711E80C5 for ; Mon, 10 Sep 2012 13:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKSMoVkRHmRd for ; Mon, 10 Sep 2012 13:33:02 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1911E80A3 for ; Mon, 10 Sep 2012 13:33:01 -0700 (PDT) Received: by qafi29 with SMTP id i29so1126105qaf.10 for ; Mon, 10 Sep 2012 13:33:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y+ROXPQnDOc8Mdyyef4r8Ams9U5GIw7Pr8zwHPAlTaM=; b=mihcUKEwJQC0to+p0S5/ZbJQTvB75HZUAVbtdVvCwWX3jA5o8uv/Mvg9GgOZr/04iR +/Vga9cKxBylvgXgwfFcM54DUt4SOxhvRjd4aQAXiSiSVXFSKUQ53HePnbEX+aml7ipm LvL6ZP2UaucZg1UAxgHZz0dv09fB/yrEq9lcpz7mZxaYgMSU1Zd4qPrb5Lm2qUwI0C8B cqq/2TkRVkNFlNdlgc9jWllgzQVteBHeTtwJqLWE/jz+L2EaG2ujzms96pcdLJ+WZUhO dfwz6wKfuD4/Qsf6oEVYn9RAs1H5VPOK6kOs3sk8YqZ196rNWvSI8/K0HxEjnNd48DQa d4NA== MIME-Version: 1.0 Received: by 10.224.52.139 with SMTP id i11mr4236331qag.11.1347309181400; Mon, 10 Sep 2012 13:33:01 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 13:33:01 -0700 (PDT) In-Reply-To: <20120910.220655.433664319.mbj@tail-f.com> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> Date: Mon, 10 Sep 2012 13:33:01 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmX9ObeosjUJXjvdDEdFKSwrabNUGuh29q7KxBpTUzJCrd/PkKOwT0kDo1VEqnK5Hu1j3JK Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 20:33:03 -0000 Hi, It's OK to leave this out of scope I guess. The text in the 'name' leaf should be consistent with the 'location' leaf. Maybe I missed the out-of-scope text in the 'name' leaf? It will take too long to come up with a solution satisfactory to everybody, so better not to do anything half-baked and delay this draft. Andy On Mon, Sep 10, 2012 at 1:06 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Mon, Sep 10, 2012 at 8:28 AM, Ladislav Lhotka wrote: >> > >> > On Sep 10, 2012, at 5:09 PM, Andy Bierman wrote: >> > >> >> I strongly object to the notion of replacing keys in YANG lists. >> >> When you change keys, you delete the old entry and create a new one. >> >> Period. That is the only interpretation. >> >> >> >> I strongly object to undocumented vendor-specific value sets, >> >> as identified in this text: >> >> >> >> A device MAY restrict the allowed values for this leaf, >> >> possibly depending on the type and location. >> >> >> >> This is exactly the type of NMS data-silo design we are trying to >> >> avoid in standards. >> >> It is less objectionable to do this sort of vendor-specific variant >> >> for config=false. >> >> But for config=true, it means an application developer will have to >> >> figure out from trial and error >> >> or perhaps some ad-hoc vendor documentation what values are allowed on >> >> each server. >> >> >> >> This does not promote multi-vendor interoperability. >> >> The YANG data type definition is normative. The server must implement >> >> the specified syntax (modulo too-big errors, etc.). There cannot be some >> >> secret patterns that the server accepts that are not documented >> >> in the YANG type-stmt. >> >> >> > >> > I agree, and for all this I propose to avoid using vendor-specific name as >> > the list key. It can be part of the data but as a non-key leaf. >> > >> >> That would solve it, but so many other data models reference interface names. >> >> Isn't the 'location' string also vendor-specific? > > Yes. > >> It does not contain any text about how the server MAY restrict >> values. > > It says: > > The device-specific location of the interface of a > particular type. The format of the location string > depends on the interface type and the device. > > The text also says: > > How a client can learn which types and locations are present on a > certain device is outside the scope of this document. > >> If the client provides an initial value, the server MUST use it, according >> to the YANG that is there. > > I think it makes perfect sense for a device to reject a location > string with the value "hi mom". > >> This whole thread really demonstrates that the REST-full way >> of solving this problem is so much better than NETCONF. >> Client POSTs new resource, server returns CREATED 201 and >> a Location header identifying the new resource. So much cleaner! > > Well, I agree that this feature is nice, but I fail to see how it > would help here. > >> YANG-API has the 'optional-key' YANG extension to solve this >> problem. > > You still need the location, so it doesn't really solve the problem. > >> Maybe a API is needed, since standard >> is going to be vendor-specific. That way, app developers can choose >> the interoperable but very limited or they can create the >> vendor-specific interface entry directly with . >> >> If vendors can pick their own secret patterns for strings, then they can >> also change them, right? So a name that works today in the "standard" >> is in no way guaranteed to work in the future? I think the current key >> for the interface list needs more work. > > Even if the name is arbitrary, you will still have the problem that > different devices have different hardware, and thus different > "locations". Again, making the name arbitrary doesn't solve *this* > problem. > > > /martin From andy@yumaworks.com Mon Sep 10 13:42:59 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 3D6E011E809C for ; Mon, 10 Sep 2012 13:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZWSad+7nPUN for ; Mon, 10 Sep 2012 13:42:58 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4B8B11E808A for ; Mon, 10 Sep 2012 13:42:58 -0700 (PDT) Received: by qcac10 with SMTP id c10so1739871qca.31 for ; Mon, 10 Sep 2012 13:42:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cB9lH+ppJOgVh8bnMRSBrrGUsClgK2d4goHp3gWVXFc=; b=gS8jgMYvJ1nZckqCrEpXf22Y0NMXdKhjbb1+CIQZh/KLTzyqMoXgx5zqYYV4Or6neH 4IEECvBdrZ8ZNIGif7fmIOjnB3TyEofUmafyA6WHhjuVmj1NL9V7iWTgmD0a1x/rOouH lWlXXYw7h3Ct+Ee+Q8Rjdh3zDpzmUP+odkDh0Qg2lJratBPn64nSFhq/NirOMoBXE0H1 KJZXXui7OPtGT/VMkeAwAv7d11QakhWn6LOhChjIGuzlPM7ky4dHMC9MEiefZPpvuXOT BoPUDczcWxHtmhj9VXXnsxRBPFdTEi0LjhD5CvRNMURt+w8SvHfuwm69JhXbFsB6GC/V RJBg== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr17017276qaf.2.1347309778068; Mon, 10 Sep 2012 13:42:58 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 10 Sep 2012 13:42:57 -0700 (PDT) In-Reply-To: <20120910.222531.428149139.mbj@tail-f.com> References: <20120910124817.GA52800@elstar.local> <94B333AE-5BEC-47DC-B40D-5D3124617C17@nic.cz> <20120910.222531.428149139.mbj@tail-f.com> Date: Mon, 10 Sep 2012 13:42:57 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnbr4zAKr/givwsQQURZKdpFgki6ZglcB8+Xp0slh4reKFhItEU2w+sbYYMP6Xoko4tnspp Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 10 Sep 2012 20:42:59 -0000 On Mon, Sep 10, 2012 at 1:25 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> I propose to avoid using the local interface name as the key for >> "interface". One way to do it is to use a new key, say "id", containing an >> arbitrary string, so "name" would not be the key anymore, so it can be changed >> via . > > If this really is what we want to do, it is much simpler to remove the > text about restrictions on the name, and just say that the name is > arbitrary. > > But it is not clear to me that this solves a real problem. > > I agree with Juergen that devices will have their naming schemes > regardless of what we write in this document, and it seems to be error > prone to use a different name in the config and the rest of the system > (syslog, snmp, logs, cli messages etc). > > +1 We don't want multiple naming schemes to map between. Do devices really support renaming list entries? We reject attempts to replace a list key. You have to copy-and-create a new entry then delete the old one. Does RFC 6241 or 6020 say what to do 1 way or the other? I don't remember any edit-config text specific to list keys. Maybe it should be supported. This is a general N/Y issue not specific to interfaces. > /martin Andy From lhotka@nic.cz Tue Sep 11 01:27: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 0E78221F8742 for ; Tue, 11 Sep 2012 01:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaWaeUdQIMrr for ; Tue, 11 Sep 2012 01:27:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0421F8746 for ; Tue, 11 Sep 2012 01:27:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0874C540566 for ; Tue, 11 Sep 2012 10:27:49 +0200 (CEST) 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 jOlz-P2MrcJQ for ; Tue, 11 Sep 2012 10:27:42 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 25A745404F5 for ; Tue, 11 Sep 2012 10:27:41 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120910.220655.433664319.mbj@tail-f.com> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 11 Sep 2012 10:27:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 08:27:54 -0000 Martin Bjorklund writes: >> >> If vendors can pick their own secret patterns for strings, then they can >> also change them, right? So a name that works today in the "standard" >> is in no way guaranteed to work in the future? I think the current key >> for the interface list needs more work. > > Even if the name is arbitrary, you will still have the problem that > different devices have different hardware, and thus different > "locations". Again, making the name arbitrary doesn't solve *this* > problem. So how about doing three simple things: 1. Add a new leaf "local-name", mandatory for physical interfaces. IMO "type" and "location" is not enough, in particular on systems that allow for changing the internal interface name, such as Linux. 2. Make "type" and "location" optional even for physical interfaces. 3. Remove the following two paragraphs from the description of "name": --------------------------------------------------------- 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'. ---------------------------------------------------------- A device imposing such restrictions should declare a deviation. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Sep 11 01:42: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 7B1DF21F8557 for ; Tue, 11 Sep 2012 01:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J92vSQX42ZFp for ; Tue, 11 Sep 2012 01:42:33 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E02E021F84FC for ; Tue, 11 Sep 2012 01:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 15474540566 for ; Tue, 11 Sep 2012 10:42:32 +0200 (CEST) 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 TVsufZtVZ6SP for ; Tue, 11 Sep 2012 10:42:29 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DBED15404F5 for ; Tue, 11 Sep 2012 10:42:28 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120910.221558.166970929.mbj@tail-f.com> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.221558.166970929.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 11 Sep 2012 10:42:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 08:42:33 -0000 Martin Bjorklund writes: > "Lange, Jeffrey K (GE Energy)" wrote: >> What if there was a config=false list of the physical interfaces on a machine, >> then new entries in the /interfaces table could point to the physical device >> that it is actually using? This would solve the problem of vendors having >> name restriction on physical devices, and at the same time allow users to >> create interface entries with whatever names they wanted? > > It would be great with some mechanism a client can use to discover the > naming scheme / locations available on a device. But a simple config > false list of physical interfaces won't solve this. It might be > possible to hot-plug new interfaces for example, and you may want to > pre-provision those. Also, even with such a list, an operator can > not just use these locations as opaque values - somehow you have to > know which physical interface a particular cable is connected to... Pre-provisioning could be easy: The client pre-configures the interface with "name" of his choice, and after the card is plugged in, the client just fills in the "local-name". If the same card is removed, its configuration stay in the interface list, having the same client-selected name as before. Later, if the card plugged in again, it may get another local name from the system. In this case it suffices to update the "local-name" and the configuration works again, including all logical interfaces built upon the hot-pluggable physical interface. Of course, nothing prevents the client form using the tentative local name as the "name" key. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Sep 11 01:45: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 5882A21F8741 for ; Tue, 11 Sep 2012 01:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MASgDq34SzMd for ; Tue, 11 Sep 2012 01:45:05 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DD49421F861F for ; Tue, 11 Sep 2012 01:45:02 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id CBD2712008BF; Tue, 11 Sep 2012 10:45:00 +0200 (CEST) Date: Tue, 11 Sep 2012 10:45:00 +0200 (CEST) Message-Id: <20120911.104500.407602305.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120910.220655.433664319.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interface and ip 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, 11 Sep 2012 08:45:05 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > >> > >> If vendors can pick their own secret patterns for strings, then they can > >> also change them, right? So a name that works today in the "standard" > >> is in no way guaranteed to work in the future? I think the current key > >> for the interface list needs more work. > > > > Even if the name is arbitrary, you will still have the problem that > > different devices have different hardware, and thus different > > "locations". Again, making the name arbitrary doesn't solve *this* > > problem. > > So how about doing three simple things: > > 1. Add a new leaf "local-name", mandatory for physical interfaces. > > IMO "type" and "location" is not enough, in particular on systems that allow > for changing the > internal interface name, such as Linux. Can you elaborate on why type + location is not sufficient? /martin From lhotka@nic.cz Tue Sep 11 01:58:25 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 7E92B21F8797 for ; Tue, 11 Sep 2012 01:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8Zx9xjVr1XP for ; Tue, 11 Sep 2012 01:58:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F34C621F8787 for ; Tue, 11 Sep 2012 01:58:17 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2AC1A140FC2; Tue, 11 Sep 2012 10:58:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347353896; bh=b3NbjizNpomackSC7/m0QjlBQO4dDImr6WfeOkIYR2k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k12L/8ruKYEwIpOmKKEbF3HvNXZDLv8JhNZt6auWBd5IjH86Tpq6f5Hokz28huFE0 G32vIkFTZHmrm7vLkwTBQlK9lWYItRzo/PvY7GokKqxiM9bdDqfIYPnRjj4m3qqD3c 5haorukVD0FxtQb8RUk90FaCpeLZ50k2tCSNqS8g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120911.104500.407602305.mbj@tail-f.com> Date: Tue, 11 Sep 2012 10:58:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120910.220655.433664319.mbj@tail-f.com> <20120911.104500.407602305.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 08:58:25 -0000 On Sep 11, 2012, at 10:45 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>>>=20 >>>> If vendors can pick their own secret patterns for strings, then = they can >>>> also change them, right? So a name that works today in the = "standard" >>>> is in no way guaranteed to work in the future? I think the current = key >>>> for the interface list needs more work. >>>=20 >>> Even if the name is arbitrary, you will still have the problem that >>> different devices have different hardware, and thus different >>> "locations". Again, making the name arbitrary doesn't solve *this* >>> problem. >>=20 >> So how about doing three simple things: >>=20 >> 1. Add a new leaf "local-name", mandatory for physical interfaces. >>=20 >> IMO "type" and "location" is not enough, in particular on systems = that allow >> for changing the >> internal interface name, such as Linux. >=20 > Can you elaborate on why type + location is not sufficient? What will the location leaf contain on Linux if the interface has the = local name "foo"? If you use the "nameif" command to change the interface name, the new = name is really low-level, not just an alias for ethX, for example it = appears in /proc/sys/net/ipv4/conf/. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Sep 11 02:00:31 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 4AC5021F87A5 for ; Tue, 11 Sep 2012 02:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-Yg2RQAb+b2 for ; Tue, 11 Sep 2012 02:00:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D304721F8787 for ; Tue, 11 Sep 2012 02:00:24 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A460E20BCD; Tue, 11 Sep 2012 11:00:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7PiCnPb6Bd08; Tue, 11 Sep 2012 11:00:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B8BF20BC1; Tue, 11 Sep 2012 11:00:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E79621B94DA; Tue, 11 Sep 2012 11:00:19 +0200 (CEST) Date: Tue, 11 Sep 2012 11:00:19 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120911090019.GA69384@elstar.local> Mail-Followup-To: netmod@ietf.org References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> 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) Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 09:00:31 -0000 On Tue, Sep 11, 2012 at 10:27:40AM +0200, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > >> > >> If vendors can pick their own secret patterns for strings, then they can > >> also change them, right? So a name that works today in the "standard" > >> is in no way guaranteed to work in the future? I think the current key > >> for the interface list needs more work. > > > > Even if the name is arbitrary, you will still have the problem that > > different devices have different hardware, and thus different > > "locations". Again, making the name arbitrary doesn't solve *this* > > problem. > > So how about doing three simple things: > > 1. Add a new leaf "local-name", mandatory for physical interfaces. > > IMO "type" and "location" is not enough, in particular on systems that allow for changing the > internal interface name, such as Linux. > > 2. Make "type" and "location" optional even for physical interfaces. > > 3. Remove the following two paragraphs from the description of "name": > > --------------------------------------------------------- > 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'. > ---------------------------------------------------------- > > A device imposing such restrictions should declare a deviation. So what precisely is the definition of 'name' and 'local-name'? If I do "ip link set eth0 name foo" on a Linux box, am I changing the 'name' or the 'local-name'? If I use interfaces(5) on a Debian-like system, is the name of a stanza a 'name' or a 'local-name'? If I have both, 'name' and 'local-name', how does that related to objects in say the IF-MIB? /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 Tue Sep 11 02:26:38 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 B505B21F8770 for ; Tue, 11 Sep 2012 02:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RFH42TJB53w for ; Tue, 11 Sep 2012 02:26:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A8F8121F854E for ; Tue, 11 Sep 2012 02:26:37 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B7CD6140FC2; Tue, 11 Sep 2012 11:26:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347355596; bh=olQUkcvNEWgd7FzxTpgXk8pXmhnG2kGGX72Avocgd8M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D0LTLDbtTTB1HsXOvUbYnFQNiWCEGBF3N8DRs8+d9ec1HVLYxUU4P1Gs240QUvHjW zwmROOB6DcejB4ZZ/zJZCUVjVePTQULkh+7F4Nxu3VU8SVEuY6K0MUzDSZn+d6YwpZ udbJPO0IqjxOweR0Ck/kmraNUY+FTHbdydaX6mH0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120911090019.GA69384@elstar.local> Date: Tue, 11 Sep 2012 11:26:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 09:26:39 -0000 On Sep 11, 2012, at 11:00 AM, Juergen Schoenwaelder = wrote: > On Tue, Sep 11, 2012 at 10:27:40AM +0200, Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>>>=20 >>>> If vendors can pick their own secret patterns for strings, then = they can >>>> also change them, right? So a name that works today in the = "standard" >>>> is in no way guaranteed to work in the future? I think the current = key >>>> for the interface list needs more work. >>>=20 >>> Even if the name is arbitrary, you will still have the problem that >>> different devices have different hardware, and thus different >>> "locations". Again, making the name arbitrary doesn't solve *this* >>> problem. >>=20 >> So how about doing three simple things: >>=20 >> 1. Add a new leaf "local-name", mandatory for physical interfaces. >>=20 >> IMO "type" and "location" is not enough, in particular on systems = that allow for changing the=20 >> internal interface name, such as Linux. >>=20 >> 2. Make "type" and "location" optional even for physical interfaces. >>=20 >> 3. Remove the following two paragraphs from the description of = "name": >>=20 >> --------------------------------------------------------- >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >>=20 >> 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'. >> ---------------------------------------------------------- >>=20 >> A device imposing such restrictions should declare a deviation. >=20 > So what precisely is the definition of 'name' and 'local-name'? If I > do "ip link set eth0 name foo" on a Linux box, am I changing the > 'name' or the 'local-name'? If I use interfaces(5) on a Debian-like In this case you are changing. I am not sure about kernel guts, but from = the user's perspective "eth0" no more exists.=20 > system, is the name of a stanza a 'name' or a 'local-name'? If I have If you rename eth0 to foo before /etc/network/interfaces is read, you = have to use "foo" in that file because it is now the local name of that = interface. The "name" key is applicable only in the context of a NETCONF = configuration. > both, 'name' and 'local-name', how does that related to objects in say > the IF-MIB? =46rom RFC 2863 it seems clear that "local-name" corresponds to = "ifName", and "name" corresponds to "ifAlias": "[The ifName] object contains the device's local name (e.g., the name = used at the device's local console) =85" "[ifAlias] provides a location in which a network management application = can store a non-volatile interface-naming value of its own choice." Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Sep 11 02:32:31 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 79A0E21F85B4 for ; Tue, 11 Sep 2012 02:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h9IWf5IiITa for ; Tue, 11 Sep 2012 02:32:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BF21F85AA for ; Tue, 11 Sep 2012 02:32:30 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C1A8F140FC2; Tue, 11 Sep 2012 11:32:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347355949; bh=CaVmnmaWVjxzKYyJtpKpuk7F7kfaczp4bOJlsK9Wx1c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F0iUWyIWTwTPVePb8qKgUGUdPfu2wsyr48+dKf1CSOMz7w4CaONltbljxzn7jOcJL kNzqxv58UPRAzI/J9ZYOtHAiCkyE0lHAqy+h4FeIjC/xXzI2C0m8a1+fPNuqxGHw6Z kyv5g50jE4xk+SjoKU/lf94jJMr2vHhBKmx+QfME= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 11 Sep 2012 11:32:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9026A01C-0FB7-47E1-A62D-5DC9044C90E8@nic.cz> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 09:32:31 -0000 On Sep 11, 2012, at 11:26 AM, Ladislav Lhotka wrote: >>=20 >> So what precisely is the definition of 'name' and 'local-name'? If I >> do "ip link set eth0 name foo" on a Linux box, am I changing the >> 'name' or the 'local-name'? If I use interfaces(5) on a Debian-like >=20 > In this case you are changing. I am not sure about kernel guts, but = from the user's perspective "eth0" no more exists. I meant "In this case you are changing 'local-name'". Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Sep 11 02:42: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 A180821F859B for ; Tue, 11 Sep 2012 02:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL5CSTmr9EwO for ; Tue, 11 Sep 2012 02:42:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E5C0621F8564 for ; Tue, 11 Sep 2012 02:42:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46B8620C39; Tue, 11 Sep 2012 11:42:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ChddMvXM3XAb; Tue, 11 Sep 2012 11:42:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF5EB20C2E; Tue, 11 Sep 2012 11:42:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F28321B9948; Tue, 11 Sep 2012 11:42:33 +0200 (CEST) Date: Tue, 11 Sep 2012 11:42:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120911094233.GA69531@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 09:42:40 -0000 On Tue, Sep 11, 2012 at 11:26:35AM +0200, Ladislav Lhotka wrote: > > On Sep 11, 2012, at 11:00 AM, Juergen Schoenwaelder wrote: > > > > > So what precisely is the definition of 'name' and 'local-name'? If I > > do "ip link set eth0 name foo" on a Linux box, am I changing the > > 'name' or the 'local-name'? If I use interfaces(5) on a Debian-like > > In this case you are changing. I am not sure about kernel guts, but from the user's perspective "eth0" no more exists. > > > system, is the name of a stanza a 'name' or a 'local-name'? If I have > > If you rename eth0 to foo before /etc/network/interfaces is read, you have to use "foo" in that file because it is now the local name of that interface. > > The "name" key is applicable only in the context of a NETCONF configuration. > > > both, 'name' and 'local-name', how does that related to objects in say > > the IF-MIB? > > From RFC 2863 it seems clear that "local-name" corresponds to "ifName", and "name" corresponds to "ifAlias": > > "[The ifName] object contains the device's local name (e.g., the name used at the device's local console) …" > > "[ifAlias] provides a location in which a network management application can store a non-volatile interface-naming value of its own choice." > This means the description leaf in -06 becomes obsolete? And now you want essentially all references to the interface alias instead of the interface name used natively by the operating system. Now, supposed I do that and I call my interface 'customer-foo'. What happens if I have to change 'customer-foo' to 'customer-bar'? Now you prefer that the key would have been the interface name, not its alias. In other words, you seem to assume that freely choosen names are more stable and the names assigned by the underlying operating system, no? /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 Sep 11 02:51:35 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 AE70C21F8769 for ; Tue, 11 Sep 2012 02:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jkh7F1Y-Frv for ; Tue, 11 Sep 2012 02:51:34 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BB20D21F8764 for ; Tue, 11 Sep 2012 02:51:34 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E612D1200D0F; Tue, 11 Sep 2012 11:51:33 +0200 (CEST) Date: Tue, 11 Sep 2012 11:51:33 +0200 (CEST) Message-Id: <20120911.115133.303554024.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120911.104500.407602305.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interface and ip 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, 11 Sep 2012 09:51:35 -0000 Ladislav Lhotka wrote: > > On Sep 11, 2012, at 10:45 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >>>> > >>>> If vendors can pick their own secret patterns for strings, then they can > >>>> also change them, right? So a name that works today in the "standard" > >>>> is in no way guaranteed to work in the future? I think the current key > >>>> for the interface list needs more work. > >>> > >>> Even if the name is arbitrary, you will still have the problem that > >>> different devices have different hardware, and thus different > >>> "locations". Again, making the name arbitrary doesn't solve *this* > >>> problem. > >> > >> So how about doing three simple things: > >> > >> 1. Add a new leaf "local-name", mandatory for physical interfaces. > >> > >> IMO "type" and "location" is not enough, in particular on systems that > >> allow > >> for changing the > >> internal interface name, such as Linux. > > > > Can you elaborate on why type + location is not sufficient? > > What will the location leaf contain on Linux if the interface has the local > name "foo"? This would be a system that allows arbitrary names, and the arbitrary name "foo" is not enough to identify the physical interface. This is why there is type and location. So the location leaf in case might be "1" (if this was 'eth1' originally). > If you use the "nameif" command to change the interface name, the new name is > really low-level, not just an alias for ethX, for example it appears in > /proc/sys/net/ipv4/conf/. nameif assigns a name based on the MAC address. And it works only for ethernet interfaces, so maybe it is not a good idea to use it for this purpose. /martin From lhotka@nic.cz Tue Sep 11 02:59: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 4944F21F87BC for ; Tue, 11 Sep 2012 02:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJSpuhVVfVMQ for ; Tue, 11 Sep 2012 02:59:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5337F21F87B8 for ; Tue, 11 Sep 2012 02:59:25 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9C098140FC2; Tue, 11 Sep 2012 11:59:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347357564; bh=6XoRIKBLPAg7upQS8MeF4Vx3Irwe9iJ5eEAbgzi7Paw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WPlwjEFjs0AsEY4s8fdQ8sMqd8mxRa8QcOvvs+MqOgbglMF9DEVrTbxs7/axzU18R dz9XLQrsbbPZDbtbOtf6lPx/VZeHqPlTQ315qvirkja+eQsyLir1fH6eWwshSV3lrT /vDV9kTfaVkTvum2MwHfm3ldmi0EObKDDC3lHMyY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120911094233.GA69531@elstar.local> Date: Tue, 11 Sep 2012 11:59:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 09:59:26 -0000 On Sep 11, 2012, at 11:42 AM, Juergen Schoenwaelder = wrote: > On Tue, Sep 11, 2012 at 11:26:35AM +0200, Ladislav Lhotka wrote: >>=20 >> On Sep 11, 2012, at 11:00 AM, Juergen Schoenwaelder = wrote: >>=20 >>>=20 >>> So what precisely is the definition of 'name' and 'local-name'? If I >>> do "ip link set eth0 name foo" on a Linux box, am I changing the >>> 'name' or the 'local-name'? If I use interfaces(5) on a Debian-like >>=20 >> In this case you are changing. I am not sure about kernel guts, but = from the user's perspective "eth0" no more exists.=20 >>=20 >>> system, is the name of a stanza a 'name' or a 'local-name'? If I = have >>=20 >> If you rename eth0 to foo before /etc/network/interfaces is read, you = have to use "foo" in that file because it is now the local name of that = interface. >>=20 >> The "name" key is applicable only in the context of a NETCONF = configuration. >>=20 >>> both, 'name' and 'local-name', how does that related to objects in = say >>> the IF-MIB? >>=20 >> =46rom RFC 2863 it seems clear that "local-name" corresponds to = "ifName", and "name" corresponds to "ifAlias": >>=20 >> "[The ifName] object contains the device's local name (e.g., the name = used at the device's local console) =85" >>=20 >> "[ifAlias] provides a location in which a network management = application can store a non-volatile interface-naming value of its own = choice." >>=20 >=20 > This means the description leaf in -06 becomes obsolete? And now you No, this leaf may still contain any text describing the the interface in = prose, or whatever. It corresponds to "ifDescr". > want essentially all references to the interface alias instead of the > interface name used natively by the operating system. Now, supposed I > do that and I call my interface 'customer-foo'. What happens if I have > to change 'customer-foo' to 'customer-bar'? Now you prefer that the Do you mean you change it via "ip link"? In this case, you have to = change "local-name" in the NETCONF configuration to "customer-bar". The = "name" key needn't be changed. =20 > key would have been the interface name, not its alias. In other words, > you seem to assume that freely choosen names are more stable and the > names assigned by the underlying operating system, no? I guess the role and motivation for "name" are pretty much the same as = for "ifAlias" in RFC 2863. The RFC continues: "The ifAlias object allows a network manager to give one or more interfaces their own unique names, irrespective of any interface- stack relationship." Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Sep 11 03:17: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 8A80521F860D for ; Tue, 11 Sep 2012 03:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQKXzXEOGYqG for ; Tue, 11 Sep 2012 03:17:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E721F85F3 for ; Tue, 11 Sep 2012 03:17:42 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F0663140FC2; Tue, 11 Sep 2012 12:17:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347358662; bh=+xBh1vAohSVYLp4wWnr2edUPXUDPUv901J4DmnbaUtI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=S+CY3O08wye7tqHWq/p33zVYt39T0SB8nH4OUUVYNVHafaJb18sgSbp8v68MUMyF2 XL2jpAt8mdlMJZyzoBITEoWL63jrrS4Xl36+D0e3efmQAxxX7ojd0vZmPd3riheFNW 4zlqd8FnOcyU6LvfhXr3U0D3m9TzOpFvK7kQPV5U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120911.115133.303554024.mbj@tail-f.com> Date: Tue, 11 Sep 2012 12:17:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911.104500.407602305.mbj@tail-f.com> <20120911.115133.303554024.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 10:17:43 -0000 On Sep 11, 2012, at 11:51 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Sep 11, 2012, at 10:45 AM, Martin Bjorklund = wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> Martin Bjorklund writes: >>>>=20 >>>>>>=20 >>>>>> If vendors can pick their own secret patterns for strings, then = they can >>>>>> also change them, right? So a name that works today in the = "standard" >>>>>> is in no way guaranteed to work in the future? I think the = current key >>>>>> for the interface list needs more work. >>>>>=20 >>>>> Even if the name is arbitrary, you will still have the problem = that >>>>> different devices have different hardware, and thus different >>>>> "locations". Again, making the name arbitrary doesn't solve = *this* >>>>> problem. >>>>=20 >>>> So how about doing three simple things: >>>>=20 >>>> 1. Add a new leaf "local-name", mandatory for physical interfaces. >>>>=20 >>>> IMO "type" and "location" is not enough, in particular on systems = that >>>> allow >>>> for changing the >>>> internal interface name, such as Linux. >>>=20 >>> Can you elaborate on why type + location is not sufficient? >>=20 >> What will the location leaf contain on Linux if the interface has the = local >> name "foo"? >=20 > This would be a system that allows arbitrary names, and the arbitrary > name "foo" is not enough to identify the physical interface. This is Why? =46rom the system point of view, "foo" uniquely identifies the = interface. > why there is type and location. So the location leaf in case might be > "1" (if this was 'eth1' originally). The "1" has no meaning in the system anymore, and you have to assume = that "name" contains "foo". This not only makes the "name" key vendor = specific, but also makes it difficult to change the name via = . For instance, if somebody changes the name from the = console, ip link set dev foo name bar then you have to create a new interface entry with the "bar" key, copy = and paste all configuration, and also find all references to "foo" in = the entire configuration and change them to "bar".=20 >=20 >> If you use the "nameif" command to change the interface name, the new = name is >> really low-level, not just an alias for ethX, for example it appears = in >> /proc/sys/net/ipv4/conf/. >=20 > nameif assigns a name based on the MAC address. And it works only for > ethernet interfaces, so maybe it is not a good idea to use it for this > purpose. You can also use the "ip link" command as above. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Sep 11 03:24: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 E4D9421F8790 for ; Tue, 11 Sep 2012 03:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRkZsJpDa6An for ; Tue, 11 Sep 2012 03:24:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DABB321F8775 for ; Tue, 11 Sep 2012 03:24:04 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34B4720C88; Tue, 11 Sep 2012 12:24:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O5gCamzi5USc; Tue, 11 Sep 2012 12:24:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2E0120C82; Tue, 11 Sep 2012 12:24:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38DFD21B9CD8; Tue, 11 Sep 2012 12:23:59 +0200 (CEST) Date: Tue, 11 Sep 2012 12:23:59 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120911102359.GA69650@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 10:24:06 -0000 On Tue, Sep 11, 2012 at 11:59:24AM +0200, Ladislav Lhotka wrote: [...] > > This means the description leaf in -06 becomes obsolete? And now you > > No, this leaf may still contain any text describing the the interface in prose, or whatever. It corresponds to "ifDescr". Well, this is not what -06 says. But perhaps this is just a bug? leaf description { type string; description "A textual description of the interface. This leaf MAY be mapped to ifAlias by an implementation. Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifAlias. If a NETCONF server that implements this restriction is sent a value that doesn't match the restriction, it MUST reply with an rpc-error with the error-tag 'invalid-value'."; reference "RFC 2863: The Interfaces Group MIB - ifAlias"; } > > want essentially all references to the interface alias instead of the > > interface name used natively by the operating system. Now, supposed I > > do that and I call my interface 'customer-foo'. What happens if I have > > to change 'customer-foo' to 'customer-bar'? Now you prefer that the > > Do you mean you change it via "ip link"? In this case, you have to change "local-name" in the NETCONF configuration to "customer-bar". The "name" key needn't be changed. > No, I am talking about the key of my NETCONF interface configuration. > > key would have been the interface name, not its alias. In other words, > > you seem to assume that freely choosen names are more stable and the > > names assigned by the underlying operating system, no? > > I guess the role and motivation for "name" are pretty much the same as for "ifAlias" in RFC 2863. The RFC continues: > > "The ifAlias object allows a network manager to give one or more > interfaces their own unique names, irrespective of any interface- > stack relationship." If I recall correctly, you started with these arguments: a) If we use the OS local name for identifying interfaces, renaming becomes hard since NETCONF's edit-config() requires a delete/create cycle. b) There likely will be many leafref references to the interface that also need to be updated to make the change complete. Now, if instead we allow an arbitrary interface name, such as "customer-foo" and map that to the OS local interface name (e.g., "en42"), once I start to dislike my arbitrary interface name, that is I want to change "customer-foo" to "customer-bar", I think a) and b) still apply. So does it then not boil down to how likely OS local names change versus how likely administratively assigned names change? And do we have reached agreement that OS local interface name changes, e.g., 'ip link set eth42 name foo' are outside the scope of this data model at this point in time? /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 Sep 11 03:33: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 CB54821F87AD for ; Tue, 11 Sep 2012 03:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVU-3rYiaR-q for ; Tue, 11 Sep 2012 03:33:40 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8A121F87A2 for ; Tue, 11 Sep 2012 03:33:40 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 631411200D0F; Tue, 11 Sep 2012 12:33:39 +0200 (CEST) Date: Tue, 11 Sep 2012 12:33:38 +0200 (CEST) Message-Id: <20120911.123338.138215661.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120911102359.GA69650@elstar.local> References: <20120911094233.GA69531@elstar.local> <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> <20120911102359.GA69650@elstar.local> X-Mailer: Mew version 6.4 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] interface and ip 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, 11 Sep 2012 10:33:40 -0000 Juergen Schoenwaelder wrote: > On Tue, Sep 11, 2012 at 11:59:24AM +0200, Ladislav Lhotka wrote: > > [...] > > > > This means the description leaf in -06 becomes obsolete? And now you > > > > No, this leaf may still contain any text describing the the interface in > > prose, or whatever. It corresponds to "ifDescr". > > Well, this is not what -06 says. But perhaps this is just a bug? ifDescr is read-only in the MIB. We had a discussion some IETFs back about how ifAlias was really used by operators, and people said it is used as a general description of the interface, not necessarily just another name. /martin From lhotka@nic.cz Tue Sep 11 06:20: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 6A91721F85E6 for ; Tue, 11 Sep 2012 06:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3pV-SdJdcEH for ; Tue, 11 Sep 2012 06:20:22 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2F21F87E7 for ; Tue, 11 Sep 2012 06:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1EB97540566; Tue, 11 Sep 2012 15:20:20 +0200 (CEST) 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 EUQaSEKls9os; Tue, 11 Sep 2012 15:20:13 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3E68554013B; Tue, 11 Sep 2012 15:20:12 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20120911.123338.138215661.mbj@tail-f.com> References: <20120911094233.GA69531@elstar.local> <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> <20120911102359.GA69650@elstar.local> <20120911.123338.138215661.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de, netmod@ietf.org Date: Tue, 11 Sep 2012 15:20:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 13:20:22 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Tue, Sep 11, 2012 at 11:59:24AM +0200, Ladislav Lhotka wrote: >> >> [...] >> >> > > This means the description leaf in -06 becomes obsolete? And now you >> > >> > No, this leaf may still contain any text describing the the interface in >> > prose, or whatever. It corresponds to "ifDescr". >> >> Well, this is not what -06 says. But perhaps this is just a bug? > > ifDescr is read-only in the MIB. We had a discussion some IETFs back OK, so it's only manufacturer's info. > about how ifAlias was really used by operators, and people said it is > used as a general description of the interface, not necessarily just > another name. This is not what RFC 2863 says about the intended use of ifAlias. It looks like a kludge due to the absence of an object corresponding to a read-write description as we know it from CLIs. Lada > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Sep 11 07:27: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 3226921F8809 for ; Tue, 11 Sep 2012 07:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R4UURVsLD7k for ; Tue, 11 Sep 2012 07:27:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0193921F8803 for ; Tue, 11 Sep 2012 07:27:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BBB25540566 for ; Tue, 11 Sep 2012 16:27:17 +0200 (CEST) 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 UC5UZeeuz87l for ; Tue, 11 Sep 2012 16:27:06 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3481B5404F5 for ; Tue, 11 Sep 2012 16:27:05 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120911102359.GA69650@elstar.local> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> <20120911102359.GA69650@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 11 Sep 2012 16:27:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 14:27:20 -0000 Juergen Schoenwaelder writes: > On Tue, Sep 11, 2012 at 11:59:24AM +0200, Ladislav Lhotka wrote: > > [...] > >> > This means the description leaf in -06 becomes obsolete? And now you >> >> No, this leaf may still contain any text describing the the interface in prose, or whatever. It corresponds to "ifDescr". > > Well, this is not what -06 says. But perhaps this is just a bug? > > leaf description { > type string; > description > "A textual description of the interface. > > This leaf MAY be mapped to ifAlias by an implementation. > Such an implementation MAY restrict the allowed values for > this leaf so that it matches the restrictions of ifAlias. > If a NETCONF server that implements this restriction is > sent a value that doesn't match the restriction, it MUST > reply with an rpc-error with the error-tag > 'invalid-value'."; > reference > "RFC 2863: The Interfaces Group MIB - ifAlias"; > } See my previous response to Martin. > >> > want essentially all references to the interface alias instead of the >> > interface name used natively by the operating system. Now, supposed I >> > do that and I call my interface 'customer-foo'. What happens if I have >> > to change 'customer-foo' to 'customer-bar'? Now you prefer that the >> >> Do you mean you change it via "ip link"? In this case, you have to change "local-name" in the NETCONF configuration to "customer-bar". The "name" key needn't be changed. >> > > No, I am talking about the key of my NETCONF interface configuration. The "name" cannot be changed because it is a list key, at least not via . > >> > key would have been the interface name, not its alias. In other words, >> > you seem to assume that freely choosen names are more stable and the >> > names assigned by the underlying operating system, no? >> >> I guess the role and motivation for "name" are pretty much the same as for "ifAlias" in RFC 2863. The RFC continues: >> >> "The ifAlias object allows a network manager to give one or more >> interfaces their own unique names, irrespective of any interface- >> stack relationship." > > If I recall correctly, you started with these arguments: > > a) If we use the OS local name for identifying interfaces, renaming > becomes hard since NETCONF's edit-config() requires a delete/create > cycle. But I mean renaming that is forced by the change in the local name of the corresponding physical interface. For example, I reboot my Linux box and find out that my two Ethernet cards swapped their names "eth0" and "eth1" because the new kernel uses a different order of device driver initialization - I saw this several times. In the OS shell, I can simply edit /etc/network/interfaces, but in NETCONF it is not that easy if "eth0" and "eth1" are list keys. > > b) There likely will be many leafref references to the interface that > also need to be updated to make the change complete. Yes, because these references point to a wrong/nonexistent interface. > > Now, if instead we allow an arbitrary interface name, such as > "customer-foo" and map that to the OS local interface name (e.g., > "en42"), once I start to dislike my arbitrary interface name, that is > I want to change "customer-foo" to "customer-bar", I think a) and b) > still apply. So does it then not boil down to how likely OS local > names change versus how likely administratively assigned names change? My use case is sort of opposite - easy changes of the "name" key are not supported because (i) it is a list key, and (ii) such a change may break references to that interface. Instead, it is easy to handle changes in the underlying local name that is assigned by the system and follows the vendor's rules. In your example, if it is on Linux, you can do ip link set dev customer-foo name customer-bar and update the "local-name" in the NETCONF configuration to "customer-bar". Of course, if the "name" key of this interface was originally "customer-foo", and it cannot be changed, then the new configuration of that interface may be a bit confusing, but at least nothing will break. Detaching the "name" key from the local name also makes the configuration more vendor and system independent. > > And do we have reached agreement that OS local interface name changes, > e.g., 'ip link set eth42 name foo' are outside the scope of this data > model at this point in time? Yes, except there must be a way for indicating the physical interface to which a given NETCONF interface entry belongs. Lada > > /js > > -- > 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 mbj@tail-f.com Tue Sep 11 07:43:29 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 B4E9621F87FF for ; Tue, 11 Sep 2012 07:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBFHxxePFqiM for ; Tue, 11 Sep 2012 07:43:29 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 337CC21F87FE for ; Tue, 11 Sep 2012 07:43:29 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C8A412008BF; Tue, 11 Sep 2012 16:43:28 +0200 (CEST) Date: Tue, 11 Sep 2012 16:43:27 +0200 (CEST) Message-Id: <20120911.164327.111194529.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> <20120911102359.GA69650@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] interface and ip 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, 11 Sep 2012 14:43:29 -0000 Ladislav Lhotka wrote: > Yes, except there must be a way for indicating the physical interface to which > a given NETCONF interface entry belongs. Agreed. The idea was that the combination 'type' and 'location' would do this, where 'location' is defined as some string the device can use to identify the physical hardware. On linux, it doesn't seem that "eth0" and "eth1" are good names, neither for 'name', 'location' or your proposed 'local-name', since they may change with a new kernel. /martin From lhotka@nic.cz Tue Sep 11 08:13: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 8749A21F87DC for ; Tue, 11 Sep 2012 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWjIcllBxCXn for ; Tue, 11 Sep 2012 08:13:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0721F87D8 for ; Tue, 11 Sep 2012 08:13:35 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EA8F8140FC2; Tue, 11 Sep 2012 17:13:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347376415; bh=kUvku25m5Xd+S4J2+tLKtYGTjD7OkBw26ixMOnn9OIA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=b66cVYnuoYgNTsJRjNFLNP1cFGQJUXk5f1AP2j2JdRIPmYmw7za/pbvoWFnOz1V/V kHcVI7BCqroyWiKe3Vg6oy1NfDWrYK+UqkYjJ28tKdAH7XgpK14lSSLRGmc/Anh6Qc vsxbOxqFkWqc6EFFvu6DfmPAp+sZ0x4bL2pfPUH8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120911.164327.111194529.mbj@tail-f.com> Date: Tue, 11 Sep 2012 17:13:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <817D984D-7756-4F49-9797-4760BF818931@nic.cz> References: <0D286046-00DB-4E71-8680-54CF52E0100D@nic.cz> <20120911102359.GA69650@elstar.local> <20120911.164327.111194529.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 15:13:36 -0000 On Sep 11, 2012, at 4:43 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Yes, except there must be a way for indicating the physical interface = to which >> a given NETCONF interface entry belongs. >=20 > Agreed. The idea was that the combination 'type' and 'location' would > do this, where 'location' is defined as some string the device can use > to identify the physical hardware. So let's take the example in appendix D of the interfaces-cfg draft, and = assume there is more configuration, IP addresses, VLANs etc. What is the = NETCONF client supposed to do after finding out that the operating = system swapped eth0 and eth1? =20 >=20 > On linux, it doesn't seem that "eth0" and "eth1" are good names, > neither for 'name', 'location' or your proposed 'local-name', since > they may change with a new kernel. Well, "local-name" is a good name because it is the name under which the = interface is known to the operating system. If the OS or its admin = change their mind, then the local-name has to be updated in the NETCONF = configuration(s). But the client can do this update using a simple = because "local-name" is not the list key. I agree that "0" or "1" has nothing to do with location of the interface = as it just reflects the (arbitrary) order of initialisation. IMO it = would be better to use the PCI address as the "location" value. But even = then it is useful to know that a given interface is "eth0" from the OS = perspective. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Tue Sep 11 09:59: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 133EB21F87AF for ; Tue, 11 Sep 2012 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSKa0E6Dw6Gf for ; Tue, 11 Sep 2012 09:59:50 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1B421F876E for ; Tue, 11 Sep 2012 09:59:49 -0700 (PDT) Received: from mail3-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 16:59:48 +0000 Received: from mail3-db3 (localhost [127.0.0.1]) by mail3-db3-R.bigfish.com (Postfix) with ESMTP id D725C4010C; Tue, 11 Sep 2012 16:59:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I542M1432I1418Izz1202h1d1ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail3-db3 (localhost.localdomain [127.0.0.1]) by mail3-db3 (MessageSwitch) id 1347382785659821_7374; Tue, 11 Sep 2012 16:59:45 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.233]) by mail3-db3.bigfish.com (Postfix) with ESMTP id 95A7A400054; Tue, 11 Sep 2012 16:59:45 +0000 (UTC) Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 16:59:42 +0000 Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 11 Sep 2012 16:59:40 +0000 Message-ID: <000401cd903e$ed065640$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka References: <20120910.220655.433664319.mbj@tail-f.com> <20120911.104500.407602305.mbj@tail-f.com> Date: Tue, 11 Sep 2012 12:43:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.85] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 16:59:51 -0000 Lada In principle, I agree with your suggestion but it is an argument I have had many, many times over the years and have almost always lost, even if people tell me years afterwards that I was right and that they wished that they had listened to me:-( I am against encoding information into names, seeing them as identifiers that should be simple to use and not a source of something that instead should be looked up in a database; but I usually lose out to those who want to encode something useful, such as the type of the object, the physical path to the network etc. And when the useful information changes, as it always does, then there is the choice of the useful information now being misleading, or of telling everyone that the object now has a new identifier, and yes, they will have to update all the places where they have incorporated a reference to the printer name:-) I am pleasantly surprised at how many operational, relational databases actually do do this, with the primary key being system-chosen and a seemingly arbitrary string that is hardly visible, with the keys that the user uses being meaningful to users but always secondary. Changing the primary key is then straightforward. But in the community of network and systems management, this almost never happens. So I think that you are right, but I do not expect it to happen. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Martin Bjorklund" Cc: Sent: Tuesday, September 11, 2012 9:58 AM Subject: Re: [netmod] interface and ip > > On Sep 11, 2012, at 10:45 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >>>> > >>>> If vendors can pick their own secret patterns for strings, then they can > >>>> also change them, right? So a name that works today in the "standard" > >>>> is in no way guaranteed to work in the future? I think the current key > >>>> for the interface list needs more work. > >>> > >>> Even if the name is arbitrary, you will still have the problem that > >>> different devices have different hardware, and thus different > >>> "locations". Again, making the name arbitrary doesn't solve *this* > >>> problem. > >> > >> So how about doing three simple things: > >> > >> 1. Add a new leaf "local-name", mandatory for physical interfaces. > >> > >> IMO "type" and "location" is not enough, in particular on systems that allow > >> for changing the > >> internal interface name, such as Linux. > > > > Can you elaborate on why type + location is not sufficient? > > What will the location leaf contain on Linux if the interface has the local name "foo"? > > If you use the "nameif" command to change the interface name, the new name is really low-level, not just an alias for ethX, for example it appears in /proc/sys/net/ipv4/conf/. > > Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From wjhns1@hardakers.net Tue Sep 11 10:11: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 1B50F21F8773 for ; Tue, 11 Sep 2012 10:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY5GGZXE2ruC for ; Tue, 11 Sep 2012 10:11:45 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D7D21F876A for ; Tue, 11 Sep 2012 10:11:45 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 9D99D272; Tue, 11 Sep 2012 10:11:43 -0700 (PDT) From: Wes Hardaker To: Ladislav Lhotka References: Date: Tue, 11 Sep 2012 10:11:43 -0700 In-Reply-To: (Ladislav Lhotka's message of "Thu, 6 Sep 2012 13:48:33 +0200") Message-ID: <0lfw6oh4c0.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] routing-cfg issues 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, 11 Sep 2012 17:11:46 -0000 Ladislav Lhotka writes: > 2.1. Implementations will supply the mandatory objects as entries of a > config=true list but declare them read-only so that they cannot be > deleted by the client. > > 2.2. The mandatory entries will exist as state data, but outside the > core data model. A client wanting to refer to them will have to > explicitly configure a corresponding dummy entry in the config=true > list and refer to this entry. ugh... This is where the whole "lets separate config and operational state" kinda falls apart. If you want to keep that separation pure, then when someone does a get-config dump so they can later re-upload it after rebuilding a system, you certainly don't want "direct" entries in it that will conflict because they don't match the new-device's internal state. Thus, it seems to me they shouldn't be listed as config or else those scripted config-grabs will get confused. But that doesn't feel right either. Sigh. > 3.1. Really fix the main routing table name, i.e. make it a MUST. > > 3.2. Introduce a new leaf node, e.g. "main-routing-table", pointing to > the main table. > > 3.3. Add the "type" leaf under "routing-table" and use it for > distinguishing the main routing table from the rest. My preference order: 3.2, 3.1 then 3.3 -- Wes Hardaker SPARTA, Inc. From lhotka@nic.cz Tue Sep 11 11:47:44 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 C45EE21F8581 for ; Tue, 11 Sep 2012 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nji7iWDl-pIu for ; Tue, 11 Sep 2012 11:47:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BF34821F8578 for ; Tue, 11 Sep 2012 11:47:43 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9A04A140FC2; Tue, 11 Sep 2012 20:47:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347389262; bh=D3Sz4vR5ItNbi2jPdlGxrUIpEzVt5Z4sl2jZ5abNRXs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qB+CL9JLZDybVeLm6ngS02ihQAOonpiIyFgjrmJMwuTAEOyrF9zmjbCBkkfDaDF5N 9PG7nh/xTYyaAYXSLh0aY3am4Lj/kwmXZcLIBy+mKXmLa8ZrsywTupEd6kncZ/GW9P q2HkWHMvfreXPo3ZHKs9JyJ3QB6CjGH0DCRLeg8E= Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <000401cd903e$ed065640$4001a8c0@gateway.2wire.net> Date: Tue, 11 Sep 2012 20:47:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B6990E3-E2FB-4360-B6FD-8C46F63AE036@nic.cz> References: <20120910.220655.433664319.mbj@tail-f.com> <20120911.104500.407602305.mbj@tail-f.com> <000401cd903e$ed065640$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 18:47:44 -0000 On Sep 11, 2012, at 1:43 PM, t.petch wrote: > Lada >=20 > In principle, I agree with your suggestion but it is an argument I = have > had many, many times over the years and have almost always lost, even = if > people tell me years afterwards that I was right and that they wished > that they had listened to me:-( I understand that vendors (especially the big ones) consider their = naming schemes a part of their trademark, so they are opposed to any = vendor-independent scheme. However, for operators it would IMO be a real = boon. >=20 > I am against encoding information into names, seeing them as = identifiers > that should be simple to use and not a source of something that = instead > should be looked up in a database; but I usually lose out to those who > want to encode something useful, such as the type of the object, the > physical path to the network etc. And when the useful information > changes, as it always does, then there is the choice of the useful > information now being misleading, or of telling everyone that the = object > now has a new identifier, and yes, they will have to update all the > places where they have incorporated a reference to the printer name:-) Absolutely! >=20 > I am pleasantly surprised at how many operational, relational = databases > actually do do this, with the primary key being system-chosen and a > seemingly arbitrary string that is hardly visible, with the keys that > the user uses being meaningful to users but always secondary. = Changing > the primary key is then straightforward. Right, I like the way how this is done in mongodb: System-chosen object = ids are attached to every new object by default, but the user can also = set them explicitly if there is a more natural scheme of ids. In NETCONF/YANG the primary key cannot be truly invisible because it = must always be present when selecting a list entry in . >=20 > But in the community of network and systems management, this almost > never happens. So I think that you are right, but I do not expect it = to > happen. I am a relatively unexperienced fellow, so I am still optimistic. :-) Thank you, Lada =20 >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Martin Bjorklund" > Cc: > Sent: Tuesday, September 11, 2012 9:58 AM > Subject: Re: [netmod] interface and ip >=20 >=20 >>=20 >> On Sep 11, 2012, at 10:45 AM, Martin Bjorklund = wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> Martin Bjorklund writes: >>>>=20 >>>>>>=20 >>>>>> If vendors can pick their own secret patterns for strings, then > they can >>>>>> also change them, right? So a name that works today in the > "standard" >>>>>> is in no way guaranteed to work in the future? I think the > current key >>>>>> for the interface list needs more work. >>>>>=20 >>>>> Even if the name is arbitrary, you will still have the problem > that >>>>> different devices have different hardware, and thus different >>>>> "locations". Again, making the name arbitrary doesn't solve > *this* >>>>> problem. >>>>=20 >>>> So how about doing three simple things: >>>>=20 >>>> 1. Add a new leaf "local-name", mandatory for physical interfaces. >>>>=20 >>>> IMO "type" and "location" is not enough, in particular on systems > that allow >>>> for changing the >>>> internal interface name, such as Linux. >>>=20 >>> Can you elaborate on why type + location is not sufficient? >>=20 >> What will the location leaf contain on Linux if the interface has the > local name "foo"? >>=20 >> If you use the "nameif" command to change the interface name, the new > name is really low-level, not just an alias for ethX, for example it > appears in /proc/sys/net/ipv4/conf/. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Sep 11 11:57:31 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 20DC621F84BF for ; Tue, 11 Sep 2012 11:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL7xtXBpRYkx for ; Tue, 11 Sep 2012 11:57:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 67BE721F84B9 for ; Tue, 11 Sep 2012 11:57:30 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 112F5140FC2; Tue, 11 Sep 2012 20:57:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347389849; bh=2zjeHaWMdBv09OAMxc/S/Z9AAGBq/KNVCRorc/72hmQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=grBrvtKLPeSvh+HxURrUuaaoXPLyM2HZ4XyrFHsRvhAmWfw7v53kTbhUo+lhMYwNd J2yQCHORVUhuhYonyhQuogcMS/Lv4zQWzQ8Zm20c1ClhbcB1o2tM399m2HgdqwJB81 WY8lWHk7iZc7Jb0J43pg5QKjOlF0J9tNU3X9z68w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <0lfw6oh4c0.fsf@wjh.hardakers.net> Date: Tue, 11 Sep 2012 20:57:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05717FE9-8374-4F12-8232-52B30045DBED@nic.cz> References: <0lfw6oh4c0.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] routing-cfg issues 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, 11 Sep 2012 18:57:31 -0000 On Sep 11, 2012, at 7:11 PM, Wes Hardaker wrote: > Ladislav Lhotka writes: >=20 >> 2.1. Implementations will supply the mandatory objects as entries of = a >> config=3Dtrue list but declare them read-only so that they cannot be >> deleted by the client. >>=20 >> 2.2. The mandatory entries will exist as state data, but outside the >> core data model. A client wanting to refer to them will have to >> explicitly configure a corresponding dummy entry in the config=3Dtrue >> list and refer to this entry. >=20 > ugh... This is where the whole "lets separate config and operational > state" kinda falls apart. If you want to keep that separation pure, > then when someone does a get-config dump so they can later re-upload = it > after rebuilding a system, you certainly don't want "direct" entries = in it > that will conflict because they don't match the new-device's internal > state. Thus, it seems to me they shouldn't be listed as config or = else > those scripted config-grabs will get confused. The *contents* of routing tables, i.e. routes, are always state data, = even in an explicitly configured table, so a get-config dump can only = contain a list of static routes but never any direct routes. =20 >=20 > But that doesn't feel right either. Sigh. >=20 >> 3.1. Really fix the main routing table name, i.e. make it a MUST. >>=20 >> 3.2. Introduce a new leaf node, e.g. "main-routing-table", pointing = to >> the main table. >>=20 >> 3.3. Add the "type" leaf under "routing-table" and use it for >> distinguishing the main routing table from the rest. >=20 > My preference order: 3.2, 3.1 then 3.3 OK. Thanks, Lada > --=20 > Wes Hardaker > SPARTA, Inc. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From randy_presuhn@mindspring.com Tue Sep 11 12:12:35 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 5F96721F84DF for ; Tue, 11 Sep 2012 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pggBGncYby0f for ; Tue, 11 Sep 2012 12:12:34 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2021F84DE for ; Tue, 11 Sep 2012 12:12:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rkoYCPZyc8sUlopQGau76eMzSj6H3Zuy0MNTYbfOKpe9Yugc13hxFNHTAzcA5zwA; 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.33.94.36] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TBVsv-0000q3-NH for netmod@ietf.org; Tue, 11 Sep 2012 15:12:34 -0400 Message-ID: <005701cd9052$608d3f80$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz><20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> Date: Tue, 11 Sep 2012 12:19:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f17a34792128a5481e8616b08e54dce06d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.94.36 Subject: Re: [netmod] interface and ip 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, 11 Sep 2012 19:12:35 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Ladislav Lhotka" > Cc: > Sent: Tuesday, September 11, 2012 2:42 AM > Subject: Re: [netmod] interface and ip ... > Now, supposed I > do that and I call my interface 'customer-foo'. What happens if I have > to change 'customer-foo' to 'customer-bar'? Now you prefer that the > key would have been the interface name, not its alias. In other words, > you seem to assume that freely choosen names are more stable and the > names assigned by the underlying operating system, no? I think this use case illustrates how there are really THREE distinct kinds of information involved: 1) the system-supplied "local" identifier for an interface 2) the administratively-assigned identifiers used to stitch stacks together 3) "Post-its" for things like "customer" or "cable-id" Randy From mbj@tail-f.com Tue Sep 11 13:19:10 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 0854721F86B2 for ; Tue, 11 Sep 2012 13:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x+alFUgmn8W for ; Tue, 11 Sep 2012 13:19:09 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 744D921F86A8 for ; Tue, 11 Sep 2012 13:19:09 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 130681200D79; Tue, 11 Sep 2012 22:19:08 +0200 (CEST) Date: Tue, 11 Sep 2012 22:19:07 +0200 (CEST) Message-Id: <20120911.221907.404688057.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <817D984D-7756-4F49-9797-4760BF818931@nic.cz> References: <20120911.164327.111194529.mbj@tail-f.com> <817D984D-7756-4F49-9797-4760BF818931@nic.cz> 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] interface and ip 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, 11 Sep 2012 20:19:10 -0000 Hi, Ladislav Lhotka wrote: > > On Sep 11, 2012, at 4:43 PM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Yes, except there must be a way for indicating the physical interface to > >> which > >> a given NETCONF interface entry belongs. > > > > Agreed. The idea was that the combination 'type' and 'location' would > > do this, where 'location' is defined as some string the device can use > > to identify the physical hardware. > > So let's take the example in appendix D of the interfaces-cfg draft, and > assume there is more configuration, IP addresses, VLANs etc. What is the > NETCONF client supposed to do after finding out that the operating system > swapped eth0 and eth1? I think a more stable identifier is needed for this to be useful. The client cannot be responsible for re-configuring the interfaces after a reboot (it might not even be possible to communicate with the device if interface identification changes...) This is true both with "location" or "local-name". How this is solved on linux is up to the vendor. If the device has 8 ethernet ports, the vendor can probably use a simple location 0 .. 7, and make sure this works, regardless of the order the kernel uses. I agree that arbitrary names are better - this is why the draft RECOMMEND implementations to support it. But at the same time, we must be realistic and realize that this data model must be implementable on popular platforms. /martin From lhotka@nic.cz Tue Sep 11 23:49: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 AB90821F8605 for ; Tue, 11 Sep 2012 23:49:58 -0700 (PDT) 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.161, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5KcfNqt9r+b for ; Tue, 11 Sep 2012 23:49:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA42121F85C0 for ; Tue, 11 Sep 2012 23:49:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id EEC0F540558 for ; Wed, 12 Sep 2012 08:49:54 +0200 (CEST) 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 ZvYZg6JNwCRn for ; Wed, 12 Sep 2012 08:49:51 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EE3B45404F5 for ; Wed, 12 Sep 2012 08:49:50 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <005701cd9052$608d3f80$6b01a8c0@oemcomputer> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <005701cd9052$608d3f80$6b01a8c0@oemcomputer> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 12 Sep 2012 08:49:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface and ip 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, 12 Sep 2012 06:49:58 -0000 Randy Presuhn writes: > Hi - > >> From: "Juergen Schoenwaelder" >> To: "Ladislav Lhotka" >> Cc: >> Sent: Tuesday, September 11, 2012 2:42 AM >> Subject: Re: [netmod] interface and ip > ... >> Now, supposed I >> do that and I call my interface 'customer-foo'. What happens if I have >> to change 'customer-foo' to 'customer-bar'? Now you prefer that the >> key would have been the interface name, not its alias. In other words, >> you seem to assume that freely choosen names are more stable and the >> names assigned by the underlying operating system, no? > > I think this use case illustrates how there are really THREE distinct > kinds of information involved: > 1) the system-supplied "local" identifier for an interface > 2) the administratively-assigned identifiers used to stitch stacks together Right, that's the point. Our discussion is also complicated by the fact that some systems allow the local identifier to be arbitrary while others impose a precise format. So the draft/module should clarify whether the data model really treats 1 and 2 as independent identifiers, i.e. whether the "name" key has to be equal to the local name or not. > 3) "Post-its" for things like "customer" or "cable-id" Could the "description" leaf be used for this purpose? Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Sep 12 00:18: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 8D06C21F850D for ; Wed, 12 Sep 2012 00:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHTwZXWvb67A for ; Wed, 12 Sep 2012 00:18:18 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F06D321F8504 for ; Wed, 12 Sep 2012 00:18:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 76E1A540558; Wed, 12 Sep 2012 09:18:16 +0200 (CEST) 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 hB7CC1zwKC84; Wed, 12 Sep 2012 09:18:12 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 12AC15401C6; Wed, 12 Sep 2012 09:18:11 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20120911.221907.404688057.mbj@tail-f.com> References: <20120911.164327.111194529.mbj@tail-f.com> <817D984D-7756-4F49-9797-4760BF818931@nic.cz> <20120911.221907.404688057.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Wed, 12 Sep 2012 09:18:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 12 Sep 2012 07:18:18 -0000 Martin Bjorklund writes: > Hi, > > Ladislav Lhotka wrote: >> >> On Sep 11, 2012, at 4:43 PM, Martin Bjorklund wrote: >> >> > Ladislav Lhotka wrote: >> >> Yes, except there must be a way for indicating the physical interface to >> >> which >> >> a given NETCONF interface entry belongs. >> > >> > Agreed. The idea was that the combination 'type' and 'location' would >> > do this, where 'location' is defined as some string the device can use >> > to identify the physical hardware. >> >> So let's take the example in appendix D of the interfaces-cfg draft, and >> assume there is more configuration, IP addresses, VLANs etc. What is the >> NETCONF client supposed to do after finding out that the operating system >> swapped eth0 and eth1? > > I think a more stable identifier is needed for this to be useful. The > client cannot be responsible for re-configuring the interfaces after a > reboot (it might not even be possible to communicate with the device > if interface identification changes...) This is true both with > "location" or "local-name". Even if the local identifier is more stable: Let's say the name is "Ethernet0/1", type is the weird string representing Ethernet, and location is "0/1". Then the line card gets replaced (hot swap) and the same cable is now connected to "Ethernet0/0/1". My question is whether it is allowed to keep the old name "Ethernet0/1" as the key of that entry and only change location to "0/0/1". > > How this is solved on linux is up to the vendor. If the device has 8 > ethernet ports, the vendor can probably use a simple location 0 .. 7, > and make sure this works, regardless of the order the kernel uses. > > I agree that arbitrary names are better - this is why the draft > RECOMMEND implementations to support it. But at the same time, we This is not what I read in -06. It says: A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. > must be realistic and realize that this data model must be > implementable on popular platforms. But again: I propose the "name" key to be of the second type in Randy's classification, i.e. 2) the administratively-assigned identifiers used to stitch stacks together So this key is used for internal purposes within the NETCONF system, and it is irrelevant whether the platform restricts the form of its local interface identifiers or not. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Sep 12 00:37:10 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 C238021F85C7 for ; Wed, 12 Sep 2012 00:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpGmL3u9A-vt for ; Wed, 12 Sep 2012 00:37:10 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 31D0921F85C0 for ; Wed, 12 Sep 2012 00:37:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2684E1200D0F; Wed, 12 Sep 2012 09:37:08 +0200 (CEST) Date: Wed, 12 Sep 2012 09:37:07 +0200 (CEST) Message-Id: <20120912.093707.2093349578205712199.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <817D984D-7756-4F49-9797-4760BF818931@nic.cz> <20120911.221907.404688057.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interface and ip 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, 12 Sep 2012 07:37:10 -0000 Hi, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > Ladislav Lhotka wrote: > >> > >> On Sep 11, 2012, at 4:43 PM, Martin Bjorklund wrote: > >> > >> > Ladislav Lhotka wrote: > >> >> Yes, except there must be a way for indicating the physical interface > >> >> to > >> >> which > >> >> a given NETCONF interface entry belongs. > >> > > >> > Agreed. The idea was that the combination 'type' and 'location' would > >> > do this, where 'location' is defined as some string the device can use > >> > to identify the physical hardware. > >> > >> So let's take the example in appendix D of the interfaces-cfg draft, > >> and > >> assume there is more configuration, IP addresses, VLANs etc. What is > >> the > >> NETCONF client supposed to do after finding out that the operating > >> system > >> swapped eth0 and eth1? > > > > I think a more stable identifier is needed for this to be useful. The > > client cannot be responsible for re-configuring the interfaces after a > > reboot (it might not even be possible to communicate with the device > > if interface identification changes...) This is true both with > > "location" or "local-name". > > Even if the local identifier is more stable: Let's say the name is > "Ethernet0/1", type is the weird string representing Ethernet, and > location is "0/1". Then the line card gets replaced (hot swap) and the > same cable is now connected to "Ethernet0/0/1". My question is whether > it is allowed to keep the old name "Ethernet0/1" as the key of that > entry and only change location to "0/0/1". With the current model, it depends on the implementation. > > How this is solved on linux is up to the vendor. If the device has 8 > > ethernet ports, the vendor can probably use a simple location 0 .. 7, > > and make sure this works, regardless of the order the kernel uses. > > > > I agree that arbitrary names are better - this is why the draft > > RECOMMEND implementations to support it. But at the same time, we > > This is not what I read in -06. It says: > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. Ok, so this should be clarified. /martin From andrewmcgr@gmail.com Wed Sep 12 00:40: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 BAAAF21F862A for ; Wed, 12 Sep 2012 00:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGQ51XCcF9VX for ; Wed, 12 Sep 2012 00:40:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1918B21F8627 for ; Wed, 12 Sep 2012 00:40:54 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2407576obb.31 for ; Wed, 12 Sep 2012 00:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=1TevOUes5h3rBA1yfeBaVW6PO7d4X3Y9BGtOfOkVNWY=; b=MzkaDhx/ojZHwNFpc/BHspmnoCwdrCzv9YDMcbnp0srOfzOUOnEyr0FnRM01DQ965P XdiM6t9j4l7xc1wxZXBmc1YF/rugmiDxH8AJgXHVrNiVJDfLGZOGzxG/7e42LOltbftM Oo/Xo7vQyHIonavgGhLIOKrX2RKYoLFVqkPwrgLunSefS12smsZ8akRs3WGELQ3CErZw RJyFAGJqY+WdcPH+V7Cp/hNMG5okuKIlS2A6Ghz4uH7NyK4kn11IzL0VgsRY0juxwxeJ mqdia8/O+Ae1CnnBu9GikvxKzDQB+EJZsHnLdyKwSa/X2/VFMRjFIDCxGUO65pSw3V40 lJsg== Received: by 10.182.154.70 with SMTP id vm6mr21458785obb.50.1347435653494; Wed, 12 Sep 2012 00:40:53 -0700 (PDT) Received: from andrewm-lo.lan (63.239.69.111.dynamic.snap.net.nz. [111.69.239.63]) by mx.google.com with ESMTPS id j10sm15485144oej.10.2012.09.12.00.40.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2012 00:40:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_322223C3-5DC2-4D2D-8937-633AFDBB0225"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Andrew McGregor In-Reply-To: Date: Wed, 12 Sep 2012 19:40:43 +1200 Message-Id: References: <20120911.164327.111194529.mbj@tail-f.com> <817D984D-7756-4F49-9797-4760BF818931@nic.cz> <20120911.221907.404688057.mbj@tail-f.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1486) Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 12 Sep 2012 07:40:54 -0000 --Apple-Mail=_322223C3-5DC2-4D2D-8937-633AFDBB0225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12/09/2012, at 7:18 PM, Ladislav Lhotka wrote: > Martin Bjorklund writes: >>=20 >> I think a more stable identifier is needed for this to be useful. = The >> client cannot be responsible for re-configuring the interfaces after = a >> reboot (it might not even be possible to communicate with the device >> if interface identification changes...) This is true both with >> "location" or "local-name". >=20 > Even if the local identifier is more stable: Let's say the name is = "Ethernet0/1", type is the weird string representing Ethernet, and = location is "0/1". Then the line card gets replaced (hot swap) and the = same cable is now connected to "Ethernet0/0/1". My question is whether = it is allowed to keep the old name "Ethernet0/1" as the key of that = entry and only change location to "0/0/1". Most router and switch vendors seem to have solved this by always using = a stable format on a given platform, in our case it's a triple of unit = number, slot number, port number. So if the port name changed, that's = because the cable is in a different port by definition; if it's the same = port in any useful sense, it has the same canonical name. >=20 >=20 >> must be realistic and realize that this data model must be >> implementable on popular platforms. >=20 > But again: I propose the "name" key to be of the second type in = Randy's classification, i.e. >=20 > 2) the administratively-assigned identifiers used to stitch stacks = together >=20 > So this key is used for internal purposes within the NETCONF system, = and it is irrelevant whether the platform restricts the form of its = local interface identifiers or not. >=20 On linux, the stable identifiers are of one of the forms you can key off = under the udev system, for example: # PCI device 0x14e4:/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0 = (tg3) SUBSYSTEM=3D=3D"net", ACTION=3D=3D"add", DRIVERS=3D=3D"?*", = ATTR{address}=3D=3D"00:15:77:df:e6:01", ATTR{dev_id}=3D=3D"0x0", = ATTR{type}=3D=3D"1", KERNEL=3D=3D"eth*", NAME=3D"eth1" which is an extract from /etc/udev/rules.d/70-persistent-net.rules on my = work machine. In this case, it's configured to say that the device with MAC address = 00:15:77:df:e6:01 is known as "eth1", but you could equally say the = device in the slot at pci0000:00/0000:00:01.1/0000:02:00.0 could be = "eth1". Udev is unfortunate for this discussion, because it is = extremely configurable in terms of name mapping. In any case, netconf should be able to express something like the udev = situation, but it might be necessary to identify the configuration = entity by a UDID or something similar, that could be returned as a udev = attribute along with the name. Andrew= --Apple-Mail=_322223C3-5DC2-4D2D-8937-633AFDBB0225 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTIwNzQwNDRaMCMGCSqGSIb3DQEJBDEWBBR4FwPJ GP/bm2wPck6J6lArUroo2zCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAGZ1PbgWzYK3fsatl0FSclhujcG3HRURKuYGXNGS1LnqE42MnLRxV/C3 O0XUaQJCghDea8blbUXkNr6BJwwGURq2aeTvGX9jjcLFB7SSyL/4Zl5OnpU0PAr4NSL+r3Jh1x7x 4lQkDORc4Ffe75Ujm+YgSOP0XNjfT9qXLpoHpAjfLPgrF6N6/BQn8CKOSyXPjmDYkqwXdMwo6ldk cnSXDEmDkgO+A5+E3qgj0ZA9AaG7tczeuRT/khvz2cUbmJxeimxVq8QU65Tvq6CQttHlhKIv2RdW YGxtQPjvUaAwyi7LwahGb/PwIrVw/FNDhPoIbYg9lG3u1qDn5vYMWSmrLuwAAAAAAAA= --Apple-Mail=_322223C3-5DC2-4D2D-8937-633AFDBB0225-- From lhotka@nic.cz Wed Sep 12 01:18: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 BBDD721F84B2 for ; Wed, 12 Sep 2012 01:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLjmygdAHtWe for ; Wed, 12 Sep 2012 01:18:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C493721F84B5 for ; Wed, 12 Sep 2012 01:18:00 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 03B45140072; Wed, 12 Sep 2012 10:17:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347437879; bh=srNmRaxdm7S42C0aL92U0sD2EfZTnTk5iT4B1iCrcXc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Zj08NVnY8A/2cpyGPFJgcmLYqPXbKOpNLFDbUb8tpT7VWOo2NcKyt9wkHNVJpHll+ wOvqQKgw0dKZdg9YZOQ5XHAGq2fkuPdLya0uNBGn9tQNIE8fMsC0RWVcLu0+saortr Jw1Lyw6DdKjd440YaSE6GQhsN6bX1XJN0YMzE6nA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120912.093707.2093349578205712199.mbj@tail-f.com> Date: Wed, 12 Sep 2012 10:17:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <757EE186-4757-4622-9EFE-B24A68F50DD8@nic.cz> References: <817D984D-7756-4F49-9797-4760BF818931@nic.cz> <20120911.221907.404688057.mbj@tail-f.com> <20120912.093707.2093349578205712199.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 12 Sep 2012 08:18:03 -0000 On Sep 12, 2012, at 9:37 AM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Hi, >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On Sep 11, 2012, at 4:43 PM, Martin Bjorklund = wrote: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> Yes, except there must be a way for indicating the physical = interface >>>>>> to >>>>>> which >>>>>> a given NETCONF interface entry belongs. >>>>>=20 >>>>> Agreed. The idea was that the combination 'type' and 'location' = would >>>>> do this, where 'location' is defined as some string the device can = use >>>>> to identify the physical hardware. >>>>=20 >>>> So let's take the example in appendix D of the interfaces-cfg = draft, >>>> and >>>> assume there is more configuration, IP addresses, VLANs etc. What = is >>>> the >>>> NETCONF client supposed to do after finding out that the operating >>>> system >>>> swapped eth0 and eth1? >>>=20 >>> I think a more stable identifier is needed for this to be useful. = The >>> client cannot be responsible for re-configuring the interfaces after = a >>> reboot (it might not even be possible to communicate with the device >>> if interface identification changes...) This is true both with >>> "location" or "local-name". >>=20 >> Even if the local identifier is more stable: Let's say the name is >> "Ethernet0/1", type is the weird string representing Ethernet, and >> location is "0/1". Then the line card gets replaced (hot swap) and = the >> same cable is now connected to "Ethernet0/0/1". My question is = whether >> it is allowed to keep the old name "Ethernet0/1" as the key of that >> entry and only change location to "0/0/1". >=20 > With the current model, it depends on the implementation. Then people will start writing client applications that rely on "name" = being the same as the local identifier and interoperability will be = gone. I agree with Andy that the standard should be strict in this = respect. >=20 >>> How this is solved on linux is up to the vendor. If the device has = 8 >>> ethernet ports, the vendor can probably use a simple location 0 .. = 7, >>> and make sure this works, regardless of the order the kernel uses. >>>=20 >>> I agree that arbitrary names are better - this is why the draft >>> RECOMMEND implementations to support it. But at the same time, we >>=20 >> This is not what I read in -06. It says: >>=20 >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >=20 > Ok, so this should be clarified. Maybe the MIB mapping should also be reconsidered, because according to = RFC 2863 "ifName" is the local name that is used on the device console. Lada =20 >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Sep 13 23:51: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 6E80021F85DA for ; Thu, 13 Sep 2012 23:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsdGcutMsCBh for ; Thu, 13 Sep 2012 23:51:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E15E221F85A0 for ; Thu, 13 Sep 2012 23:51:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33C5D20CA5; Fri, 14 Sep 2012 08:51:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UFWzzP-4WjKG; Fri, 14 Sep 2012 08:51:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D9A320CA4; Fri, 14 Sep 2012 08:51:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 04C6E21C4B28; Fri, 14 Sep 2012 08:50:54 +0200 (CEST) Date: Fri, 14 Sep 2012 08:50:54 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20120914065054.GB12446@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <005701cd9052$608d3f80$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701cd9052$608d3f80$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 14 Sep 2012 06:51:11 -0000 On Tue, Sep 11, 2012 at 12:19:32PM -0700, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Ladislav Lhotka" > > Cc: > > Sent: Tuesday, September 11, 2012 2:42 AM > > Subject: Re: [netmod] interface and ip > ... > > Now, supposed I > > do that and I call my interface 'customer-foo'. What happens if I have > > to change 'customer-foo' to 'customer-bar'? Now you prefer that the > > key would have been the interface name, not its alias. In other words, > > you seem to assume that freely choosen names are more stable and the > > names assigned by the underlying operating system, no? > > I think this use case illustrates how there are really THREE distinct > kinds of information involved: > 1) the system-supplied "local" identifier for an interface > 2) the administratively-assigned identifiers used to stitch stacks together > 3) "Post-its" for things like "customer" or "cable-id" There are also different aspects of change: a) Lada's problem seems to be that on a certain platform, the system supplied "local" identifier can change with a kernel upgrade. It seems some network device vendors have solved that problem by using identifiers / kernels that do not have this "bug/feature", e.g. by making sure kernels follow the same device driver initialization order or by naming interfaces according to a location. b) There is the old hotplug discussion of what it means to move one linecard from one slot to another. Depending on why you move the line card, you either want the configuration of that card to change or you want the config of the card to move with the card. c) There is the option to use purely administratively assigned keys for config snippets. Once we support this, I am sure we will see that people will encode semantics into these identifiers and hence there will be changes due to whatever encoded semantic got encoded. Unless we make NETCONF generate purely semantic free keys (numbers, uuids), we will end up with keys that once in a while require changes and then the discussion boils down to how likely this is for the various naming systems proposed. We will likely not find agreement on an answer to this question. Operationally, it seems that the system-level notion of interface names is very widely used in management interfaces and beyond (e.g. as part of zone indexes for link-local IPv6 addresses or to specify scopes in IP multicast communication). /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 Sep 14 02:28: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 3C0DF21F8518 for ; Fri, 14 Sep 2012 02:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W59DN8zJVIrO for ; Fri, 14 Sep 2012 02:28:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFBB21F84FC for ; Fri, 14 Sep 2012 02:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6976C5403F0; Fri, 14 Sep 2012 11:27:59 +0200 (CEST) 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 7xKMtYqrUzPZ; Fri, 14 Sep 2012 11:27:52 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 514F954013B; Fri, 14 Sep 2012 11:27:50 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Randy Presuhn In-Reply-To: <20120914065054.GB12446@elstar.local> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <005701cd9052$608d3f80$6b01a8c0@oemcomputer> <20120914065054.GB12446@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Juergen Schoenwaelder , Randy Presuhn , netmod@ietf.org Date: Fri, 14 Sep 2012 11:27:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 14 Sep 2012 09:28:02 -0000 Juergen Schoenwaelder writes: > On Tue, Sep 11, 2012 at 12:19:32PM -0700, Randy Presuhn wrote: >> Hi - >> >> > From: "Juergen Schoenwaelder" >> > To: "Ladislav Lhotka" >> > Cc: >> > Sent: Tuesday, September 11, 2012 2:42 AM >> > Subject: Re: [netmod] interface and ip >> ... >> > Now, supposed I >> > do that and I call my interface 'customer-foo'. What happens if I have >> > to change 'customer-foo' to 'customer-bar'? Now you prefer that the >> > key would have been the interface name, not its alias. In other words, >> > you seem to assume that freely choosen names are more stable and the >> > names assigned by the underlying operating system, no? >> >> I think this use case illustrates how there are really THREE distinct >> kinds of information involved: >> 1) the system-supplied "local" identifier for an interface >> 2) the administratively-assigned identifiers used to stitch stacks together >> 3) "Post-its" for things like "customer" or "cable-id" > > There are also different aspects of change: > > a) Lada's problem seems to be that on a certain platform, the system > supplied "local" identifier can change with a kernel upgrade. It > seems some network device vendors have solved that problem by using > identifiers / kernels that do not have this "bug/feature", e.g. by > making sure kernels follow the same device driver initialization > order or by naming interfaces according to a location. In my (not very recent) experience, the situation where one needs to migrate an entire stack to a different interface happens on all platforms - hardware upgrades, port failures etc. > > b) There is the old hotplug discussion of what it means to move one > linecard from one slot to another. Depending on why you move the > line card, you either want the configuration of that card to change > or you want the config of the card to move with the card. > > c) There is the option to use purely administratively assigned keys > for config snippets. Once we support this, I am sure we will see > that people will encode semantics into these identifiers and hence > there will be changes due to whatever encoded semantic got encoded. On the other hand, such keys would enable publishing config snippets that can be used on various platforms, without the drudgery of changing interface names and all references to them. > > Unless we make NETCONF generate purely semantic free keys (numbers, > uuids), we will end up with keys that once in a while require changes > and then the discussion boils down to how likely this is for the > various naming systems proposed. We will likely not find agreement on > an answer to this question. IMO, a user-friendly server could assign opaque keys automatically by default, but also allow the client to assign them manually. > > Operationally, it seems that the system-level notion of interface > names is very widely used in management interfaces and beyond (e.g. > as part of zone indexes for link-local IPv6 addresses or to specify > scopes in IP multicast communication). In general, configurations are mostly dealt with in a very platform-specific context, even independent authors of technical books usually select one or at most two platforms for showing configuration examples. 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 Sep 14 03:17: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 A4D7021F853E for ; Fri, 14 Sep 2012 03:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yP5Rljg2AYF for ; Fri, 14 Sep 2012 03:17:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0E121F853C for ; Fri, 14 Sep 2012 03:17:51 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2ECF720CE3; Fri, 14 Sep 2012 12:17:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kD7IILx_nozk; Fri, 14 Sep 2012 12:17:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EA9520CDE; Fri, 14 Sep 2012 12:17:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6526B21C52C7; Fri, 14 Sep 2012 12:17:44 +0200 (CEST) Date: Fri, 14 Sep 2012 12:17:44 +0200 From: Juergen Schoenwaelder To: Randy Presuhn , netmod@ietf.org Message-ID: <20120914101744.GB12937@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <005701cd9052$608d3f80$6b01a8c0@oemcomputer> <20120914065054.GB12446@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) Subject: Re: [netmod] interface and ip 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, 14 Sep 2012 10:17:52 -0000 On Fri, Sep 14, 2012 at 11:27:52AM +0200, Ladislav Lhotka wrote: > > Unless we make NETCONF generate purely semantic free keys (numbers, > > uuids), we will end up with keys that once in a while require changes > > and then the discussion boils down to how likely this is for the > > various naming systems proposed. We will likely not find agreement on > > an answer to this question. > > IMO, a user-friendly server could assign opaque keys automatically by default, but also allow the client to assign them manually. > NETCONF does not assign opaque keys automatically if you create new list instances so for us this is completely out of scope. > > Operationally, it seems that the system-level notion of interface > > names is very widely used in management interfaces and beyond (e.g. > > as part of zone indexes for link-local IPv6 addresses or to specify > > scopes in IP multicast communication). > > In general, configurations are mostly dealt with in a very platform-specific context, even independent authors of technical books usually select one or at most two platforms for showing configuration examples. > Operators need to be able to easily cross-correlate things. What is "easy" is surely subjective. But we need to get back to concrete proposals, otherwise this discussion becomes unproductive. I think we have: a) What is currently in draft-ietf-netmod-interfaces-cfg-06. Supports implementations using opaque interface names as well as implementations using system-level interface names. b) The change you suggested in http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html essentially removing interface name restrictions (systems that choose to still have them would either declare a deviation or cheat) c) The option of having a generic 'rename' extension for NETCONF along the lines of Phil's email http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html This clearly is outside the scope of our charter, we would simply assume that at some point in time there will be a generic way of renaming things. d) Not explicitely proposed but mentioned in some emails is the option to have a 'rename-interface' RPC that renames interface config plus all leafrefs pointing to the old name. A special purpose version of c) which we could do now. Am I missing anything? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Sep 14 03:32: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 F18CE21F859E for ; Fri, 14 Sep 2012 03:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oSb4tyX-6Th for ; Fri, 14 Sep 2012 03:32:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE3821F8587 for ; Fri, 14 Sep 2012 03:32:03 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 612D91200D0F; Fri, 14 Sep 2012 12:32:02 +0200 (CEST) Date: Fri, 14 Sep 2012 12:32:01 +0200 (CEST) Message-Id: <20120914.123201.171095060.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120914101744.GB12937@elstar.local> References: <20120914065054.GB12446@elstar.local> <20120914101744.GB12937@elstar.local> X-Mailer: Mew version 6.4 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] interface and ip 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, 14 Sep 2012 10:32:05 -0000 Hi, Juergen Schoenwaelder wrote: > But we need to get back to concrete > proposals, otherwise this discussion becomes unproductive. I think we > have: > > a) What is currently in draft-ietf-netmod-interfaces-cfg-06. Supports > implementations using opaque interface names as well as > implementations using system-level interface names. > > b) The change you suggested in > > http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html > > essentially removing interface name restrictions (systems that > choose to still have them would either declare a deviation or > cheat) Right. These are exclusive; we have to pick one of them. (In the cited msg Lada proposed 'local-name', but I don't think that is necessary). > c) The option of having a generic 'rename' extension for NETCONF along > the lines of Phil's email > > http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html > > This clearly is outside the scope of our charter, we would simply > assume that at some point in time there will be a generic way of > renaming things. Agreed. > d) Not explicitely proposed but mentioned in some emails is the option > to have a 'rename-interface' RPC that renames interface config plus > all leafrefs pointing to the old name. A special purpose version of > c) which we could do now. I think that if it is important to rename things, we should probably look into a more generic mechanism. So, I prefer (a) over (b); (c) is already out-of-scope, and I do not think we should do (d). /martin From andy@yumaworks.com Fri Sep 14 07:53:23 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 EB22021F84FA for ; Fri, 14 Sep 2012 07:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk8s9K6U7inR for ; Fri, 14 Sep 2012 07:53:23 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4221F8499 for ; Fri, 14 Sep 2012 07:53:23 -0700 (PDT) Received: by qadz3 with SMTP id z3so3155678qad.10 for ; Fri, 14 Sep 2012 07:53:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=+hD8jNYv7RFLC8mFjK5Zcf0FINUL22vkPOXiu/ylRY8=; b=T5MEoCFTOlSnHnPvivXnymErKQf50jpffHhvrC7JDiq87kzRkJoKLM8Jg9u71WhAaA uUlfNINDfmJ+4V/mtg1Td12sm60PoX8c2HnalL2gJKdDijjt1nPrGnlg9ITzWsvAOIup j/lwj3z4VqwmZQly9hdXq1/3dYduGLaug1h1Q/DxkPnTfRLxzUskoRrb5VxS5diXUzhz 92y4j0Gy1jBhl9R1Qh8ilVdg0U3WTm0wCJTkPecXDGaOmsLp8CvHoT560E/jbVIQStkw 5kKywcqd6jUvQpRv82xXCENXBNrlxDs+XrPRQ+AXCyaVjmxNz9uBYHeBBTh8oxiFIiX0 eOqw== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr7978567qaf.2.1347634402628; Fri, 14 Sep 2012 07:53:22 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Fri, 14 Sep 2012 07:53:22 -0700 (PDT) In-Reply-To: <20120914101744.GB12937@elstar.local> References: <36531B4B-E76B-4C6C-A05B-1ADC1234CCA1@nic.cz> <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <005701cd9052$608d3f80$6b01a8c0@oemcomputer> <20120914065054.GB12446@elstar.local> <20120914101744.GB12937@elstar.local> Date: Fri, 14 Sep 2012 07:53:22 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Randy Presuhn , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmIzBlhVsngfrLmL8RpOiUOgLAZUrEVSP5+4PtKtObU6bJganM0uOJ/aAh0oqB653tamoP7 Subject: Re: [netmod] interface and ip 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, 14 Sep 2012 14:53:24 -0000 On Fri, Sep 14, 2012 at 3:17 AM, Juergen Schoenwaelder wrote: > On Fri, Sep 14, 2012 at 11:27:52AM +0200, Ladislav Lhotka wrote: > >> > Unless we make NETCONF generate purely semantic free keys (numbers, >> > uuids), we will end up with keys that once in a while require changes >> > and then the discussion boils down to how likely this is for the >> > various naming systems proposed. We will likely not find agreement on >> > an answer to this question. >> >> IMO, a user-friendly server could assign opaque keys automatically by default, but also allow the client to assign them manually. >> > > NETCONF does not assign opaque keys automatically if you create new > list instances so for us this is completely out of scope. > Maybe cannot return the new resource ID, but could easily do so. Andy From j.schoenwaelder@jacobs-university.de Fri Sep 14 08:03:38 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 6F82721F8523 for ; Fri, 14 Sep 2012 08:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-6WMs89-9PG for ; Fri, 14 Sep 2012 08:03:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0021F8514 for ; Fri, 14 Sep 2012 08:03:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D134920CA3; Fri, 14 Sep 2012 17:03:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Tu3K5z-IBfz4; Fri, 14 Sep 2012 17:03:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4572C20C87; Fri, 14 Sep 2012 17:03:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16CE921C5AC2; Fri, 14 Sep 2012 17:03:29 +0200 (CEST) Date: Fri, 14 Sep 2012 17:03:29 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120914150329.GB13377@elstar.local> Mail-Followup-To: Andy Bierman , Randy Presuhn , netmod@ietf.org References: <20120910.220655.433664319.mbj@tail-f.com> <20120911090019.GA69384@elstar.local> <20120911094233.GA69531@elstar.local> <005701cd9052$608d3f80$6b01a8c0@oemcomputer> <20120914065054.GB12446@elstar.local> <20120914101744.GB12937@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] interface and ip 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, 14 Sep 2012 15:03:38 -0000 On Fri, Sep 14, 2012 at 07:53:22AM -0700, Andy Bierman wrote: > On Fri, Sep 14, 2012 at 3:17 AM, Juergen Schoenwaelder > wrote: > > On Fri, Sep 14, 2012 at 11:27:52AM +0200, Ladislav Lhotka wrote: > > > >> > Unless we make NETCONF generate purely semantic free keys (numbers, > >> > uuids), we will end up with keys that once in a while require changes > >> > and then the discussion boils down to how likely this is for the > >> > various naming systems proposed. We will likely not find agreement on > >> > an answer to this question. > >> > >> IMO, a user-friendly server could assign opaque keys automatically by default, but also allow the client to assign them manually. > >> > > > > NETCONF does not assign opaque keys automatically if you create new > > list instances so for us this is completely out of scope. > > > > Maybe cannot return the new resource ID, > but could easily do so. > Yes, so we have another option, that is introducing a create-interface RPC that returns suitable opaque keys. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Sep 14 08:12:01 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 3544621F8514 for ; Fri, 14 Sep 2012 08:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYsnljkMHXyf for ; Fri, 14 Sep 2012 08:12:00 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A867721F84F9 for ; Fri, 14 Sep 2012 08:12:00 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 405AD1200D0F; Fri, 14 Sep 2012 17:11:59 +0200 (CEST) Date: Fri, 14 Sep 2012 17:11:59 +0200 (CEST) Message-Id: <20120914.171159.67776539.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120914150329.GB13377@elstar.local> References: <20120914101744.GB12937@elstar.local> <20120914150329.GB13377@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] interface and ip 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, 14 Sep 2012 15:12:01 -0000 Juergen Schoenwaelder wrote: > On Fri, Sep 14, 2012 at 07:53:22AM -0700, Andy Bierman wrote: > > On Fri, Sep 14, 2012 at 3:17 AM, Juergen Schoenwaelder > > wrote: > > > On Fri, Sep 14, 2012 at 11:27:52AM +0200, Ladislav Lhotka wrote: > > > > > >> > Unless we make NETCONF generate purely semantic free keys (numbers, > > >> > uuids), we will end up with keys that once in a while require changes > > >> > and then the discussion boils down to how likely this is for the > > >> > various naming systems proposed. We will likely not find agreement on > > >> > an answer to this question. > > >> > > >> IMO, a user-friendly server could assign opaque keys automatically by > > >> default, but also allow the client to assign them manually. > > >> > > > > > > NETCONF does not assign opaque keys automatically if you create new > > > list instances so for us this is completely out of scope. > > > > > > > Maybe cannot return the new resource ID, > > but could easily do so. > > > > Yes, so we have another option, that is introducing a create-interface > RPC that returns suitable opaque keys. This would be a really bad idea. The fact that we have data models and generic edit-config / get-config is what makes NETCONF so much better for automation than rpc based solutions like soap or rest or corba etc. /martin From lhotka@nic.cz Sun Sep 16 22:00:25 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 7A97C21F84B6 for ; Sun, 16 Sep 2012 22:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V5INnYi4wnO for ; Sun, 16 Sep 2012 22:00:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA8421F84B2 for ; Sun, 16 Sep 2012 22:00:23 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E727713F678; Mon, 17 Sep 2012 07:00:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1347858022; bh=0W1f3TjptO8Jvro45GQT8O4OCl14+lFmN/xLz0KqWOk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XVtG9Rc3VeGbbkUsZPYQPesHpr3XGiEwjJkkl3bSwHXg5viPJlzEdmgnDiJAQUc54 CNiIF5Cj30/nHFDlf3ie0EDVRYV1CAtttyv7NYoKR7KR3WCqGbJnDB3wCeypkWElBs 4MXLrTEr0AhzI2vz3G93qYVX3Le2aJ9H5HzzJRJk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120914.123201.171095060.mbj@tail-f.com> Date: Mon, 17 Sep 2012 07:00:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1BFC4507-1C33-44EE-A264-DB47574A3C9D@nic.cz> References: <20120914065054.GB12446@elstar.local> <20120914101744.GB12937@elstar.local> <20120914.123201.171095060.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface and ip 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, 17 Sep 2012 05:00:25 -0000 On Sep 14, 2012, at 12:32 PM, Martin Bjorklund wrote: > Hi, >=20 > Juergen Schoenwaelder wrote: >> But we need to get back to concrete >> proposals, otherwise this discussion becomes unproductive. I think we >> have: >>=20 >> a) What is currently in draft-ietf-netmod-interfaces-cfg-06. Supports >> implementations using opaque interface names as well as >> implementations using system-level interface names. >>=20 >> b) The change you suggested in=20 >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html >>=20 >> essentially removing interface name restrictions (systems that >> choose to still have them would either declare a deviation or >> cheat) >=20 > Right. These are exclusive; we have to pick one of them. >=20 > (In the cited msg Lada proposed 'local-name', but I don't think that > is necessary). I would still prefer to be able to see the the native interface name. = Would it be a problem to have 'local-name' as an optional leaf? Lada >=20 >> c) The option of having a generic 'rename' extension for NETCONF = along >> the lines of Phil's email >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html >>=20 >> This clearly is outside the scope of our charter, we would simply >> assume that at some point in time there will be a generic way of >> renaming things. >=20 > Agreed. >=20 >> d) Not explicitely proposed but mentioned in some emails is the = option >> to have a 'rename-interface' RPC that renames interface config plus >> all leafrefs pointing to the old name. A special purpose version of >> c) which we could do now. >=20 > I think that if it is important to rename things, we should probably > look into a more generic mechanism. >=20 >=20 > So, I prefer (a) over (b); (c) is already out-of-scope, and I do not > think we should do (d). >=20 >=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 wwwrun@rfc-editor.org Mon Sep 17 09:21:10 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 E22C821F869A for ; Mon, 17 Sep 2012 09:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-y02YjsTPMP for ; Mon, 17 Sep 2012 09:21:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 75D8A21F8539 for ; Mon, 17 Sep 2012 09:21:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 17AE1B1E003; Mon, 17 Sep 2012 09:17:42 -0700 (PDT) To: phil@juniper.net, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20120917161742.17AE1B1E003@rfc-editor.org> Date: Mon, 17 Sep 2012 09:17:42 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Editorial Errata Reported] RFC6244 (3356) 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, 17 Sep 2012 16:21:11 -0000 The following errata report has been submitted for RFC6244, "An Architecture for Network Management Using NETCONF and YANG". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6244&eid=3356 -------------------------------------- Type: Editorial Reported by: Benoit Claise Section: 2.2.3 Original Text ------------- augment /ospf:ospf/ospf:area/ospf:interfaces { leaf no-neighbor-down-notification { type empty; description "Don't inform other protocols about" + " neighbor down events"; Corrected Text -------------- augment /ospf:ospf/ospf:area/ospf:interface { leaf no-neighbor-down-notification { type empty; description "Don't inform other protocols about" + " neighbor down events"; Notes ----- Section 2.2.3 For example, if the above OSPF configuration were the standard, a vendor module may augment this with vendor-specific extensions. module vendorx-ospf { namespace "http://vendorx.example.com/ospf"; prefix vendorx; import example-ospf { prefix ospf; } augment /ospf:ospf/ospf:area/ospf:interfaces { leaf no-neighbor-down-notification { type empty; description "Don't inform other protocols about" + " neighbor down events"; } } } While the "above OSPF configuration" refers to interface and not interfaces module example-ospf { namespace "http://example.org/netconf/ospf"; prefix ospf; import network-types { // Access another module's def'ns prefix nett; } container ospf { // Declare the top-level tag list area { // Declare a list of "area" nodes key name; // The key "name" identifies list members leaf name { type nett:area-id; } list interface { key name; leaf name { type nett:interface-name; } leaf priority { description "Designated router priority"; type uint8; // The type is a constraint on // valid values for "priority". } leaf metric { type uint16 { range 1..65535; } } leaf dead-interval { units seconds; type uint16 { range 1..65535; } } } } } } Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6244 (draft-ietf-netmod-arch-10) -------------------------------------- Title : An Architecture for Network Management Using NETCONF and YANG Publication Date : June 2011 Author(s) : P. Shafer Category : INFORMATIONAL Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From mbj@tail-f.com Tue Sep 18 06:08: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 DB17E21E80BA for ; Tue, 18 Sep 2012 06:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8in7BqwG-Ar0 for ; Tue, 18 Sep 2012 06:08:50 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0EF21E80B0 for ; Tue, 18 Sep 2012 06:08:50 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 369AB1200D0F; Tue, 18 Sep 2012 15:08:48 +0200 (CEST) Date: Tue, 18 Sep 2012 15:08:47 +0200 (CEST) Message-Id: <20120918.150847.348333610267246619.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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, 18 Sep 2012 13:08:51 -0000 Hi, "Alexander Clemm (alex)" wrote: > We are hoping that this model is of interest to this group. Please > take a look and let us know your thoughts and comments. I have done a high-level review of this draft. My comments focus on higher-level issues, rather than details. o Maybe OPSAWG is the right place to do this work? Andy suggested that NETMOD could help other WGs with theier YANG models. I think that would be a good idea for this data model. o Is the Intended Status really Informational? o All your YANG models should have the markers. Note that the acl model has instead of the proper . Proper markers help tools extract the data models. o Running pyang on your data models gives two errors that are easy to fix: acl@2012-08-30.yang:1: warning: unexpected latest revision "2012-08-31" in acl@2012-08-30.yang, should be 2012-08-30 acl-ip.yang:389: error: type "Comparator" not found in module acl-ip o I suggest you try to be consistent in the format of the YANG models (indentation, placement of statements etc.) 'pyang' can help with this - run: pyang -f yang --yang-canonical to get started. This would make the models easier to follow. o I did not understand why some ip-related definitions are in acl-ip.yang, and some in acl.yang (and same for mac etc). o A common pattern in your model is this: leaf ip-source-kind { type IP-Network-Kind ; } choice source-address-host-group { when "ip-source-kind != 'any'"; case mask { when "ip-source-kind = 'ip'" ; leaf ip-source-address { ... } leaf ip-source-mask { ... } } case host { when "ip-source-kind = 'host'"; leaf ip-source-host-address { ... } } case group { when "ip-source-kind = 'group'"; leaf ip-source-group { ... } } } An alternative design which might simplify the model could be to get rid of the discriminator: choice source-address-host-group { case mask { // implies 'ip' kind leaf ip-source-address { ... } leaf ip-source-mask { ... } } case host { // implies 'host' kind leaf ip-source-host-address { ... } } case group { // implies 'group' kind leaf ip-source-group { ... } } case any { // implies 'any' kind leaf ip-any { type empty; } } } In this particular case, maybe it makes sense to add a form with a prefix instead of a mask: case prefix { leaf ip-source-subnet { type inet:ip-prefix; } } 10.0.0.1/24 o If seems a bit odd that there's a choice between a remark and filters; this means that you cannot put a comment on an ace that has filters. The model would be simpler if you did: OLD: choice remark-or-filter { case remark { leaf remark { ... } } case filter { container filters { uses ... } } NEW: leaf remark { ... } container filters { uses ... } Or maybe also get rid of the 'filters' container: leaf remark { ... } uses ... /martin From j.schoenwaelder@jacobs-university.de Wed Sep 19 04:44:59 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 BF9BE21F864A for ; Wed, 19 Sep 2012 04:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLva6KsR4jT8 for ; Wed, 19 Sep 2012 04:44:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5121F860E for ; Wed, 19 Sep 2012 04:44:58 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3166920C37; Wed, 19 Sep 2012 13:44:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nIbqQpTVHtZQ; Wed, 19 Sep 2012 13:44:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C783720C33; Wed, 19 Sep 2012 13:44:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74DF821D62FD; Wed, 19 Sep 2012 13:44:52 +0200 (CEST) Date: Wed, 19 Sep 2012 13:44:52 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120919114451.GA39136@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] interface keying - call for preferences 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, 19 Sep 2012 11:44:59 -0000 Hi, I like to close the interface keying issue. There has been a long thread "interface and ip" and I think we have seen the various arguments. The options that were identified are listed below: a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. This supports implementations using opaque interface names as well as implementations using system-level interface names. b) We use the change suggested in: http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html This essentially removes any interface name restrictions. Implementations that choose to still have some restrictions would either declare a deviation or cheat. c) The option of having a generic 'rename' extension for NETCONF along the lines of Phil's email: http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html This clearly is outside the scope of our charter, we would simply assume that at some point in time there will be a generic way of renaming things. d) Not explicitely proposed but mentioned in some emails is the option to have a 'rename-interface' RPC that renames interface config plus all leafrefs pointing to the old name. A special purpose version of c) which we could do now. e) Introduce a new RPC such as that returns a suitable key to the client when a new interface is created. Can people please state their preferences? Please be concise, lets try to not repeat the whole discussion. Here is what I have so far: Martin Bjorklund: I prefer (a) over (b); (c) is already out-of-scope, and I do not think we should do (d). (e) would be a really bad idea. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Sep 19 07:02:55 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 F41CB21F85B4 for ; Wed, 19 Sep 2012 07:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHR-yub5Fllc for ; Wed, 19 Sep 2012 07:02:53 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4D21F8567 for ; Wed, 19 Sep 2012 07:02:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUFnQiryXmzQfbN68EdWbngWpT7iKwhKq@postini.com; Wed, 19 Sep 2012 07:02:53 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Sep 2012 07:01:16 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q8JE1Dh48760; Wed, 19 Sep 2012 07:01:15 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q8JE1C3l001981; Wed, 19 Sep 2012 10:01:13 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201209191401.q8JE1C3l001981@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120919114451.GA39136@elstar.local> Date: Wed, 19 Sep 2012 10:01:12 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 19 Sep 2012 14:02:55 -0000 Juergen Schoenwaelder writes: >a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. > This supports implementations using opaque interface names as well > as implementations using system-level interface names. +1 >e) Introduce a new RPC such as that returns a > suitable key to the client when a new interface is created. I don't like (e) but there will (at some future point, in some future (chassis?) module) need to be a RPC that can take a set of criteria and return a set of suitable interfaces, including names and other information. Something like "give me the set of unused ethernet ports on slot 1 of this chassis". But that's future work; for now, (a) is the answer. Thanks, Phil From lhotka@nic.cz Wed Sep 19 08:41:44 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 8444321F86F7 for ; Wed, 19 Sep 2012 08:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+qaNBJp0yCG for ; Wed, 19 Sep 2012 08:41:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 89AF021F86EF for ; Wed, 19 Sep 2012 08:41:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 973235404A4 for ; Wed, 19 Sep 2012 17:41:41 +0200 (CEST) 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 Eu7A3BF5+v90 for ; Wed, 19 Sep 2012 17:41:37 +0200 (CEST) Received: from localhost (birdie-w.lhotkovi.cz [172.29.2.202]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9B4185401A4 for ; Wed, 19 Sep 2012 17:41:37 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120919114451.GA39136@elstar.local> References: <20120919114451.GA39136@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 19 Sep 2012 17:41:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface keying - call for preferences 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, 19 Sep 2012 15:41:44 -0000 Hi, I prefer (b) but I could easily live with (a) if "local-name" was added as an *optional* leaf. Lada Juergen Schoenwaelder writes: > Hi, > > I like to close the interface keying issue. There has been a long > thread "interface and ip" and I think we have seen the various > arguments. The options that were identified are listed below: > > a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. > This supports implementations using opaque interface names as well > as implementations using system-level interface names. > > b) We use the change suggested in: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html > > This essentially removes any interface name restrictions. > Implementations that choose to still have some restrictions would > either declare a deviation or cheat. > > c) The option of having a generic 'rename' extension for NETCONF along > the lines of Phil's email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html > > This clearly is outside the scope of our charter, we would simply > assume that at some point in time there will be a generic way of > renaming things. > > d) Not explicitely proposed but mentioned in some emails is the option > to have a 'rename-interface' RPC that renames interface config plus > all leafrefs pointing to the old name. A special purpose version of > c) which we could do now. > > e) Introduce a new RPC such as that returns a > suitable key to the client when a new interface is created. > > Can people please state their preferences? Please be concise, lets try > to not repeat the whole discussion. Here is what I have so far: > > Martin Bjorklund: > > I prefer (a) over (b); (c) is already out-of-scope, and I do not > think we should do (d). (e) would be a really bad idea. > > /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 yihuan@cisco.com Thu Sep 20 10:35: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 8BB8321F86A1 for ; Thu, 20 Sep 2012 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obQlZVtSCn8m for ; Thu, 20 Sep 2012 10:34:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5787E21F869A for ; Thu, 20 Sep 2012 10:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2206; q=dns/txt; s=iport; t=1348162499; x=1349372099; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=J1maQAKx6jUp8SJHhl53fzM0x0rWqN2N9i9wfhqOLRg=; b=XL53sdd6KjwfLxB3dhzNpJYa8tsXoHlt8bTPKX49nU2cFtgw3p+vpIzX hrFvb8hu9D+y/QORhmPkE9ky7N/XTUvXLy+kjpVv1MvB50+yHkwZplLG6 JmRhEvBGiANtXP2wHp7c8iv58fmPz3Agzt2kn+45rR1qC90Rk5k8B5Ha2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALRSW1CtJV2Z/2dsb2JhbABCA70jgQiCIgEEAQEBDwEKHTQZBAEIDgImKwwLJQIEARIJGYdhC5oPoBUEizKDA4MlA5VkjjiBaYJngWM0 X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="123661672" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 20 Sep 2012 17:34:59 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8KHYwWl027176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 17:34:58 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Thu, 20 Sep 2012 12:34:58 -0500 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] interface keying - call for preferences Thread-Index: AQHNllw36zGjKxzGvUiIneqi3HgAj5eTXkGA Date: Thu, 20 Sep 2012 17:34:58 +0000 Message-ID: In-Reply-To: <20120919114451.GA39136@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.166.184] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--52.843300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <10ADD5AFF9491F4AA47334752ED3967A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] interface keying - call for preferences 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, 20 Sep 2012 17:35:05 -0000 b +1. On 9/19/12 4:44 AM, "Juergen Schoenwaelder" wrote: >Hi, > >I like to close the interface keying issue. There has been a long >thread "interface and ip" and I think we have seen the various >arguments. The options that were identified are listed below: > >a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. > This supports implementations using opaque interface names as well > as implementations using system-level interface names. > >b) We use the change suggested in: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html > > This essentially removes any interface name restrictions. > Implementations that choose to still have some restrictions would > either declare a deviation or cheat. > >c) The option of having a generic 'rename' extension for NETCONF along > the lines of Phil's email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html > > This clearly is outside the scope of our charter, we would simply > assume that at some point in time there will be a generic way of > renaming things. > >d) Not explicitely proposed but mentioned in some emails is the option > to have a 'rename-interface' RPC that renames interface config plus > all leafrefs pointing to the old name. A special purpose version of > c) which we could do now. > >e) Introduce a new RPC such as that returns a > suitable key to the client when a new interface is created. > >Can people please state their preferences? Please be concise, lets try >to not repeat the whole discussion. Here is what I have so far: > >Martin Bjorklund: > > I prefer (a) over (b); (c) is already out-of-scope, and I do not > think we should do (d). (e) would be a really bad idea. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From pgili@cisco.com Thu Sep 20 10:38:01 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 1112621F86A3 for ; Thu, 20 Sep 2012 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnyhCWkiXKey for ; Thu, 20 Sep 2012 10:38:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF73A21F86E8 for ; Thu, 20 Sep 2012 10:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2321; q=dns/txt; s=iport; t=1348162678; x=1349372278; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=98UW7vx0gaAVkvhMPZrYNzYT8nU/TLCoTUlqSVWBDV0=; b=NJXX7XN5tz7Irck2X5khpnlqulplSMaMhNV6Xgq5ZdpGqLxWKbf4kTqK IH5zLNkJXiBYzIJp43wigcvnVI/j7N3re+fmF4rIpLbizsWvgRSa/cnHu hU4BYj6FAUJDuxf2fBoWd5PX+5J4xbbgvLnc8RubgDGzVhA5mFgX5jUFs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAA1UW1CtJV2d/2dsb2JhbABCA70jgQiCIAEBAQQBAQEPAQodNBcCAgIBCA4CAQQBAQsUCQcbDAsUCQgCBAESCAEZh2ELmgugFQSLGBqDA4JFYAOkHIFpgmeBYzQ X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="123444684" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 20 Sep 2012 17:37:57 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8KHbvZO028435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 17:37:57 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 20 Sep 2012 12:37:57 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] interface keying - call for preferences Thread-Index: AQHNllw3qJkf/AcnA0GPZG7OCpIpXpeTgItg Date: Thu, 20 Sep 2012 17:37:56 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB052F17@xmb-aln-x14.cisco.com> References: <20120919114451.GA39136@elstar.local> In-Reply-To: <20120919114451.GA39136@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--49.911400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] interface keying - call for preferences 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, 20 Sep 2012 17:38:01 -0000 Choice A -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Wednesday, September 19, 2012 7:45 AM To: netmod@ietf.org Subject: [netmod] interface keying - call for preferences Hi, I like to close the interface keying issue. There has been a long thread "i= nterface and ip" and I think we have seen the various arguments. The option= s that were identified are listed below: a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. This supports implementations using opaque interface names as well as implementations using system-level interface names. b) We use the change suggested in: http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html This essentially removes any interface name restrictions. Implementations that choose to still have some restrictions would either declare a deviation or cheat. c) The option of having a generic 'rename' extension for NETCONF along the lines of Phil's email: http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html This clearly is outside the scope of our charter, we would simply assume that at some point in time there will be a generic way of renaming things. d) Not explicitely proposed but mentioned in some emails is the option to have a 'rename-interface' RPC that renames interface config plus all leafrefs pointing to the old name. A special purpose version of c) which we could do now. e) Introduce a new RPC such as that returns a suitable key to the client when a new interface is created. Can people please state their preferences? Please be concise, lets try to n= ot repeat the whole discussion. Here is what I have so far: Martin Bjorklund: I prefer (a) over (b); (c) is already out-of-scope, and I do not think we should do (d). (e) would be a really bad idea. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Thu Sep 20 10:55: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 C1B6321F87E9 for ; Thu, 20 Sep 2012 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB1C43SYUcal for ; Thu, 20 Sep 2012 10:55:09 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2727221F8783 for ; Thu, 20 Sep 2012 10:55:09 -0700 (PDT) Received: by qaec10 with SMTP id c10so636661qae.10 for ; Thu, 20 Sep 2012 10:55:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=klhmlrDlfmeazLJl6W/GRwR7XFogovqBUS4wFNvnwZg=; b=YLoV9dwufLn7yIn11QPY8CQeJttN1Mjn3QJZ9sCPg+lWBABjP0+cuoWWQ61nbKKB8N oKhj+6FvbkeAJTOMaIOUQKCzGCspkv06+6tpG9tnoWezi054SGxzL+cuVhcVLVmG1sDp Rbma6W3UPolvSLlGJnBgPL3FOIrVf5pRKhIarm9NV4W/dRvSmWBfpHj39jrMLhMoEH8E POZis6ev1rwyDsCglPJLjbpW7j9O/hiqjD35ARgOPiL2YQLP2Lqc4eOgS8qn73CAcoRn 1dAiAIa1gQoEUswq9W4UzfqdJvOFIceqz5erlI7189PGUtQT2knQryZzbAzx8PzjRKDD uaMg== MIME-Version: 1.0 Received: by 10.224.220.204 with SMTP id hz12mr6358722qab.40.1348163708561; Thu, 20 Sep 2012 10:55:08 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Thu, 20 Sep 2012 10:55:08 -0700 (PDT) In-Reply-To: <20120919114451.GA39136@elstar.local> References: <20120919114451.GA39136@elstar.local> Date: Thu, 20 Sep 2012 10:55:08 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkRjZd8Eghwwp/t6S/NaR8er36puMHFaLr2MM6+rXEubt+QszZizzSPmrDzpK8Oac/Xxy7A Subject: Re: [netmod] interface keying - call for preferences 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, 20 Sep 2012 17:55:09 -0000 I prefer (a). I also prefer that some sort of operation is available if (a) is used: rpc name-interface { description "return an acceptable interface name for a given interface type and location."; input { leaf type { type ianaift:iana-if-type; mandatory true; } leaf location { type string; } } output { leaf name { type string; } } } Andy On Wed, Sep 19, 2012 at 4:44 AM, Juergen Schoenwaelder wrote: > Hi, > > I like to close the interface keying issue. There has been a long > thread "interface and ip" and I think we have seen the various > arguments. The options that were identified are listed below: > > a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. > This supports implementations using opaque interface names as well > as implementations using system-level interface names. > > b) We use the change suggested in: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html > > This essentially removes any interface name restrictions. > Implementations that choose to still have some restrictions would > either declare a deviation or cheat. > > c) The option of having a generic 'rename' extension for NETCONF along > the lines of Phil's email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html > > This clearly is outside the scope of our charter, we would simply > assume that at some point in time there will be a generic way of > renaming things. > > d) Not explicitely proposed but mentioned in some emails is the option > to have a 'rename-interface' RPC that renames interface config plus > all leafrefs pointing to the old name. A special purpose version of > c) which we could do now. > > e) Introduce a new RPC such as that returns a > suitable key to the client when a new interface is created. > > Can people please state their preferences? Please be concise, lets try > to not repeat the whole discussion. Here is what I have so far: > > Martin Bjorklund: > > I prefer (a) over (b); (c) is already out-of-scope, and I do not > think we should do (d). (e) would be a really bad idea. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From alex@cisco.com Thu Sep 20 11:06: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 1CE1421F881D for ; Thu, 20 Sep 2012 11:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMqvEeBkRFEL for ; Thu, 20 Sep 2012 11:06:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2050521F8810 for ; Thu, 20 Sep 2012 11:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3754; q=dns/txt; s=iport; t=1348164409; x=1349374009; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=r3n4E2Jjo+rXHerkmQ6iJrltYrD27V05OGKW63L2Jks=; b=Z4ZaZasH2aUZNGdUrk6H/6x9aoGhEwXnrOtAn6EB9or9JalC6zlExo3K vaYN0cX1yUhbBlJRbuxR1cZA8hZL2jQ7uvTvZzsgFKeeoa2lJba9iTiM3 4gZGyMXwGIeRmQH4D+GXgq1yN/qTM7vWaS6dolgk9zfw2mT/DeWnV8wdH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANdZW1CtJXG8/2dsb2JhbABCA70ngQiCIAEBAQQBAQEPAQodNBcCAgIBCBABBAEBAQoUCQcbDAsUCQgCBAESCAEZh2ELmg6gFQSLGBqDA4JFYAOkHIFpgmeBYzQ X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="123673385" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 20 Sep 2012 18:06:40 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8KI6eBd018314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 18:06:40 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 20 Sep 2012 13:06:40 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] interface keying - call for preferences Thread-Index: AQHNllw3R5bcABfZhka/ATxPnqumRZeT2T4A//+tVLA= Date: Thu, 20 Sep 2012 18:06:40 +0000 Message-ID: References: <20120919114451.GA39136@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.43] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--61.304400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] interface keying - call for preferences 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, 20 Sep 2012 18:06:50 -0000 a+1 . =20 b would still be preferrable over c,d, not sure about the suggested operation - I agree with the spirit (of making= it easier to avoid issues with picking the "right" name particular in the = presence of device name constraints that MAY apply) but I am wondering if = the particular output would change over time - this addresses cases where t= he name is a function of type and location which may not be necessarily a g= iven - anyway, maybe some further discussion needed. =20 --- Alex -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Andy Bierman Sent: Thursday, September 20, 2012 10:55 AM To: Juergen Schoenwaelder; netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences I prefer (a). I also prefer that some sort of operation is available if = (a) is used: rpc name-interface { description "return an acceptable interface name for a given interface type and location."; input { leaf type { type ianaift:iana-if-type; mandatory true; } leaf location { type string; } } output { leaf name { type string; } } } Andy On Wed, Sep 19, 2012 at 4:44 AM, Juergen Schoenwaelder wrote: > Hi, > > I like to close the interface keying issue. There has been a long=20 > thread "interface and ip" and I think we have seen the various=20 > arguments. The options that were identified are listed below: > > a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. > This supports implementations using opaque interface names as well > as implementations using system-level interface names. > > b) We use the change suggested in: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html > > This essentially removes any interface name restrictions. > Implementations that choose to still have some restrictions would > either declare a deviation or cheat. > > c) The option of having a generic 'rename' extension for NETCONF along > the lines of Phil's email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html > > This clearly is outside the scope of our charter, we would simply > assume that at some point in time there will be a generic way of > renaming things. > > d) Not explicitely proposed but mentioned in some emails is the option > to have a 'rename-interface' RPC that renames interface config plus > all leafrefs pointing to the old name. A special purpose version of > c) which we could do now. > > e) Introduce a new RPC such as that returns a > suitable key to the client when a new interface is created. > > Can people please state their preferences? Please be concise, lets try=20 > to not repeat the whole discussion. Here is what I have so far: > > Martin Bjorklund: > > I prefer (a) over (b); (c) is already out-of-scope, and I do not > think we should do (d). (e) would be a really bad idea. > > /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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From xiangli@seguesoft.com Fri Sep 21 06:55: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 3A8BF21F883A for ; Fri, 21 Sep 2012 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM1RnwUSKd0a for ; Fri, 21 Sep 2012 06:55:21 -0700 (PDT) Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) by ietfa.amsl.com (Postfix) with SMTP id 2A81521F8838 for ; Fri, 21 Sep 2012 06:55:20 -0700 (PDT) Received: (qmail 1153 invoked from network); 21 Sep 2012 13:55:20 -0000 Received: from unknown (98.212.151.151) by p3plsmtpa08-05.prod.phx3.secureserver.net (173.201.193.106) with ESMTP; 21 Sep 2012 13:55:19 -0000 Message-ID: <505C71C6.5050000@seguesoft.com> Date: Fri, 21 Sep 2012 08:55:18 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20120919114451.GA39136@elstar.local> In-Reply-To: <20120919114451.GA39136@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] interface keying - call for preferences 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, 21 Sep 2012 13:55:22 -0000 I prefer (a). I am also thinking if we could add a mandatory-false and config-false leaf "xyz-pattern" node that may serve as a hint to acceptable interface name for a given interface type and location (if any). For example: leaf name-pattern { mandatory false; --not really needed here config false type string; description "acceptable interface name regular string pattern"; } Similarly we can add another mandatory-false leaf: leaf description-pattern { mandatory false; --not really needed here config false type string; description "acceptable description name regular string pattern"; } Then we can remove the description " This leaf MAY be mapped to ifAlias by an implementation...." etc. The idea is similar to Andy's proposed operation without actually introducing an additional RPC. However I am not even sure this kind of helper nodes are even recommended by YANG design principles. --Xiang On 9/19/2012 6:44 AM, Juergen Schoenwaelder wrote: > Hi, > > I like to close the interface keying issue. There has been a long > thread "interface and ip" and I think we have seen the various > arguments. The options that were identified are listed below: > > a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. > This supports implementations using opaque interface names as well > as implementations using system-level interface names. > > b) We use the change suggested in: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html > > This essentially removes any interface name restrictions. > Implementations that choose to still have some restrictions would > either declare a deviation or cheat. > > c) The option of having a generic 'rename' extension for NETCONF along > the lines of Phil's email: > > http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html > > This clearly is outside the scope of our charter, we would simply > assume that at some point in time there will be a generic way of > renaming things. > > d) Not explicitely proposed but mentioned in some emails is the option > to have a 'rename-interface' RPC that renames interface config plus > all leafrefs pointing to the old name. A special purpose version of > c) which we could do now. > > e) Introduce a new RPC such as that returns a > suitable key to the client when a new interface is created. > > Can people please state their preferences? Please be concise, lets try > to not repeat the whole discussion. Here is what I have so far: > > Martin Bjorklund: > > I prefer (a) over (b); (c) is already out-of-scope, and I do not > think we should do (d). (e) would be a really bad idea. > > /js > -- --Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 Mobile: 1 (217) 472-4108 From andy@yumaworks.com Fri Sep 21 07:19: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 4650921F883A for ; Fri, 21 Sep 2012 07:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSBgaAA8bEIQ for ; Fri, 21 Sep 2012 07:19:20 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0B421F8831 for ; Fri, 21 Sep 2012 07:19:20 -0700 (PDT) Received: by qaec10 with SMTP id c10so1400550qae.10 for ; Fri, 21 Sep 2012 07:19:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ib3hJYhWvHD8JJDqZi4g8G1uozN+YonT8deGUM1wLO0=; b=mQZPMgmd/cHfWH5a0rWKlO2UINBZKnIhGRie+YgLadXCOOv25Y8DxpJNsh7MpuH4iF /Pye425y1vSVcBYJUjfgG5uPkgJ/ERbLCCL/jfgyu+g2vM9eMIR3vJZVD6mBklOiJbFo uFyI/ZhIwgI4sLFYavouDtBBWcOYYBPHBeTkHV1PXW/Qkay7W8RdFvQttHpxjjKlzzqG tQ+PymNhjRRo6FVDutdIEksDtkFfl+ccv1dsV49+imL2Xz58/PM+yRmtHM1dTC5JXnac FV8qnoLcFg0G9PylcOKxdvczs7Qt9qTjkpn2fy7tmRbBJrAX81DhEG40eT/vDx3yLBxZ LIxw== MIME-Version: 1.0 Received: by 10.224.180.83 with SMTP id bt19mr1696445qab.82.1348237159718; Fri, 21 Sep 2012 07:19:19 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Fri, 21 Sep 2012 07:19:19 -0700 (PDT) In-Reply-To: <505C71C6.5050000@seguesoft.com> References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> Date: Fri, 21 Sep 2012 07:19:19 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk+85k5sbz/zfvW1r6ACD+O8hGcZusMqalil/ZUe3GzR7YVEiwnx+EfaMKTSqomxfDY9Dhl Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 21 Sep 2012 14:19:21 -0000 On Fri, Sep 21, 2012 at 6:55 AM, Xiang Li wrote: > I prefer (a). I am also thinking if we could add a > mandatory-false and config-false leaf "xyz-pattern" > node that may serve as a hint to acceptable interface > name for a given interface type and location (if any). > For example: > > leaf name-pattern { > mandatory false; --not really needed here > config false > type string; > description "acceptable interface name regular string pattern"; > } > > Similarly we can add another mandatory-false leaf: > leaf description-pattern { > mandatory false; --not really needed here > config false > type string; > description "acceptable description name regular string pattern"; > } > > Then we can remove the description " This leaf MAY be mapped to ifAlias by > an implementation...." etc. > > The idea is similar to Andy's proposed operation without > actually introducing an additional RPC. However I am not even sure this kind > of helper nodes are even recommended by YANG design principles. > IMO this will not work because there are no input parameters possible, and a static pattern doesn't represent the acceptable choices. The operation may even be too simplistic because it assumes all interfaces can be named knowing the type and location. This probably covers most interface naming schemes though, which is why I suggested it. > --Xiang Andy > > On 9/19/2012 6:44 AM, Juergen Schoenwaelder wrote: >> >> Hi, >> >> I like to close the interface keying issue. There has been a long >> thread "interface and ip" and I think we have seen the various >> arguments. The options that were identified are listed below: >> >> a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. >> This supports implementations using opaque interface names as well >> as implementations using system-level interface names. >> >> b) We use the change suggested in: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html >> >> This essentially removes any interface name restrictions. >> Implementations that choose to still have some restrictions would >> either declare a deviation or cheat. >> >> c) The option of having a generic 'rename' extension for NETCONF along >> the lines of Phil's email: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html >> >> This clearly is outside the scope of our charter, we would simply >> assume that at some point in time there will be a generic way of >> renaming things. >> >> d) Not explicitely proposed but mentioned in some emails is the option >> to have a 'rename-interface' RPC that renames interface config plus >> all leafrefs pointing to the old name. A special purpose version of >> c) which we could do now. >> >> e) Introduce a new RPC such as that returns a >> suitable key to the client when a new interface is created. >> >> Can people please state their preferences? Please be concise, lets try >> to not repeat the whole discussion. Here is what I have so far: >> >> Martin Bjorklund: >> >> I prefer (a) over (b); (c) is already out-of-scope, and I do not >> think we should do (d). (e) would be a really bad idea. >> >> /js >> > > -- > --Xiang Li > Web: www.seguesoft.com > Voice: 1 (872) 216-2610 > Mobile: 1 (217) 472-4108 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From xiangli@seguesoft.com Fri Sep 21 07:19: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 08A4021F8831 for ; Fri, 21 Sep 2012 07:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyd40i75p7pz for ; Fri, 21 Sep 2012 07:19:21 -0700 (PDT) Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) by ietfa.amsl.com (Postfix) with SMTP id 16D9521F8838 for ; Fri, 21 Sep 2012 07:19:20 -0700 (PDT) Received: (qmail 365 invoked from network); 21 Sep 2012 14:19:19 -0000 Received: from unknown (98.212.151.151) by p3plsmtpa07-09.prod.phx3.secureserver.net (173.201.192.238) with ESMTP; 21 Sep 2012 14:19:17 -0000 Message-ID: <505C7767.9040408@seguesoft.com> Date: Fri, 21 Sep 2012 09:19:19 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> In-Reply-To: <505C71C6.5050000@seguesoft.com> Content-Type: multipart/alternative; boundary="------------050307070806090304060802" Subject: Re: [netmod] interface keying - call for preferences 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, 21 Sep 2012 14:19:22 -0000 This is a multi-part message in MIME format. --------------050307070806090304060802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I realized this might not necessary if the in the error can somehow be made to contain what is acceptable values. Can we even enforce the content of a ? Name is not valid. Valid pattern are xxxx --Xiang On 9/21/2012 8:55 AM, Xiang Li wrote: > I prefer (a). I am also thinking if we could add a > mandatory-false and config-false leaf "xyz-pattern" > node that may serve as a hint to acceptable interface > name for a given interface type and location (if any). > For example: > > leaf name-pattern { > mandatory false; --not really needed here > config false > type string; > description "acceptable interface name regular string pattern"; > } > > Similarly we can add another mandatory-false leaf: > leaf description-pattern { > mandatory false; --not really needed here > config false > type string; > description "acceptable description name regular string pattern"; > } > > Then we can remove the description " This leaf MAY be mapped to > ifAlias by > an implementation...." etc. > > The idea is similar to Andy's proposed operation without > actually introducing an additional RPC. However I am not even sure > this kind > of helper nodes are even recommended by YANG design principles. > > --Xiang > > On 9/19/2012 6:44 AM, Juergen Schoenwaelder wrote: >> Hi, >> >> I like to close the interface keying issue. There has been a long >> thread "interface and ip" and I think we have seen the various >> arguments. The options that were identified are listed below: >> >> a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06. >> This supports implementations using opaque interface names as well >> as implementations using system-level interface names. >> >> b) We use the change suggested in: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html >> >> This essentially removes any interface name restrictions. >> Implementations that choose to still have some restrictions would >> either declare a deviation or cheat. >> >> c) The option of having a generic 'rename' extension for NETCONF along >> the lines of Phil's email: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html >> >> This clearly is outside the scope of our charter, we would simply >> assume that at some point in time there will be a generic way of >> renaming things. >> >> d) Not explicitely proposed but mentioned in some emails is the option >> to have a 'rename-interface' RPC that renames interface config plus >> all leafrefs pointing to the old name. A special purpose version of >> c) which we could do now. >> >> e) Introduce a new RPC such as that returns a >> suitable key to the client when a new interface is created. >> >> Can people please state their preferences? Please be concise, lets try >> to not repeat the whole discussion. Here is what I have so far: >> >> Martin Bjorklund: >> >> I prefer (a) over (b); (c) is already out-of-scope, and I do not >> think we should do (d). (e) would be a really bad idea. >> >> /js >> > -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 --------------050307070806090304060802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I realized this might not necessary if the <error-message> in the <invalid-value> error
can somehow be made to contain what is acceptable values.  Can we even enforce the
content of a  <error-message >?
<error-message >
           Name is not valid. Valid pattern are xxxx
</error-message>


--Xiang

On 9/21/2012 8:55 AM, Xiang Li wrote:
I prefer (a). I am also thinking if we could add a
mandatory-false and config-false leaf "xyz-pattern"
node that may serve as a hint to acceptable interface
name for a given interface type and location (if any).
For example:

leaf name-pattern {
       mandatory false; --not really needed here
       config false
       type string;
       description "acceptable interface name regular string pattern";
     }

Similarly we can add another mandatory-false leaf:
leaf description-pattern {
       mandatory false; --not really needed here
       config false   
       type string;
       description "acceptable description name regular string pattern";
     }

Then we can remove the description " This leaf MAY be mapped to ifAlias by
an implementation...." etc.

The idea is similar to Andy's proposed <name-interface> operation without
actually introducing an additional RPC. However I am not even sure this kind
of helper nodes are even recommended by YANG design principles.

--Xiang

On 9/19/2012 6:44 AM, Juergen Schoenwaelder wrote:
Hi,

I like to close the interface keying issue. There has been a long
thread "interface and ip" and I think we have seen the various
arguments. The options that were identified are listed below:

a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06.
    This supports implementations using opaque interface names as well
    as implementations using system-level interface names.

b) We use the change suggested in:

    http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html

    This essentially removes any interface name restrictions.
    Implementations that choose to still have some restrictions would
    either declare a deviation or cheat.

c) The option of having a generic 'rename' extension for NETCONF along
    the lines of Phil's email:

    http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html

    This clearly is outside the scope of our charter, we would simply
    assume that at some point in time there will be a generic way of
    renaming things.

d) Not explicitely proposed but mentioned in some emails is the option
    to have a 'rename-interface' RPC that renames interface config plus
    all leafrefs pointing to the old name. A special purpose version of
    c) which we could do now.

e) Introduce a new RPC such as <create-interface> that returns a
    suitable key to the client when a new interface is created.

Can people please state their preferences? Please be concise, lets try
to not repeat the whole discussion. Here is what I have so far:

Martin Bjorklund:

   I prefer (a) over (b); (c) is already out-of-scope, and I do not
   think we should do (d). (e) would be a really bad idea.

/js 



-- 
--
Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610
--------------050307070806090304060802-- From jernej.tuljak@mg-soft.si Fri Sep 21 07:47: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 EBD1F21F87BC for ; Fri, 21 Sep 2012 07:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOyw-0Wm7Yto for ; Fri, 21 Sep 2012 07:47:03 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2111021F8808 for ; Fri, 21 Sep 2012 07:47:02 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8LEl19S012551 for ; Fri, 21 Sep 2012 16:47:01 +0200 Message-ID: <505C7DDD.6060503@mg-soft.com> Date: Fri, 21 Sep 2012 16:46:53 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------040206070109010801020404" Subject: [netmod] RFC6110 and unique-stmt mapping 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, 21 Sep 2012 14:47:04 -0000 This is a multi-part message in MIME format. --------------040206070109010801020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, RFC6110 10.55.: The 'units' Statement This statement is mapped to the @nma:unique attribute. ARGUMENT MUST be translated so that every node identifier in each of its components is prefixed with the namespace prefix of the local module, unless the prefix is already present. The result of this translation then becomes the value of the @nma:unique attribute. For example, assuming that the local module prefix is "ex", unique "foo ex:bar/baz" is mapped to the following attribute/value pair: nma:unique="ex:foo ex:bar/ex:baz" A list's unique-stmt has a cardinality of 0..n, the same as for a must-stmt. *(unique-stmt stmtsep) Why is a uniqe-stmt mapped into an @nma:unique attribute? How do you encode multiple unique-stmt arguments into a single @nma:unique attribute? Do note that an XML element with multiple attributes named exactly the same way is not a well formed XML element and a file that is not XML cannot be transformed using XSLT. unique "foo bar"; unique "baz foo"; @nma:unique = ? It would make sense to me to encode this statement as an element, the same way this is done for must-stmt. Am I missing something? I hope I got the mailing list right. Please direct this message to a proper mailing list if not so. Jernej --------------040206070109010801020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

RFC6110 10.55.:
The 'units' Statement

   This statement is mapped to the @nma:unique attribute.  ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @nma:unique attribute.

   For example, assuming that the local module prefix is "ex",

   unique "foo ex:bar/baz"

   is mapped to the following attribute/value pair:

   nma:unique="ex:foo ex:bar/ex:baz"
A list's unique-stmt has a cardinality of 0..n, the same as for a must-stmt. 
*(unique-stmt stmtsep)
Why is a uniqe-stmt mapped into an @nma:unique attribute? How do you encode multiple unique-stmt arguments into a single @nma:unique attribute? Do note that an XML element with multiple attributes named exactly the same way is not a well formed XML element and a file that is not XML cannot be transformed using XSLT.

unique "foo bar";
unique "baz foo";

@nma:unique = ?

It would make sense to me to encode this statement as an element, the same way this is done for must-stmt. Am I missing something?

I hope I got the mailing list right. Please direct this message to a proper mailing list if not so.

Jernej
--------------040206070109010801020404-- From jernej.tuljak@mg-soft.si Fri Sep 21 07:50: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 7173621F8797 for ; Fri, 21 Sep 2012 07:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEa+eWFmVlLf for ; Fri, 21 Sep 2012 07:50:02 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id EFD8A21F8819 for ; Fri, 21 Sep 2012 07:50:01 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8LEo0b1012577; Fri, 21 Sep 2012 16:50:01 +0200 Message-ID: <505C7E90.1060409@mg-soft.com> Date: Fri, 21 Sep 2012 16:49:52 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <505C7DDD.6060503@mg-soft.com> In-Reply-To: <505C7DDD.6060503@mg-soft.com> Content-Type: multipart/alternative; boundary="------------020604080203010306090200" Cc: NETMOD Working Group Subject: Re: [netmod] RFC6110 and unique-stmt mapping 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, 21 Sep 2012 14:50:03 -0000 This is a multi-part message in MIME format. --------------020604080203010306090200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dne 21.9.2012 16:46, pis(e Jernej Tuljak: > Hi, > > RFC6110 10.55.: > > > The 'units' Statement > Wrong copy/paste. Should obviously be "The 'unique' Statement". Jernej > > This statement is mapped to the @nma:unique attribute. ARGUMENT MUST > be translated so that every node identifier in each of its components > is prefixed with the namespace prefix of the local module, unless the > prefix is already present. The result of this translation then > becomes the value of the @nma:unique attribute. > For example, assuming that the local module prefix is "ex", > > unique "foo ex:bar/baz" > > is mapped to the following attribute/value pair: > > nma:unique="ex:foo ex:bar/ex:baz" > > A list's unique-stmt has a cardinality of 0..n, the same as for a > must-stmt. > *(unique-stmt stmtsep) > Why is a uniqe-stmt mapped into an @nma:unique attribute? How do you > encode multiple unique-stmt arguments into a single @nma:unique > attribute? Do note that an XML element with multiple attributes named > exactly the same way is not a well formed XML element and a file that > is not XML cannot be transformed using XSLT. > > unique "foo bar"; > unique "baz foo"; > > @nma:unique = ? > > It would make sense to me to encode this statement as an element, the > same way this is done for must-stmt. Am I missing something? > > I hope I got the mailing list right. Please direct this message to a > proper mailing list if not so. > > Jernej > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------020604080203010306090200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dne 21.9.2012 16:46, piše Jernej Tuljak:
Hi,

RFC6110 10.55.:
The 'units' Statement

Wrong copy/paste. Should obviously be "The 'unique' Statement".

Jernej



   This statement is mapped to the @nma:unique attribute.  ARGUMENT MUST
   be translated so that every node identifier in each of its components
   is prefixed with the namespace prefix of the local module, unless the
   prefix is already present.  The result of this translation then
   becomes the value of the @nma:unique attribute.

   For example, assuming that the local module prefix is "ex",

   unique "foo ex:bar/baz"

   is mapped to the following attribute/value pair:

   nma:unique="ex:foo ex:bar/ex:baz"
A list's unique-stmt has a cardinality of 0..n, the same as for a must-stmt. 
*(unique-stmt stmtsep)
Why is a uniqe-stmt mapped into an @nma:unique attribute? How do you encode multiple unique-stmt arguments into a single @nma:unique attribute? Do note that an XML element with multiple attributes named exactly the same way is not a well formed XML element and a file that is not XML cannot be transformed using XSLT.

unique "foo bar";
unique "baz foo";

@nma:unique = ?

It would make sense to me to encode this statement as an element, the same way this is done for must-stmt. Am I missing something?

I hope I got the mailing list right. Please direct this message to a proper mailing list if not so.

Jernej


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------020604080203010306090200-- From lhotka@nic.cz Fri Sep 21 08:02: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 D935321F8830 for ; Fri, 21 Sep 2012 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZbwhVhhBSe8 for ; Fri, 21 Sep 2012 08:02:13 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 477C121F882E for ; Fri, 21 Sep 2012 08:02:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C140C540466; Fri, 21 Sep 2012 17:02:11 +0200 (CEST) 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 gBtS8TcaFvYZ; Fri, 21 Sep 2012 17:01:46 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 257B354020A; Fri, 21 Sep 2012 17:01:45 +0200 (CEST) From: Ladislav Lhotka To: Jernej Tuljak , Jernej Tuljak In-Reply-To: <505C7E90.1060409@mg-soft.com> References: <505C7DDD.6060503@mg-soft.com> <505C7E90.1060409@mg-soft.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Jernej Tuljak , Jernej Tuljak , NETMOD Working Group Date: Fri, 21 Sep 2012 17:01:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: NETMOD Working Group Subject: Re: [netmod] RFC6110 and unique-stmt mapping 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, 21 Sep 2012 15:02:14 -0000 Jernej Tuljak writes: > Dne 21.9.2012 16:46, pis(e Jernej Tuljak: >> Hi, >> >> RFC6110 10.55.: >> >> >> The 'units' Statement >> > > Wrong copy/paste. Should obviously be "The 'unique' Statement". > > Jernej > >> >> This statement is mapped to the @nma:unique attribute. ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @nma:unique attribute. >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following attribute/value pair: >> >> nma:unique="ex:foo ex:bar/ex:baz" >> >> A list's unique-stmt has a cardinality of 0..n, the same as for a >> must-stmt. >> *(unique-stmt stmtsep) >> Why is a uniqe-stmt mapped into an @nma:unique attribute? How do you >> encode multiple unique-stmt arguments into a single @nma:unique >> attribute? Do note that an XML element with multiple attributes named >> exactly the same way is not a well formed XML element and a file that >> is not XML cannot be transformed using XSLT. >> >> unique "foo bar"; >> unique "baz foo"; >> >> @nma:unique = ? >> >> It would make sense to me to encode this statement as an element, the >> same way this is done for must-stmt. Am I missing something? No, this is a bug. I didn't realize there might be multiple "unique" statements. Would you mind to report it as an erratum? http://www.rfc-editor.org/errata.php#reportnew Thanks, Lada >> >> I hope I got the mailing list right. Please direct this message to a >> proper mailing list if not so. >> >> Jernej >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wwwrun@rfc-editor.org Fri Sep 21 08:52:34 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 4FF7B21E80A6 for ; Fri, 21 Sep 2012 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t39UXrBltfCq for ; Fri, 21 Sep 2012 08:52:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7021E8097 for ; Fri, 21 Sep 2012 08:52:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6A92C72E038; Fri, 21 Sep 2012 08:48:50 -0700 (PDT) To: lhotka@cesnet.cz, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20120921154850.6A92C72E038@rfc-editor.org> Date: Fri, 21 Sep 2012 08:48:50 -0700 (PDT) Cc: netmod@ietf.org, jernej.tuljak@mg-soft.com, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 21 Sep 2012 15:52:34 -0000 The following errata report has been submitted for RFC6110, "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6110&eid=3362 -------------------------------------- Type: Technical Reported by: Jernej Tuljak Section: 10.55. Original Text ------------- The 'unique' Statement This statement is mapped to the @nma:unique attribute. ARGUMENT MUST be translated so that every node identifier in each of its components is prefixed with the namespace prefix of the local module, unless the prefix is already present. The result of this translation then becomes the value of the @nma:unique attribute. For example, assuming that the local module prefix is "ex", unique "foo ex:bar/baz" is mapped to the following attribute/value pair: nma:unique="ex:foo ex:bar/ex:baz" Corrected Text -------------- The 'unique' Statement This statement is mapped to the element. It has one mandatory attribute @key (with no namespace). ARGUMENT MUST be translated so that every node identifier in each of its components is prefixed with the namespace prefix of the local module, unless the prefix is already present. The result of this translation then becomes the value of the @key attribute. For example, assuming that the local module prefix is "ex", unique "foo ex:bar/baz" is mapped to the following element: Notes ----- A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6110 (draft-ietf-netmod-dsdl-map-10) -------------------------------------- Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Publication Date : February 2011 Author(s) : L. Lhotka, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From randy_presuhn@mindspring.com Fri Sep 21 09:51:12 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 F250821E8097 for ; Fri, 21 Sep 2012 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjCR0iOdAtGy for ; Fri, 21 Sep 2012 09:51:11 -0700 (PDT) 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 71C8421E8082 for ; Fri, 21 Sep 2012 09:51:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DtbNbPEXRVE97rRyLABlE2+yK7B4Jt89aeTUXm3kQIawW7D+ZehHMwjLSqmOVzJz; 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.30.224.193] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TF6Ra-0003VE-2D for netmod@ietf.org; Fri, 21 Sep 2012 12:51:10 -0400 Message-ID: <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120919114451.GA39136@elstar.local><505C71C6.5050000@seguesoft.com> Date: Fri, 21 Sep 2012 09:58:34 -0700 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1b54d3dd988859c45442ebeed0a613755350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.224.193 Subject: Re: [netmod] interface keying - call for preferences 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, 21 Sep 2012 16:51:12 -0000 Hi - I can't help but think that we're thinking about this in if not the wrong way, at least in a way that makes things harder than they need to be. When one is stitching a stack together, there ends up being a web of service users and service providers, connected by references from one more-or-less arbitrarily named interface to another. Where this hits a rock in the current discussion is when that reference is to the "bottom" of the stack, which is really just the hardware - a particular connector or cable. Where I think our thinking has been subtly wrong is in thinking that the set of possible values for that lowest-level reference might somehow be *syntactically* more constrained that the other references in the stack. It is NOT more constrained syntactically. The constraint is an *existence* constraint, modulo what the system allows for provisioning of non-existent interfaces. The set of things that might possibly exist in a given system might be describable using a syntactic pattern, but there's really no reason to handle this any differently from other references. My point is that the ultimate lowest "level" - the set of possible cable or connector identifiers, is *not* configuration data as we've been using the term here, although an implementation would hopefully make this information available. Values from this set make up the possible *references* from the lowest configurable layer in the stack. Randy From andy@yumaworks.com Fri Sep 21 09:58:10 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 A3B0521F8549 for ; Fri, 21 Sep 2012 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n36Mjowxkc5T for ; Fri, 21 Sep 2012 09:58:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 122B221F853B for ; Fri, 21 Sep 2012 09:58:09 -0700 (PDT) Received: by qabj40 with SMTP id j40so1541596qab.10 for ; Fri, 21 Sep 2012 09:58:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cKojW3c1am45z4y7udmg9l7w/1yICmhcHurXGQ7EtDg=; b=RuP4FJgMooRFujlK8IchDUiamOmAGS6I7Eqa+TjHBcvRnYxJOO0ecDIvz6dxLdgHVf kAf+Wp4RL0LfkHU6pTSJG+UPmyBueIn74sWSU2p5h+5OK4GSfpi0mnr9j0Rk1A9+18Wm HG+Gg8bNO9kJdix2KVowQAhHAkTchuHi09o6oz7zyKq5uT/6pmYCoY2RmJ4rnR8BUMsv yFVJ3JkFxgPolRhazuqPG0lJ9xEudgFpiNbxogcpv6qEOwGTc16F77m28DjiRpLIcJoA n+FflScw9/9h8+3/0VPinIQzgMoIKA6bulxRmq9jpVfA4ORc314GI4WUuw10DsCiOabH w0TA== MIME-Version: 1.0 Received: by 10.224.185.5 with SMTP id cm5mr13456253qab.87.1348246689450; Fri, 21 Sep 2012 09:58:09 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Fri, 21 Sep 2012 09:58:09 -0700 (PDT) In-Reply-To: <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> Date: Fri, 21 Sep 2012 09:58:09 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnFFMLkD1G1cdpNdVyOBHnNxVGrO50zyS120e02Po7son+RiSqX/INpvm6Hk/jJVYCDFoOR Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 21 Sep 2012 16:58:10 -0000 On Fri, Sep 21, 2012 at 9:58 AM, Randy Presuhn wrote: > Hi - > > I can't help but think that we're thinking about this in > if not the wrong way, at least in a way that makes things > harder than they need to be. > > When one is stitching a stack together, there ends up being > a web of service users and service providers, connected > by references from one more-or-less arbitrarily named > interface to another. Where this hits a rock in the current > discussion is when that reference is to the "bottom" of the > stack, which is really just the hardware - a particular connector > or cable. Where I think our thinking has been subtly wrong is > in thinking that the set of possible values for that lowest-level > reference might somehow be *syntactically* more constrained > that the other references in the stack. > > It is NOT more constrained syntactically. The constraint > is an *existence* constraint, modulo what the system allows > for provisioning of non-existent interfaces. The set of things > that might possibly exist in a given system might be describable > using a syntactic pattern, but there's really no reason to handle > this any differently from other references. > > My point is that the ultimate lowest "level" - the set of possible > cable or connector identifiers, is *not* configuration data as > we've been using the term here, although an implementation would > hopefully make this information available. Values from this set make up > the possible *references* from the lowest configurable layer in > the stack. > Going back to your most relevant list: 1) the system-supplied "local" identifier for an interface 2) the administratively-assigned identifiers used to stitch stacks together 3) "Post-its" for things like "customer" or "cable-id" Are you saying we should not worry about (1)? The system will pre-populate the factory-default config with these interfaces, so an create operation is not that common? > Randy Andy From randy_presuhn@mindspring.com Fri Sep 21 11:15:44 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 D5A6221E80B9 for ; Fri, 21 Sep 2012 11:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6xsm4-4t-Cv for ; Fri, 21 Sep 2012 11:15:44 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEAD21E80B7 for ; Fri, 21 Sep 2012 11:15:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OU9L0HRPkrh1MTyL1cauLv/8CJFNSDhChLg4nRgW6ReHyEG6n31A3HmoE/abNJSf; 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.30.224.193] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TF7lP-0007PM-5Q for netmod@ietf.org; Fri, 21 Sep 2012 14:15:43 -0400 Message-ID: <000401cd9826$27324ec0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120919114451.GA39136@elstar.local><505C71C6.5050000@seguesoft.com><001a01cd981a$573d01c0$6b01a8c0@oemcomputer> Date: Fri, 21 Sep 2012 11:23:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f142769302bafce9d9e16e5c88e641dbef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.224.193 Subject: Re: [netmod] interface keying - call for preferences 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, 21 Sep 2012 18:15:44 -0000 Hi - > From: "Andy Bierman" > To: "Randy Presuhn" > Cc: > Sent: Friday, September 21, 2012 9:58 AM > Subject: Re: [netmod] interface keying - call for preferences > > On Fri, Sep 21, 2012 at 9:58 AM, Randy Presuhn > wrote: > > Hi - > > > > I can't help but think that we're thinking about this in > > if not the wrong way, at least in a way that makes things > > harder than they need to be. > > > > When one is stitching a stack together, there ends up being > > a web of service users and service providers, connected > > by references from one more-or-less arbitrarily named > > interface to another. Where this hits a rock in the current > > discussion is when that reference is to the "bottom" of the > > stack, which is really just the hardware - a particular connector > > or cable. Where I think our thinking has been subtly wrong is > > in thinking that the set of possible values for that lowest-level > > reference might somehow be *syntactically* more constrained > > that the other references in the stack. > > > > It is NOT more constrained syntactically. The constraint > > is an *existence* constraint, modulo what the system allows > > for provisioning of non-existent interfaces. The set of things > > that might possibly exist in a given system might be describable > > using a syntactic pattern, but there's really no reason to handle > > this any differently from other references. > > > > My point is that the ultimate lowest "level" - the set of possible > > cable or connector identifiers, is *not* configuration data as > > we've been using the term here, although an implementation would > > hopefully make this information available. Values from this set make up > > the possible *references* from the lowest configurable layer in > > the stack. > > > > Going back to your most relevant list: > > 1) the system-supplied "local" identifier for an interface > 2) the administratively-assigned identifiers used to stitch stacks together > 3) "Post-its" for things like "customer" or "cable-id" > > Are you saying we should not worry about (1)? > The system will pre-populate the factory-default config with > these interfaces, so an create operation > is not that common? No. Here's the subtle difference. We've been talking as though the system-supplied "local" identifier for an interface is something that is a property of the object we've been calling an interface. 
+-------------------------+
| Interface Object        |
|            "local id"   |
|            other stuff  |
+-------------------------+
As we've already seen, this approach leads to multiple conundrums. What I'm suggesting is that we look at it this way: 
+-----------------------------+
| Interface Object            |          +------------------------------+
|            service provider----------->|                              |
|            other stuff      |          | "hardware" interface, e.g.   |
+-----------------------------+          | physical socket, cable, etc. |
                                         +------------------------------+
In other words, the position where we've been putting "local id" and its ilk should really be just a reference. I put "hardware" interface in quotes, because with virtual machines, etc., etc. it's not really hardware, but its provisioning, installation, etc. tends to take on a very different character from just bringing up another stack. This sort of approach works really nicely with tunneling and other encapsulations, btw. Of course, some will just say "it's turtles all the way down"; you can view this as a bug or a feature, but the reality is that eventually that reference will be to something physical and in a sense not configurable at the level of virtualization in question. Randy From alex@cisco.com Fri Sep 21 18:06: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 8F60421E80C1 for ; Fri, 21 Sep 2012 18:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfsk-etZOKmj for ; Fri, 21 Sep 2012 18:06:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AC2F921E80BF for ; Fri, 21 Sep 2012 18:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5839; q=dns/txt; s=iport; t=1348275986; x=1349485586; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A6zcLUU+UCM/l6hnPoAL5dLgLdisv2gzmILgi4+z6Xc=; b=J224jl6/VB6lq7RSyZnA/4bsMECVEOosqybI6fnU3wQ6w5S81tLs28kH KcHEjYsM1MW7wurYhAdKOA6vvSdsnvlV+bkqe+vbbRgu8dizjUhgjF2V/ sYBUMsaF3Xfy2PcyfTSP2z55tJG10dg1z0lqnWKjOW3gkzoQfO7L9bgsU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMkNXVCtJV2c/2dsb2JhbABFviGBCIIhAQEEEgEnPxACAQgOFBQQMiUBAQQODRqHY5kioBWQYmADpB2BaYJnghc X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="124164589" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 22 Sep 2012 01:06:26 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8M16QSZ018790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Sep 2012 01:06:26 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 20:06:26 -0500 From: "Alexander Clemm (alex)" To: Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwN+9QGAAKS+G1A= Date: Sat, 22 Sep 2012 01:06:25 +0000 Message-ID: References: <20120918.150847.348333610267246619.mbj@tail-f.com> In-Reply-To: <20120918.150847.348333610267246619.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.43] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--38.520200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 22 Sep 2012 01:06:27 -0000 Hi Martin, Thank you for your review! Quick responses inline. --- Alex [...] o Maybe OPSAWG is the right place to do this work? Andy suggested that NETMOD could help other WGs with theier YANG models. I think that would be a good idea for this data model. Of course, this is ultimately for the working group to decide. In our= viewpoint, one thing that is still needed from standardization perspective= to make YANG truly successful is the development of more "content". To ma= ke YANG truly "stick" in the industry, more YANG modules are needed and the= ones that exist must be easy to find. This IMHO makes it preferrable to c= oncentrate/consolidate them in one place rather than scatter them around - = specifically if they concern general-purpose as opposed to very technology/= feature-specific modules. If consolidated in one place, the obvious place = that comes to my mind is this working group. =20 o Is the Intended Status really Informational? Actually it would be good to have this standards track. o All your YANG models should have the markers. Note that the acl model has instead of the proper . Proper markers help tools extract the data models. Agree, we need to fix it. o Running pyang on your data models gives two errors that are easy to fix: acl@2012-08-30.yang:1: warning: unexpected latest revision "2012-08-31" = in acl@2012-08-30.yang, should be 2012-08-30 acl-ip.yang:389: error: type "Comparator" not found in module acl-ip Agree, we need to fix it. o I suggest you try to be consistent in the format of the YANG models (indentation, placement of statements etc.) 'pyang' can help with this - run: pyang -f yang --yang-canonical to get started. This would make the models easier to follow. Agree, we need to fix it. o I did not understand why some ip-related definitions are in acl-ip.yang, and some in acl.yang (and same for mac etc). no comment at this point from our side, we will revisit in our next pa= ss and make sure that design decisions are documented properly =20 o A common pattern in your model is this: leaf ip-source-kind { type IP-Network-Kind ; } choice source-address-host-group { when "ip-source-kind !=3D 'any'"; case mask { when "ip-source-kind =3D 'ip'" ; leaf ip-source-address { ... } leaf ip-source-mask { ... } } case host { when "ip-source-kind =3D 'host'"; leaf ip-source-host-address { ... } } case group { when "ip-source-kind =3D 'group'"; leaf ip-source-group { ... } } } An alternative design which might simplify the model could be to get rid of the discriminator: choice source-address-host-group { case mask { // implies 'ip' kind leaf ip-source-address { ... } leaf ip-source-mask { ... } } case host { // implies 'host' kind leaf ip-source-host-address { ... } } case group { // implies 'group' kind leaf ip-source-group { ... } } case any { // implies 'any' kind leaf ip-any { type empty; } } } =20 We were actually considering the alternative design but, at least in the fi= rst pass, decided against it. Your proposed alternative is from a modeling= perspective certainly elegant. However, it introduces certain "context de= pendencies" - powerful but also a bit more complex because if you want to s= imply know what type of ip-source-kind you have, you cannot simply find out= , but need to know how it is defined (to conclude which type it is). The c= urrent design is more "context independent" - a bit cruder but also simpler= in a way, although of course it necessitates a when statement. =20 This might be a case where a "best practice" for authors might be useful, a= ctually, as these are clearly design alternatives to accomplish the same th= ing in different ways. =20 In this particular case, maybe it makes sense to add a form with a prefix instead of a mask: case prefix { leaf ip-source-subnet { type inet:ip-prefix; } } 10.0.0.1/24 Agree, this makes sense. We will add it. o If seems a bit odd that there's a choice between a remark and filters; this means that you cannot put a comment on an ace that has filters. The model would be simpler if you did: OLD: choice remark-or-filter { case remark { leaf remark { ... } } case filter { container filters { uses ... } } NEW: leaf remark { ... } container filters { uses ... } Or maybe also get rid of the 'filters' container: leaf remark { ... } uses ... The two are not the same. Admittedly, we let the semantics of Cisco CLI de= sign guide us here, in which remarks are truly independent items in an ACL = not tied to a particular ACE; they do not share a sequence number with an A= CE. Clearly a design choice, but one that will make the implementation of = the YANG module (at least in our case) easier. =20 From yihuan@cisco.com Fri Sep 21 18:40: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 D89EB21E8041 for ; Fri, 21 Sep 2012 18:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-iVWk+66Aak for ; Fri, 21 Sep 2012 18:40:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99F21E80D9 for ; Fri, 21 Sep 2012 18:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6933; q=dns/txt; s=iport; t=1348278053; x=1349487653; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z07kRfnXeI5PRoUFt1JH5Pm2QPc+3g7J+XB76Gm5Iz0=; b=MqTkur5jLzWYBi9MyEQwRZ5xcBr4nAppdPYskXlm38GK3jXTp6wkLc8w 844PGj80wjSz0k8WZByfwyecAzHJWCpLPIYQUbOJuPK45ZP6Vl2KW6Zll shXFzbB4zCghpsCW0K9DF/VhU+4XjxBYGAIsx8KNAky6JAFzbrS9QmsJo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPMVXVCtJV2c/2dsb2JhbAA8Cb4hgQiCIgEEAQEBDwEnNAsSAQg2NwslAQEEAQ0FIodjC5kboBEEiy2GFQOVZI45gWmCZ4IX X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="124172715" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 22 Sep 2012 01:40:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8M1er69004420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Sep 2012 01:40:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 20:40:52 -0500 From: "Lisa Huang (yihuan)" To: "Alexander Clemm (alex)" , Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwN+9QGAAKS+G1D//+3SgA== Date: Sat, 22 Sep 2012 01:40:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--49.475700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <31A72CE21FFE594A82711483276743E3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 22 Sep 2012 01:40:55 -0000 Martin, Thanks for your review. Alex has addressed most of your comments. For this comment: >I did not understand why some ip-related definitions are in > acl-ip.yang, and some in acl.yang (and same for mac etc). Point taken. I do see identity ip-acl, arp-acl, mac-acl should move to corresponding acl. I will fix it in next revision. However, some ip-related defition, such as grouping IP-ADDRESS-AND-MASK, needs to stay in acl.yang. This grouping is used by both acl-ip and acl-arp. Acl.yang is the best place I can think of without introduce another yang file. If grouping IP-ADDRESS-AND-MASK stays in acl.yang, the typedef that used by the grouping need to stay as well. Same to grouping MAC-ADDRESS-AND-MASK Thanks, Lisa On 9/21/12 6:06 PM, "Alexander Clemm (alex)" wrote: >Hi Martin, > >Thank you for your review! Quick responses inline. > >--- Alex > >[...] > > >o Maybe OPSAWG is the right place to do this work? Andy suggested > that NETMOD could help other WGs with theier YANG models. I think > that would be a good idea for this data model. > > Of course, this is ultimately for the working group to decide. In >our viewpoint, one thing that is still needed from standardization >perspective to make YANG truly successful is the development of more >"content". To make YANG truly "stick" in the industry, more YANG modules >are needed and the ones that exist must be easy to find. This IMHO makes >it preferrable to concentrate/consolidate them in one place rather than >scatter them around - specifically if they concern general-purpose as >opposed to very technology/feature-specific modules. If consolidated in >one place, the obvious place that comes to my mind is this working group. >=20 > > >o Is the Intended Status really Informational? > > Actually it would be good to have this standards track. > > >o All your YANG models should have the > markers. Note that the acl model has instead of the > proper . Proper markers help tools extract the data > models. > > Agree, we need to fix it. > > >o Running pyang on your data models gives two errors that are easy to > fix: > > acl@2012-08-30.yang:1: warning: unexpected latest revision >"2012-08-31" in acl@2012-08-30.yang, should be 2012-08-30 > > acl-ip.yang:389: error: type "Comparator" not found in module acl-ip > > Agree, we need to fix it. > > >o I suggest you try to be consistent in the format of the > YANG models (indentation, placement of statements etc.) 'pyang' can > help with this - run: > > pyang -f yang --yang-canonical > > to get started. This would make the models easier to follow. > > Agree, we need to fix it. > > >o I did not understand why some ip-related definitions are in > acl-ip.yang, and some in acl.yang (and same for mac etc). > > no comment at this point from our side, we will revisit in our next >pass and make sure that design decisions are documented properly >=20 > >o A common pattern in your model is this: > > leaf ip-source-kind { > type IP-Network-Kind ; > } > choice source-address-host-group { > when "ip-source-kind !=3D 'any'"; > case mask { > when "ip-source-kind =3D 'ip'" ; > leaf ip-source-address { ... } > leaf ip-source-mask { ... } > } > case host { > when "ip-source-kind =3D 'host'"; > leaf ip-source-host-address { ... } > } > case group { > when "ip-source-kind =3D 'group'"; > leaf ip-source-group { ... } > } > } > > An alternative design which might simplify the model could be to get > rid of the discriminator: > > choice source-address-host-group { > case mask { // implies 'ip' kind > leaf ip-source-address { ... } > leaf ip-source-mask { ... } > } > case host { // implies 'host' kind > leaf ip-source-host-address { ... } > } > case group { // implies 'group' kind > leaf ip-source-group { ... } > } > case any { // implies 'any' kind > leaf ip-any { type empty; } > } > } > =20 > >We were actually considering the alternative design but, at least in the >first pass, decided against it. Your proposed alternative is from a >modeling perspective certainly elegant. However, it introduces certain >"context dependencies" - powerful but also a bit more complex because if >you want to simply know what type of ip-source-kind you have, you cannot >simply find out, but need to know how it is defined (to conclude which >type it is). The current design is more "context independent" - a bit >cruder but also simpler in a way, although of course it necessitates a >when statement. =20 > >This might be a case where a "best practice" for authors might be useful, >actually, as these are clearly design alternatives to accomplish the same >thing in different ways. > > > > In this particular case, maybe it makes sense to add a form with a > prefix instead of a mask: > > case prefix { > leaf ip-source-subnet { > type inet:ip-prefix; > } > } > > 10.0.0.1/24 > > Agree, this makes sense. We will add it. > > > o If seems a bit odd that there's a choice between a remark and > filters; this means that you cannot put a comment on an ace that > has filters. The model would be simpler if you did: > > OLD: > > choice remark-or-filter { > case remark { > leaf remark { ... } > } > case filter { > container filters { uses ... } > } > > NEW: > > leaf remark { ... } > container filters { uses ... } > > Or maybe also get rid of the 'filters' container: > > leaf remark { ... } > uses ... > > >The two are not the same. Admittedly, we let the semantics of Cisco CLI >design guide us here, in which remarks are truly independent items in an >ACL not tied to a particular ACE; they do not share a sequence number >with an ACE. Clearly a design choice, but one that will make the >implementation of the YANG module (at least in our case) easier. > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Sat Sep 22 10:29:12 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 66D1621F8690 for ; Sat, 22 Sep 2012 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMNtIvwBLrOe for ; Sat, 22 Sep 2012 10:29:12 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA26521F8624 for ; Sat, 22 Sep 2012 10:29:11 -0700 (PDT) Received: by qcac10 with SMTP id c10so3934080qca.31 for ; Sat, 22 Sep 2012 10:29:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/KuEEn4dsn7IcoBh7iZdxDtgCZ6y5AXe5cXYvlup0YM=; b=GNUYv2r+WSAlPNfA82iyh4GnmOv5E/6BRojsVZB32+TNUbo1yanNwKW7IrqVI+gZ67 vxubIkLmUSE5X3U4k/zRNA/Ygb28fQJ+eBxny5zbk6Tu2l1XZj/VOPDsN2e0wVagZmnu 1HeuByaAPGspr0XMN4PgWkyrrU1wn4YN+Cyw/ZLf2vP6KKxztqU3Vy5uCJSApiJu/m8D oNMNa+g9RnJyzv3Ky22OgddiW82fD/oliG9sKAh0xPvokdS43IjLR/t4l+VvquMqt3E9 IOauMwDHlCVL8JXySDMkqlzKANZeUMLNryA2OsYuxTJ29aRsXFyuuC4vjW2yo4Xa6HTD NsjQ== MIME-Version: 1.0 Received: by 10.224.177.15 with SMTP id bg15mr20556597qab.85.1348334951310; Sat, 22 Sep 2012 10:29:11 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Sat, 22 Sep 2012 10:29:11 -0700 (PDT) In-Reply-To: References: <20120918.150847.348333610267246619.mbj@tail-f.com> Date: Sat, 22 Sep 2012 10:29:11 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn1FxleeJyCqay8Fv3g5Q5F78DX7e5yCebcbk0b7xfiaxB3+SM3swZFnwm7O2y0KswJ7Gq9 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 22 Sep 2012 17:29:12 -0000 ..... > o A common pattern in your model is this: > > leaf ip-source-kind { > type IP-Network-Kind ; > } > choice source-address-host-group { > when "ip-source-kind != 'any'"; > case mask { > when "ip-source-kind = 'ip'" ; > leaf ip-source-address { ... } > leaf ip-source-mask { ... } > } > case host { > when "ip-source-kind = 'host'"; > leaf ip-source-host-address { ... } > } > case group { > when "ip-source-kind = 'group'"; > leaf ip-source-group { ... } > } > } > > An alternative design which might simplify the model could be to get > rid of the discriminator: > > choice source-address-host-group { > case mask { // implies 'ip' kind > leaf ip-source-address { ... } > leaf ip-source-mask { ... } > } > case host { // implies 'host' kind > leaf ip-source-host-address { ... } > } > case group { // implies 'group' kind > leaf ip-source-group { ... } > } > case any { // implies 'any' kind > leaf ip-any { type empty; } > } > } > I have a 3rd alternative, which IMO uses the correct YANG to capture the intent -- since the client provides ip-source-kind it knows which case to provide as well. leaf ip-source-kind { type IP-Network-Kind ; } choice source-address-host-group { case mask { must "ip-source-kind = 'ip'" ; leaf ip-source-address { ... } leaf ip-source-mask { ... } } case host { must "ip-source-kind = 'host'"; leaf ip-source-host-address { ... } } case group { must "ip-source-kind = 'group'"; leaf ip-source-group { ... } } } Andy From mbj@tail-f.com Sun Sep 23 13:00: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 4546E21F84E4 for ; Sun, 23 Sep 2012 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo3G1B7Ju3Jv for ; Sun, 23 Sep 2012 13:00:55 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B929221F84A1 for ; Sun, 23 Sep 2012 13:00:55 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7163E1200050; Sun, 23 Sep 2012 22:00:53 +0200 (CEST) Date: Sun, 23 Sep 2012 22:00:52 +0200 (CEST) Message-Id: <20120923.220052.492488023.mbj@tail-f.com> To: yihuan@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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: Sun, 23 Sep 2012 20:00:56 -0000 Hi, "Lisa Huang (yihuan)" wrote: > Martin, > > Thanks for your review. Alex has addressed most of your comments. For this > comment: > > >I did not understand why some ip-related definitions are in > > acl-ip.yang, and some in acl.yang (and same for mac etc). > > Point taken. I do see identity ip-acl, arp-acl, mac-acl should move to > corresponding acl. I will fix it in next revision. > > However, some ip-related defition, such as grouping IP-ADDRESS-AND-MASK, > needs to stay in acl.yang. This grouping is used by both acl-ip and > acl-arp. It could be moved to acl-ip.yang, and then acl-arp would import acl-ip (and similar for MAC-ADDRESS-AND-MASK). /martin From mbj@tail-f.com Sun Sep 23 13:04: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 4D6CE21F84DD for ; Sun, 23 Sep 2012 13:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY1ymY4xn34O for ; Sun, 23 Sep 2012 13:04:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C18AF21F8456 for ; Sun, 23 Sep 2012 13:04:25 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 12E5F1200050; Sun, 23 Sep 2012 22:04:25 +0200 (CEST) Date: Sun, 23 Sep 2012 22:04:24 +0200 (CEST) Message-Id: <20120923.220424.146733601.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20120918.150847.348333610267246619.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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: Sun, 23 Sep 2012 20:04:26 -0000 Andy Bierman wrote: > ..... > > o A common pattern in your model is this: > > > > leaf ip-source-kind { > > type IP-Network-Kind ; > > } > > choice source-address-host-group { > > when "ip-source-kind != 'any'"; > > case mask { > > when "ip-source-kind = 'ip'" ; > > leaf ip-source-address { ... } > > leaf ip-source-mask { ... } > > } > > case host { > > when "ip-source-kind = 'host'"; > > leaf ip-source-host-address { ... } > > } > > case group { > > when "ip-source-kind = 'group'"; > > leaf ip-source-group { ... } > > } > > } > > > > An alternative design which might simplify the model could be to get > > rid of the discriminator: > > > > choice source-address-host-group { > > case mask { // implies 'ip' kind > > leaf ip-source-address { ... } > > leaf ip-source-mask { ... } > > } > > case host { // implies 'host' kind > > leaf ip-source-host-address { ... } > > } > > case group { // implies 'group' kind > > leaf ip-source-group { ... } > > } > > case any { // implies 'any' kind > > leaf ip-any { type empty; } > > } > > } > > > > I have a 3rd alternative, which IMO uses the correct YANG > to capture the intent -- since the client provides ip-source-kind > it knows which case to provide as well. I don't understand the reasoning. It seems you are saying that there are situations in which the client does not provide the data and it thus doesn't know which case to provide? /martin From mbj@tail-f.com Sun Sep 23 13:18:39 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 BD70921F8518 for ; Sun, 23 Sep 2012 13:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h71IH7indK+G for ; Sun, 23 Sep 2012 13:18:39 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DF32821F8516 for ; Sun, 23 Sep 2012 13:18:38 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D314C1200050; Sun, 23 Sep 2012 22:18:37 +0200 (CEST) Date: Sun, 23 Sep 2012 22:18:37 +0200 (CEST) Message-Id: <20120923.221837.440628213.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: <20120918.150847.348333610267246619.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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: Sun, 23 Sep 2012 20:18:39 -0000 "Alexander Clemm (alex)" wrote: > o A common pattern in your model is this: > > leaf ip-source-kind { > type IP-Network-Kind ; > } > choice source-address-host-group { > when "ip-source-kind != 'any'"; > case mask { > when "ip-source-kind = 'ip'" ; > leaf ip-source-address { ... } > leaf ip-source-mask { ... } > } > case host { > when "ip-source-kind = 'host'"; > leaf ip-source-host-address { ... } > } > case group { > when "ip-source-kind = 'group'"; > leaf ip-source-group { ... } > } > } > > An alternative design which might simplify the model could be to get > rid of the discriminator: > > choice source-address-host-group { > case mask { // implies 'ip' kind > leaf ip-source-address { ... } > leaf ip-source-mask { ... } > } > case host { // implies 'host' kind > leaf ip-source-host-address { ... } > } > case group { // implies 'group' kind > leaf ip-source-group { ... } > } > case any { // implies 'any' kind > leaf ip-any { type empty; } > } > } > > > We were actually considering the alternative design but, at least in the first > pass, decided against it. Your proposed alternative is from a modeling > perspective certainly elegant. However, it introduces certain "context > dependencies" - powerful but also a bit more complex because if you want to > simply know what type of ip-source-kind you have, you cannot simply find out, > but need to know how it is defined (to conclude which type it is). The current > design is more "context independent" - a bit cruder but also simpler in a way, > although of course it necessitates a when statement. > > This might be a case where a "best practice" for authors might be useful, > actually, as these are clearly design alternatives to accomplish the same thing > in different ways. > Here are three alternatives: (A) leaf discriminator { type enumeration { enum e1 { ... } ... enum en { ... } } choice a { case c1 { when "discriminator = 'e1'; // c1 data nodes } ... case cn { when "discriminator = 'en'; // cn data nodes } } (B) choice a { case c1 { // implies e1 // c1 data nodes } ... case cn { // implies en // cn data nodes } } (C) choice a { case c1 { container e1 { // c1 data nodes } } ... case cn { container e1 { // cn data nodes } } } (an alternative to A is to use 'must' instead of 'when', as Andy suggested. but they both result in the same structure) In your case I suggested pattern (B). I think this pattern can be useful if there are not too many nodes in each case. In this case there are one or two nodes, and they are always (?) mandatory, which means that it is trivial to figure out which case is actually in use. Pattern (C) is more explicit, but introduces another nesting level. IMO, pattern (A) is the most complex, or less direct, since it involves the additional discriminator node, and 'when' (or 'must') statements. I think CLIs often use a direct and simple model, so it can often be useful to think about the data model design from a CLI perspective. Which information is needed, and how is it given in the CLI? /martin From andy@yumaworks.com Sun Sep 23 13:26:48 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 04D2C21F8516 for ; Sun, 23 Sep 2012 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKeaeunAfeJ8 for ; Sun, 23 Sep 2012 13:26:47 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73321F8501 for ; Sun, 23 Sep 2012 13:26:47 -0700 (PDT) Received: by qaec10 with SMTP id c10so2582878qae.10 for ; Sun, 23 Sep 2012 13:26:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=G90eBMSYXEh3Z3GC1VZbe7+Jgmu1YwFvqRZyW/YdpLo=; b=IFCXgpjMqq8yK5rZKtz5l6NfLw3ESiiGQa3Jgy/rDz798W4cEGmdQ+sTQox0vgRzau qQ2GQ58vZdYgxaWFlYMOiFr98dUYQtWyqyw8jI/foZpDwV2ouGGT+jLZgRDLJEaB6TPb 0di/+yeCC07gTRb6EkYZ3r0K7uvvWCZzLZrZ6nvZBbjEUnoluO+x2jFfTrGbt/xBnRGQ WlySg/9snucBfBejybnc5W2YbP45HrESUeKeKd6C8FlzyQHO6SLO/BCjfKUPIZPLZi2Q 2xV5KXDueMfTzclOVg9/2za3tDRoXWntnAPK1+M0i0Nu984lR72B7+DPvW3qfG35xwry 4yVA== MIME-Version: 1.0 Received: by 10.229.135.11 with SMTP id l11mr7595498qct.116.1348432006589; Sun, 23 Sep 2012 13:26:46 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Sun, 23 Sep 2012 13:26:46 -0700 (PDT) In-Reply-To: <20120923.221837.440628213.mbj@tail-f.com> References: <20120918.150847.348333610267246619.mbj@tail-f.com> <20120923.221837.440628213.mbj@tail-f.com> Date: Sun, 23 Sep 2012 13:26:46 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlY5dmrIcV7r1i6ECicXSR6/9wA0oGYfMpkG+hXeTF/wqIZYzAus/movrQo0oBQIrERSrot Cc: netmod@ietf.org Subject: Re: [netmod] YANG module for ACL configuration 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: Sun, 23 Sep 2012 20:26:48 -0000 On Sun, Sep 23, 2012 at 1:18 PM, Martin Bjorklund wrote: > "Alexander Clemm (alex)" wrote: >> o A common pattern in your model is this: >> >> leaf ip-source-kind { >> type IP-Network-Kind ; >> } >> choice source-address-host-group { >> when "ip-source-kind != 'any'"; >> case mask { >> when "ip-source-kind = 'ip'" ; >> leaf ip-source-address { ... } >> leaf ip-source-mask { ... } >> } >> case host { >> when "ip-source-kind = 'host'"; >> leaf ip-source-host-address { ... } >> } >> case group { >> when "ip-source-kind = 'group'"; >> leaf ip-source-group { ... } >> } >> } >> >> An alternative design which might simplify the model could be to get >> rid of the discriminator: >> >> choice source-address-host-group { >> case mask { // implies 'ip' kind >> leaf ip-source-address { ... } >> leaf ip-source-mask { ... } >> } >> case host { // implies 'host' kind >> leaf ip-source-host-address { ... } >> } >> case group { // implies 'group' kind >> leaf ip-source-group { ... } >> } >> case any { // implies 'any' kind >> leaf ip-any { type empty; } >> } >> } >> >> >> We were actually considering the alternative design but, at least in the first >> pass, decided against it. Your proposed alternative is from a modeling >> perspective certainly elegant. However, it introduces certain "context >> dependencies" - powerful but also a bit more complex because if you want to >> simply know what type of ip-source-kind you have, you cannot simply find out, >> but need to know how it is defined (to conclude which type it is). The current >> design is more "context independent" - a bit cruder but also simpler in a way, >> although of course it necessitates a when statement. >> >> This might be a case where a "best practice" for authors might be useful, >> actually, as these are clearly design alternatives to accomplish the same thing >> in different ways. >> > > Here are three alternatives: > > (A) > > leaf discriminator { > type enumeration { > enum e1 { ... } > ... > enum en { ... } > } > choice a { > case c1 { > when "discriminator = 'e1'; > // c1 data nodes > } > ... > case cn { > when "discriminator = 'en'; > // cn data nodes > } > } > > > (B) > choice a { > case c1 { > // implies e1 > // c1 data nodes > } > ... > case cn { > // implies en > // cn data nodes > } > } > > > (C) > > choice a { > case c1 { > container e1 { > // c1 data nodes > } > } > ... > case cn { > container e1 { > // cn data nodes > } > } > } > > > > (an alternative to A is to use 'must' instead of 'when', as Andy > suggested. but they both result in the same structure) > > > In your case I suggested pattern (B). I think this pattern can be > useful if there are not too many nodes in each case. In this case > there are one or two nodes, and they are always (?) mandatory, which > means that it is trivial to figure out which case is actually in use. > > Pattern (C) is more explicit, but introduces another nesting level. > > IMO, pattern (A) is the most complex, or less direct, since it > involves the additional discriminator node, and 'when' (or 'must') > statements. > It is useful to have the discriminator node so it can be used in other unforeseen use-cases in when/must statements. IMO, providing a case for the wrong discriminator should be an error (must) not silently dropped nodes (when). (B) -- no discriminator -- cannot be used to enforce the correct case. You can add text like "This object is ignored unless foo = 3", but we have must/when for a better solution than this one. > I think CLIs often use a direct and simple model, so it can often be > useful to think about the data model design from a CLI perspective. > Which information is needed, and how is it given in the CLI? > > > /martin Andy From mbj@tail-f.com Sun Sep 23 13:33: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 6038821F8501 for ; Sun, 23 Sep 2012 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyR3TKT8XRnF for ; Sun, 23 Sep 2012 13:33:40 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D17D021F84F5 for ; Sun, 23 Sep 2012 13:33:39 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id AB27F12008B7; Sun, 23 Sep 2012 22:33:38 +0200 (CEST) Date: Sun, 23 Sep 2012 22:33:38 +0200 (CEST) Message-Id: <20120923.223338.368769785.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20120923.221837.440628213.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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: Sun, 23 Sep 2012 20:33:40 -0000 Andy Bierman wrote: > It is useful to have the discriminator node so it can be used > in other unforeseen use-cases in when/must statements. > > IMO, providing a case for the wrong discriminator should > be an error (must) not silently dropped nodes (when). If the discriminator is set to 'e1' and the client provides nodes for case 'c2', this is an error even for the 'when' case. > (B) -- no discriminator -- cannot be used to enforce > the correct case. You can add text like "This object is > ignored unless foo = 3", but we have must/when for > a better solution than this one. The point with (B) is that the discriminator is not needed. If there are just one or two nodes in each case, why bother with a discriminator node, it just makes things more complex. I absolutely agree that there are cases where a discriminator node is useful, but I also believe that there are cases wher it is not needed - otherwise we shouldn't have had choice the way it is in YANG today. /martin From yihuan@cisco.com Sun Sep 23 21:57:59 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 035EC21F8555 for ; Sun, 23 Sep 2012 21:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJhJ8yXJjSEQ for ; Sun, 23 Sep 2012 21:57:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9A73C21F845F for ; Sun, 23 Sep 2012 21:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=991; q=dns/txt; s=iport; t=1348462672; x=1349672272; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GkKIUq5L/lG6xLRY1O5z5rsq6ITtH/gNGe0zikGB9Q4=; b=d6ELLzd1oDFY6Laozl1cpOQXWRlhVlf8O6T0fB9PsoGgx0eht7la8nKX joyxfv24YHeOLVpdVYmhRt8N2gv8rBupaPq5KosriLgfWz9VDKtIFckh0 nmJt1+iUxRT+9ue7Ex7QRU653eo3kmyvC07EtOYMVHjRsbWgmc5kUSmIC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAC/nX1CtJV2b/2dsb2JhbAA7CYVEuGuBCIIgAQEBBBIBJzgHEgEIDgoeQiUBAQQOBSKHY5kAnxuLLYYZA5VljjqBaYJnghc X-IronPort-AV: E=Sophos;i="4.80,473,1344211200"; d="scan'208";a="124311106" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 24 Sep 2012 04:57:52 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8O4vq2d012356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Sep 2012 04:57:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Sun, 23 Sep 2012 23:57:51 -0500 From: "Lisa Huang (yihuan)" To: Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwN+9QGAAKS+G1D//+3SgIADOwcAgAAgrAA= Date: Mon, 24 Sep 2012 04:57:50 +0000 Message-ID: In-Reply-To: <20120923.220052.492488023.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.166.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19204.004 x-tm-as-result: No--33.187800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 24 Sep 2012 04:57:59 -0000 Acl-ip and acl-arp has no other relationship except both could filter on ip address. From this point of view, it does not quite make sense for acl-arp to import acl-ip. On 9/23/12 1:00 PM, "Martin Bjorklund" wrote: >Hi, > >"Lisa Huang (yihuan)" wrote: >> Martin, >>=20 >> Thanks for your review. Alex has addressed most of your comments. For >>this >> comment: >>=20 >> >I did not understand why some ip-related definitions are in >> > acl-ip.yang, and some in acl.yang (and same for mac etc). >>=20 >> Point taken. I do see identity ip-acl, arp-acl, mac-acl should move to >> corresponding acl. I will fix it in next revision. >>=20 >> However, some ip-related defition, such as grouping IP-ADDRESS-AND-MASK, >> needs to stay in acl.yang. This grouping is used by both acl-ip and >> acl-arp. > >It could be moved to acl-ip.yang, and then acl-arp would import >acl-ip (and similar for MAC-ADDRESS-AND-MASK). > > >/martin From jernej.tuljak@mg-soft.si Sun Sep 23 23:21: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 7644F21F8587 for ; Sun, 23 Sep 2012 23:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llZFXIl+M8OU for ; Sun, 23 Sep 2012 23:21:18 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7127A21F8555 for ; Sun, 23 Sep 2012 23:21:18 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8O6L9ge028348; Mon, 24 Sep 2012 08:21:10 +0200 Message-ID: <505FFBD5.5060808@mg-soft.com> Date: Mon, 24 Sep 2012 08:21:09 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <20120921154850.6A92C72E038@rfc-editor.org> <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> In-Reply-To: <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, lhotka@cesnet.cz, rbonica@juniper.net, RFC Errata System Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 06:21:19 -0000 Hi, actually the notes section of my errata contains a typo. Cardinality of unique-stmt is 0..n (not 0..1). That should be corrected. Jernej Dne 21.9.2012 18:04, piše Ladislav Lhotka: > Hi, > > this erratum should be verified, the reporter is absolutely right. > > Ladislav Lhotka, editor of RFC 6110 > > On Sep 21, 2012, at 5:48 PM, RFC Errata System wrote: > >> The following errata report has been submitted for RFC6110, >> "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6110&eid=3362 >> >> -------------------------------------- >> Type: Technical >> Reported by: Jernej Tuljak >> >> Section: 10.55. >> >> Original Text >> ------------- >> The 'unique' Statement >> >> This statement is mapped to the @nma:unique attribute. ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @nma:unique attribute. >> >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following attribute/value pair: >> >> nma:unique="ex:foo ex:bar/ex:baz" >> >> Corrected Text >> -------------- >> The 'unique' Statement >> >> This statement is mapped to the element. It has one >> mandatory attribute @key (with no namespace). ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @key attribute. >> >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following element: >> >> >> >> Notes >> ----- >> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6110 (draft-ietf-netmod-dsdl-map-10) >> -------------------------------------- >> Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content >> Publication Date : February 2011 >> Author(s) : L. Lhotka, Ed. >> Category : PROPOSED STANDARD >> Source : NETCONF Data Modeling Language >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG > -- > Ladislav Lhotka > PGP Key ID: E74E8C0C > > > > From ladislav@lhotka.name Fri Sep 21 09:04: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 24AA021E8083 for ; Fri, 21 Sep 2012 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJUsc0OCA-bc for ; Fri, 21 Sep 2012 09:04:42 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B456A21E8082 for ; Fri, 21 Sep 2012 09:04:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8B05E540466; Fri, 21 Sep 2012 18:04:36 +0200 (CEST) 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 Y3gzHMsudn0E; Fri, 21 Sep 2012 18:04:11 +0200 (CEST) Received: from [172.29.2.202] (unknown [10.107.191.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6C41C54022E; Fri, 21 Sep 2012 18:04:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120921154850.6A92C72E038@rfc-editor.org> Date: Fri, 21 Sep 2012 18:04:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> References: <20120921154850.6A92C72E038@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1486) X-Mailman-Approved-At: Mon, 24 Sep 2012 01:22:10 -0700 Cc: netmod@ietf.org, lhotka@cesnet.cz, rbonica@juniper.net, jernej.tuljak@mg-soft.com Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 21 Sep 2012 16:14:07 -0000 Hi, this erratum should be verified, the reporter is absolutely right. Ladislav Lhotka, editor of RFC 6110 =20 On Sep 21, 2012, at 5:48 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6110, > "Mapping YANG to Document Schema Definition Languages and Validating = NETCONF Content". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6110&eid=3D3362 >=20 > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak >=20 > Section: 10.55. >=20 > Original Text > ------------- > The 'unique' Statement >=20 > This statement is mapped to the @nma:unique attribute. ARGUMENT = MUST > be translated so that every node identifier in each of its = components > is prefixed with the namespace prefix of the local module, unless = the > prefix is already present. The result of this translation then > becomes the value of the @nma:unique attribute. >=20 > For example, assuming that the local module prefix is "ex", >=20 > unique "foo ex:bar/baz" >=20 > is mapped to the following attribute/value pair: >=20 > nma:unique=3D"ex:foo ex:bar/ex:baz" >=20 > Corrected Text > -------------- > The 'unique' Statement >=20 > This statement is mapped to the element. It has one > mandatory attribute @key (with no namespace). ARGUMENT MUST > be translated so that every node identifier in each of its = components > is prefixed with the namespace prefix of the local module, unless = the > prefix is already present. The result of this translation then > becomes the value of the @key attribute. >=20 > For example, assuming that the local module prefix is "ex", >=20 > unique "foo ex:bar/baz" >=20 > is mapped to the following element: >=20 > >=20 > Notes > ----- > A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be = mapped into a single @nma:unique attribute. It should be mapped into an = element instead, much like the must-stmt. Additional changes may be = required throughout the document. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6110 (draft-ietf-netmod-dsdl-map-10) > -------------------------------------- > Title : Mapping YANG to Document Schema Definition = Languages and Validating NETCONF Content > Publication Date : February 2011 > Author(s) : L. Lhotka, Ed. > Category : PROPOSED STANDARD > Source : NETCONF Data Modeling Language > Area : Operations and Management > Stream : IETF > Verifying Party : IESG -- Ladislav Lhotka PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Sep 24 01:34: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 1184821F85A4 for ; Mon, 24 Sep 2012 01:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpJiN2dVoRaA for ; Mon, 24 Sep 2012 01:34:36 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1474321F859B for ; Mon, 24 Sep 2012 01:34:36 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 480CC1200048; Mon, 24 Sep 2012 10:34:34 +0200 (CEST) Date: Mon, 24 Sep 2012 10:34:34 +0200 (CEST) Message-Id: <20120924.103434.156371276890823415.mbj@tail-f.com> To: ladislav@lhotka.name From: Martin Bjorklund In-Reply-To: <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> References: <20120921154850.6A92C72E038@rfc-editor.org> <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rbonica@juniper.net, lhotka@cesnet.cz, jernej.tuljak@mg-soft.com, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 08:34:37 -0000 Ladislav Lhotka wrote: > Hi, > > this erratum should be verified, the reporter is absolutely right. If I am not mistaken, this errata changes the encoding of "unique" from an XML attribute to an XML element. Can we really make such changes in an errata? /martin > > Ladislav Lhotka, editor of RFC 6110 > > On Sep 21, 2012, at 5:48 PM, RFC Errata System wrote: > > > > > The following errata report has been submitted for RFC6110, > > "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6110&eid=3362 > > > > -------------------------------------- > > Type: Technical > > Reported by: Jernej Tuljak > > > > Section: 10.55. > > > > Original Text > > ------------- > > The 'unique' Statement > > > > This statement is mapped to the @nma:unique attribute. ARGUMENT MUST > > be translated so that every node identifier in each of its components > > is prefixed with the namespace prefix of the local module, unless the > > prefix is already present. The result of this translation then > > becomes the value of the @nma:unique attribute. > > > > For example, assuming that the local module prefix is "ex", > > > > unique "foo ex:bar/baz" > > > > is mapped to the following attribute/value pair: > > > > nma:unique="ex:foo ex:bar/ex:baz" > > > > Corrected Text > > -------------- > > The 'unique' Statement > > > > This statement is mapped to the element. It has one > > mandatory attribute @key (with no namespace). ARGUMENT MUST > > be translated so that every node identifier in each of its components > > is prefixed with the namespace prefix of the local module, unless the > > prefix is already present. The result of this translation then > > becomes the value of the @key attribute. > > > > For example, assuming that the local module prefix is "ex", > > > > unique "foo ex:bar/baz" > > > > is mapped to the following element: > > > > > > > > Notes > > ----- > > A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6110 (draft-ietf-netmod-dsdl-map-10) > > -------------------------------------- > > Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content > > Publication Date : February 2011 > > Author(s) : L. Lhotka, Ed. > > Category : PROPOSED STANDARD > > Source : NETCONF Data Modeling Language > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > -- > Ladislav Lhotka > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Mon Sep 24 01:35: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 56D0321F85AA for ; Mon, 24 Sep 2012 01:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHTpFLjuyMz1 for ; Mon, 24 Sep 2012 01:35:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56F21F85A8 for ; Mon, 24 Sep 2012 01:35:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A031520C1B; Mon, 24 Sep 2012 10:35:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xCwGQXxYZPIL; Mon, 24 Sep 2012 10:35:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02D4520C1E; Mon, 24 Sep 2012 10:35:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E4A321E5585; Mon, 24 Sep 2012 10:35:32 +0200 (CEST) Date: Mon, 24 Sep 2012 10:35:32 +0200 From: Juergen Schoenwaelder To: jernej.tuljak@mg-soft.com Message-ID: <20120924083532.GB7097@elstar.local> Mail-Followup-To: jernej.tuljak@mg-soft.com, lhotka@cesnet.cz, rbonica@juniper.net, bclaise@cisco.com, david.kessens@nsn.com, netmod@ietf.org References: <20120921154850.6A92C72E038@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120921154850.6A92C72E038@rfc-editor.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rbonica@juniper.net, lhotka@cesnet.cz, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 08:35:40 -0000 On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: [...] > Notes > ----- > A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. > Would it make sense to identify the other changes that may be required? I quick search leads to: - Table 2 - 2nd paragraph of section 11.2 - section 12.16 (including its title) - definition of unique-attribute in appendix A Anything else I am missing? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Sep 24 01:45: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 A050921F8557 for ; Mon, 24 Sep 2012 01:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COOThqynhn9D for ; Mon, 24 Sep 2012 01:45:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3221F854A for ; Mon, 24 Sep 2012 01:45:55 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3546920C4F; Mon, 24 Sep 2012 10:45:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wHqIf_26pzPU; Mon, 24 Sep 2012 10:45:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 944DF20C4C; Mon, 24 Sep 2012 10:45:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6912621E568F; Mon, 24 Sep 2012 10:45:50 +0200 (CEST) Date: Mon, 24 Sep 2012 10:45:50 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120924084550.GA7231@elstar.local> Mail-Followup-To: Martin Bjorklund , ladislav@lhotka.name, rbonica@juniper.net, lhotka@cesnet.cz, jernej.tuljak@mg-soft.com, netmod@ietf.org, rfc-editor@rfc-editor.org References: <20120921154850.6A92C72E038@rfc-editor.org> <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> <20120924.103434.156371276890823415.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120924.103434.156371276890823415.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org, ladislav@lhotka.name, rbonica@juniper.net, lhotka@cesnet.cz, jernej.tuljak@mg-soft.com, rfc-editor@rfc-editor.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 08:45:56 -0000 On Mon, Sep 24, 2012 at 10:34:34AM +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi, > > > > this erratum should be verified, the reporter is absolutely right. > > If I am not mistaken, this errata changes the encoding of "unique" > from an XML attribute to an XML element. Can we really make such > changes in an errata? Good question. The bug, however, seems to be clear. I think it is important to figure out what kind of solution those implementing/using this specification really want. Some backwards compatible options: - You can create a kludge where the case with only one unique statement is handled as currently documented and additional unique statements are dealt with differently. - You can create an update that says unique statement are handled with XML elements but in the special case of only one unique statement, the attribute is present in addition to the XML elements, essentially introducing the xml element solution and deprecating the use of an attribute. Perhaps there are other options. Lets figure out which solution is preferred and then we can see how to properly document that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ladislav@lhotka.name Mon Sep 24 01:50: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 34DE421F85AA for ; Mon, 24 Sep 2012 01:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaKQ0btE6xp6 for ; Mon, 24 Sep 2012 01:50:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7023021F85A8 for ; Mon, 24 Sep 2012 01:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1E69F5405F4; Mon, 24 Sep 2012 10:50:10 +0200 (CEST) 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 ZMtbQqKI13wo; Mon, 24 Sep 2012 10:50:04 +0200 (CEST) Received: from [172.29.2.201] (unknown [10.107.191.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2748B54030F; Mon, 24 Sep 2012 10:50:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120924083532.GB7097@elstar.local> Date: Mon, 24 Sep 2012 10:49:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Mailman-Approved-At: Mon, 24 Sep 2012 01:51:55 -0700 Cc: netmod@ietf.org, rbonica@juniper.net, lhotka@cesnet.cz, jernej.tuljak@mg-soft.com Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 08:50:17 -0000 On Sep 24, 2012, at 10:35 AM, Juergen Schoenwaelder = wrote: > On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >=20 > [...] >=20 >> Notes >> ----- >> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot = be mapped into a single @nma:unique attribute. It should be mapped into = an element instead, much like the must-stmt. Additional changes may be = required throughout the document. >>=20 >=20 > Would it make sense to identify the other changes that may be > required? I quick search leads to: >=20 > - Table 2 > - 2nd paragraph of section 11.2 > - section 12.16 (including its title) > - definition of unique-attribute in appendix A Yes, this list (+ section 10.55) is all that needs to be changed. Lada >=20 > Anything else I am missing? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Sep 24 02:07: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 EC5B721F85C0 for ; Mon, 24 Sep 2012 02:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC4MVpKC-z84 for ; Mon, 24 Sep 2012 02:07:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A52721F85AD for ; Mon, 24 Sep 2012 02:07:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 675FB20C32; Mon, 24 Sep 2012 11:07:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2bxlPzuCbwnN; Mon, 24 Sep 2012 11:07:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C44A220C2A; Mon, 24 Sep 2012 11:07:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C434221E58C6; Mon, 24 Sep 2012 11:06:55 +0200 (CEST) Date: Mon, 24 Sep 2012 11:06:55 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20120924090655.GB7231@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> <000401cd9826$27324ec0$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401cd9826$27324ec0$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 09:07:04 -0000 On Fri, Sep 21, 2012 at 11:23:07AM -0700, Randy Presuhn wrote: > No. Here's the subtle difference. We've been talking as though > the system-supplied "local" identifier for an interface is something > that is a property of the object we've been calling an interface. > > 
> +-------------------------+
> | Interface Object        |
> |            "local id"   |
> |            other stuff  |
> +-------------------------+
>
> > As we've already seen, this approach leads to multiple conundrums. > What I'm suggesting is that we look at it this way: > > > 
> +-----------------------------+
> | Interface Object            |          +------------------------------+
> |            service provider----------->|                              |
> |            other stuff      |          | "hardware" interface, e.g.   |
> +-----------------------------+          | physical socket, cable, etc. |
>                                          +------------------------------+
>
> > In other words, the position where we've been putting "local id" and its > ilk should really be just a reference. I put "hardware" interface in > quotes, because with virtual machines, etc., etc. it's not really hardware, > but its provisioning, installation, etc. tends to take on a very different > character from just bringing up another stack. This sort of approach > works really nicely with tunneling and other encapsulations, btw. > > Of course, some will just say "it's turtles all the way down"; you can > view this as a bug or a feature, but the reality is that eventually that > reference will be to something physical and in a sense not configurable > at the level of virtualization in question. I think we already have your second model. The "hardware" interface is identified by (type, location): The "location" leaf is a string. It is optional in the data model, but if the type represents a physical interface, it is mandatory. The format of this string is device- and type-dependent. The device uses the location string to identify the physical or logical entity that the configuration applies to. For example, if a device has a single array of 8 ethernet ports, the location can be one of the strings "1" to "8". As another example, if a device has N cards of M ports, the location can be on the form "n/m", such as "1/0". How a client can learn which types and locations are present on a certain device is outside the scope of this document. The debate, as I understand it, started around the names of interface objects. Operating systems usually assign names to hardware interfaces and the question came up how the name of the interface object relates to the system's notion of an interface name, i.e.: - Is it allowed that implementations restrict the name of an interface object to the system's notion of an interface name? The current I-D says yes, others argued for no. If the answer is yes, how can a generic management applications learn about name restrictions used by the underlying operating system? (Note that we already have "how a client can learn which types and locations are present on a certain device is outside the scope of this document", making a truely generic client already impossible.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Sep 24 02:07: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 350D821F85C4 for ; Mon, 24 Sep 2012 02:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.548 X-Spam-Level: X-Spam-Status: No, score=-8.548 tagged_above=-999 required=5 tests=[AWL=2.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-awjzwWPKAg for ; Mon, 24 Sep 2012 02:07:29 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 604C121F85C0 for ; Mon, 24 Sep 2012 02:07:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O97NCo008445; Mon, 24 Sep 2012 11:07:23 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O97M0o028008; Mon, 24 Sep 2012 11:07:22 +0200 (CEST) Message-ID: <506022CA.9030200@cisco.com> Date: Mon, 24 Sep 2012 11:07:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> In-Reply-To: <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, lhotka@cesnet.cz, rbonica@juniper.net, jernej.tuljak@mg-soft.com Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 09:07:30 -0000 Hi, How do we want to treat this? Updating the errata 3362, or a new one? Regards, Benoit. > On Sep 24, 2012, at 10:35 AM, Juergen Schoenwaelder wrote: > >> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >> >> [...] >> >>> Notes >>> ----- >>> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. >>> >> Would it make sense to identify the other changes that may be >> required? I quick search leads to: >> >> - Table 2 >> - 2nd paragraph of section 11.2 >> - section 12.16 (including its title) >> - definition of unique-attribute in appendix A > Yes, this list (+ section 10.55) is all that needs to be changed. > > Lada > >> Anything else I am missing? >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > -- > Ladislav Lhotka > PGP Key ID: E74E8C0C > > > > > > From lhotka@nic.cz Mon Sep 24 02:17: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 3866B21F8604 for ; Mon, 24 Sep 2012 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lk3jg40CMWT for ; Mon, 24 Sep 2012 02:17:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7E78421F8602 for ; Mon, 24 Sep 2012 02:17:26 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5673313FAA4; Mon, 24 Sep 2012 11:17:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1348478245; bh=/0DIbx7lx4+Js5GHtOqDUAvpUDQzPXzwL+5zapOc8b4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=abt+rbV4VvfCNr3ZwHtO8Xyw1PSG2Dmd9RYnLkfWHC/6G4to7gX8xUEdqCPzZi9VK yw6wXN9Wqv6RDEve6yPjVhuVfFtIL3mpQ5ZEbq6uo18JglrGO1wO3YSE5rhZ/cclNs eqlPER2ZhCrqGOlQ6szl+LteBrwsUaqq6ddlUAQk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120924084550.GA7231@elstar.local> Date: Mon, 24 Sep 2012 11:17:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120921154850.6A92C72E038@rfc-editor.org> <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> <20120924.103434.156371276890823415.mbj@tail-f.com> <20120924084550.GA7231@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: rbonica@juniper.net, netmod@ietf.org, jernej.tuljak@mg-soft.com, "rfc-editor@rfc-editor.org System" Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 09:17:28 -0000 On Sep 24, 2012, at 10:45 AM, Juergen Schoenwaelder = wrote: > On Mon, Sep 24, 2012 at 10:34:34AM +0200, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Hi, >>>=20 >>> this erratum should be verified, the reporter is absolutely right. >>=20 >> If I am not mistaken, this errata changes the encoding of "unique" >> from an XML attribute to an XML element. Can we really make such >> changes in an errata? >=20 > Good question. The bug, however, seems to be clear. I think it is > important to figure out what kind of solution those implementing/using > this specification really want. Some backwards compatible options: >=20 > - You can create a kludge where the case with only one unique > statement is handled as currently documented and additional unique > statements are dealt with differently. >=20 > - You can create an update that says unique statement are handled with > XML elements but in the special case of only one unique statement, > the attribute is present in addition to the XML elements, > essentially introducing the xml element solution and deprecating the > use of an attribute. >=20 > Perhaps there are other options. Lets figure out which solution is > preferred and then we can see how to properly document that. Practically speaking, it would be IMO wiser *not* to implement any = backward compatibility kludge. The two existing implementations (MG-SOFT = and pyang) can be updated in a straightforward way, and for any future = implementors it would be easier to deal only with the = elements. I do admit it is a somewhat slippery slope but I also believe the risk = of interoperability problems is minimal. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Sep 24 03:03: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 0DDFB21F85A8 for ; Mon, 24 Sep 2012 03:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4624ix9YYxI for ; Mon, 24 Sep 2012 03:03:35 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5C21F847C for ; Mon, 24 Sep 2012 03:03:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2223B5405F4 for ; Mon, 24 Sep 2012 12:03:27 +0200 (CEST) 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 YOLkqOKWDfLg for ; Mon, 24 Sep 2012 12:03:18 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id A077054030F for ; Mon, 24 Sep 2012 12:03:14 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120924090655.GB7231@elstar.local> References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> <000401cd9826$27324ec0$6b01a8c0@oemcomputer> <20120924090655.GB7231@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 24 Sep 2012 12:02:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 10:03:36 -0000 Juergen Schoenwaelder writes: > On Fri, Sep 21, 2012 at 11:23:07AM -0700, Randy Presuhn wrote: > >> No. Here's the subtle difference. We've been talking as though >> the system-supplied "local" identifier for an interface is something >> that is a property of the object we've been calling an interface. >> >> 
>> +-------------------------+
>> | Interface Object        |
>> |            "local id"   |
>> |            other stuff  |
>> +-------------------------+
>>
>> >> As we've already seen, this approach leads to multiple conundrums. >> What I'm suggesting is that we look at it this way: >> >> >> 
>> +-----------------------------+
>> | Interface Object            |          +------------------------------+
>> |            service provider----------->|                              |
>> |            other stuff      |          | "hardware" interface, e.g.   |
>> +-----------------------------+          | physical socket, cable, etc. |
>>                                          +------------------------------+
>>
>> >> In other words, the position where we've been putting "local id" and its >> ilk should really be just a reference. I put "hardware" interface in >> quotes, because with virtual machines, etc., etc. it's not really hardware, >> but its provisioning, installation, etc. tends to take on a very different >> character from just bringing up another stack. This sort of approach >> works really nicely with tunneling and other encapsulations, btw. >> >> Of course, some will just say "it's turtles all the way down"; you can >> view this as a bug or a feature, but the reality is that eventually that >> reference will be to something physical and in a sense not configurable >> at the level of virtualization in question. > > I think we already have your second model. The "hardware" interface is > identified by (type, location): > > The "location" leaf is a string. It is optional in the data model, > but if the type represents a physical interface, it is mandatory. > The format of this string is device- and type-dependent. The device > uses the location string to identify the physical or logical entity > that the configuration applies to. For example, if a device has a > single array of 8 ethernet ports, the location can be one of the > strings "1" to "8". As another example, if a device has N cards of M > ports, the location can be on the form "n/m", such as "1/0". > > How a client can learn which types and locations are present on a > certain device is outside the scope of this document. > > The debate, as I understand it, started around the names of interface > objects. Operating systems usually assign names to hardware interfaces > and the question came up how the name of the interface object relates > to the system's notion of an interface name, i.e.: > > - Is it allowed that implementations restrict the name of an interface > object to the system's notion of an interface name? > > The current I-D says yes, others argued for no. If the answer is yes, > how can a generic management applications learn about name > restrictions used by the underlying operating system? (Note that we > already have "how a client can learn which types and locations are > present on a certain device is outside the scope of this document", > making a truely generic client already impossible.) I think the difference is this: "type" and "location" (= the anchor to a hardware interface in Randy's picture) can be adjusted in one place whereas "name" may appear in multiple places and all occurrence have to be adjusted at the same time. Also, "name" is a list key so there are additional restrictions imposed by YANG. My only problem with the (type, location) pair in the role of that anchor is that on some platforms it is not the natural way of identifying interfaces and it may require additional effort to figure out the hardware interface to which (type, location) refers. 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 Mon Sep 24 03:20:31 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 0ABDF21F863F for ; Mon, 24 Sep 2012 03:20:31 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIwHzzuCvqyD for ; Mon, 24 Sep 2012 03:20:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E361021F8619 for ; Mon, 24 Sep 2012 03:20:29 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AD2120C5A; Mon, 24 Sep 2012 12:20:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3uN1tRhY5ol7; Mon, 24 Sep 2012 12:20:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEAA220C67; Mon, 24 Sep 2012 12:20:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A071721E5E23; Mon, 24 Sep 2012 12:20:24 +0200 (CEST) Date: Mon, 24 Sep 2012 12:20:24 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120924102024.GA7521@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> <000401cd9826$27324ec0$6b01a8c0@oemcomputer> <20120924090655.GB7231@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) Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 10:20:31 -0000 On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: > My only problem with the (type, location) pair in the role of that > anchor is that on some platforms it is not the natural way of > identifying interfaces and it may require additional effort to > figure out the hardware interface to which (type, location) refers. So could the operating systems's notion of an interface name be a valid 'location' value if there is no better one known? That is on Linux, I would have acme Interface for customer acme. ... ethernetCsmacd eth0 but I could also choose to name the interface "eth0" if I really want to. eth0 Interface for customer acme. ... ethernetCsmacd eth0 Of course, the two 'eth0' strings here have rather different semantics and persistence properties. /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 Sep 24 03:39:29 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 3640421F847C for ; Mon, 24 Sep 2012 03:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJrXrzzDDOp6 for ; Mon, 24 Sep 2012 03:39:28 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 833E021F846D for ; Mon, 24 Sep 2012 03:39:28 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A936C1200048; Mon, 24 Sep 2012 12:39:26 +0200 (CEST) Date: Mon, 24 Sep 2012 12:39:26 +0200 (CEST) Message-Id: <20120924.123926.835537078326158636.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120924102024.GA7521@elstar.local> References: <20120924090655.GB7231@elstar.local> <20120924102024.GA7521@elstar.local> X-Mailer: Mew version 6.4 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] interface keying - call for preferences 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, 24 Sep 2012 10:39:29 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: > > > My only problem with the (type, location) pair in the role of that > > anchor is that on some platforms it is not the natural way of > > identifying interfaces and it may require additional effort to > > figure out the hardware interface to which (type, location) refers. > > So could the operating systems's notion of an interface name be a > valid 'location' value if there is no better one known? That is on > Linux, I would have > > > acme > Interface for customer acme. > ... > ethernetCsmacd > eth0 > If I understand what Lada wrote correctly, this doesn't work. Once you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone. On linux, it seems you must use PCI bus address for location, in order to be truly generic. Of course, a vendor that happens to use linux as the OS for its device can choose a more user-friendly location string. /martin From jernej.tuljak@mg-soft.si Mon Sep 24 03:56: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 77B0121F861E for ; Mon, 24 Sep 2012 03:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiVOJgPJ14O0 for ; Mon, 24 Sep 2012 03:56:18 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id ACA6421F861B for ; Mon, 24 Sep 2012 03:56:14 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8OAuBIs030976; Mon, 24 Sep 2012 12:56:12 +0200 Message-ID: <50603C4A.8060603@mg-soft.com> Date: Mon, 24 Sep 2012 12:56:10 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <20120921154850.6A92C72E038@rfc-editor.org> <18308163-4F9F-4545-8C38-0CAD86685B20@lhotka.name> <20120924.103434.156371276890823415.mbj@tail-f.com> <20120924084550.GA7231@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rbonica@juniper.net, netmod@ietf.org, "rfc-editor@rfc-editor.org System" Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 24 Sep 2012 10:56:19 -0000 Dne 24.9.2012 11:17, piše Ladislav Lhotka: > On Sep 24, 2012, at 10:45 AM, Juergen Schoenwaelder wrote: > >> On Mon, Sep 24, 2012 at 10:34:34AM +0200, Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> this erratum should be verified, the reporter is absolutely right. >>> If I am not mistaken, this errata changes the encoding of "unique" >>> from an XML attribute to an XML element. Can we really make such >>> changes in an errata? >> Good question. The bug, however, seems to be clear. I think it is >> important to figure out what kind of solution those implementing/using >> this specification really want. Some backwards compatible options: >> >> - You can create a kludge where the case with only one unique >> statement is handled as currently documented and additional unique >> statements are dealt with differently. >> >> - You can create an update that says unique statement are handled with >> XML elements but in the special case of only one unique statement, >> the attribute is present in addition to the XML elements, >> essentially introducing the xml element solution and deprecating the >> use of an attribute. >> >> Perhaps there are other options. Lets figure out which solution is >> preferred and then we can see how to properly document that. > Practically speaking, it would be IMO wiser *not* to implement any backward compatibility kludge. The two existing implementations (MG-SOFT and pyang) can be updated in a straightforward way, and for any future implementors it would be easier to deal only with the elements. I agree. I think it is in the interest of both, existing and future implementations, to keep stuff simple. If pyang and our implementation are really the only existing ones, then it doesn't make sense to put backward compatibility in there. Jernej > > I do admit it is a somewhat slippery slope but I also believe the risk of interoperability problems is minimal. > > Lada > >> /js >> >> -- >> 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 j.schoenwaelder@jacobs-university.de Mon Sep 24 04:00: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 00A3421F861D for ; Mon, 24 Sep 2012 04:00:50 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa4472azPl6k for ; Mon, 24 Sep 2012 04:00:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D591421F861B for ; Mon, 24 Sep 2012 04:00:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06A9A20C58; Mon, 24 Sep 2012 13:00:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zsdmZorSwYa9; Mon, 24 Sep 2012 13:00:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B25120C14; Mon, 24 Sep 2012 13:00:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5BE2E21F58EC; Mon, 24 Sep 2012 13:00:41 +0200 (CEST) Date: Mon, 24 Sep 2012 13:00:41 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120924110040.GA49561@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120924090655.GB7231@elstar.local> <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120924.123926.835537078326158636.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 11:00:50 -0000 On Mon, Sep 24, 2012 at 12:39:26PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: > > > > > My only problem with the (type, location) pair in the role of that > > > anchor is that on some platforms it is not the natural way of > > > identifying interfaces and it may require additional effort to > > > figure out the hardware interface to which (type, location) refers. > > > > So could the operating systems's notion of an interface name be a > > valid 'location' value if there is no better one known? That is on > > Linux, I would have > > > > > > acme > > Interface for customer acme. > > ... > > ethernetCsmacd > > eth0 > > > > If I understand what Lada wrote correctly, this doesn't work. Once > you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone. > > On linux, it seems you must use PCI bus address for location, in order > to be truly generic. Of course, a vendor that happens to use linux as > the OS for its device can choose a more user-friendly location string. Yes, but this is the core of the question for me. Where is the system's notion of an interface name visible? On Linux, the OS refers to an interface by a name, not by location. If we accept that OS level name as a location, then after renaming 'eth0' to 'acme' all you have to do is update the element. Lada's original concern was that eth0 might become eth1 and vice versa if you update the kernel and reboot and he wanted to minimize the amount of config impacted by such a change. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Sep 24 04:28: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 5F44121F84D2 for ; Mon, 24 Sep 2012 04:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVrOMQw9LF2c for ; Mon, 24 Sep 2012 04:28:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 939F721F845C for ; Mon, 24 Sep 2012 04:28:25 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 758291200050; Mon, 24 Sep 2012 13:28:24 +0200 (CEST) Date: Mon, 24 Sep 2012 13:28:24 +0200 (CEST) Message-Id: <20120924.132824.1800960469658429693.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120924110040.GA49561@elstar.local> References: <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> <20120924110040.GA49561@elstar.local> X-Mailer: Mew version 6.4 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] interface keying - call for preferences 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, 24 Sep 2012 11:28:26 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 24, 2012 at 12:39:26PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: > > > > > > > My only problem with the (type, location) pair in the role of that > > > > anchor is that on some platforms it is not the natural way of > > > > identifying interfaces and it may require additional effort to > > > > figure out the hardware interface to which (type, location) refers. > > > > > > So could the operating systems's notion of an interface name be a > > > valid 'location' value if there is no better one known? That is on > > > Linux, I would have > > > > > > > > > acme > > > Interface for customer acme. > > > ... > > > ethernetCsmacd > > > eth0 > > > > > > > If I understand what Lada wrote correctly, this doesn't work. Once > > you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone. > > > > On linux, it seems you must use PCI bus address for location, in order > > to be truly generic. Of course, a vendor that happens to use linux as > > the OS for its device can choose a more user-friendly location string. > > Yes, but this is the core of the question for me. Where is the > system's notion of an interface name visible? On Linux, the OS refers > to an interface by a name, not by location. If we accept that OS level > name as a location, then after renaming 'eth0' to 'acme' all you have > to do is update the element. What exactly does this mean, and who is "you" above? Do you mean that all the client has to do is set to "acme"? But that would imply that the end config is: acme Interface for customer acme. ... ethernetCsmacd acme This can't be used by the system after a reboot, since the interface will be assigned the name 'eth0' (or whatever) by the kernel, before it can be renamed. > Lada's original concern was > that eth0 might become eth1 and vice versa if you update the kernel > and reboot and he wanted to minimize the amount of config impacted by > such a change. Right. It seems there are some ways to handle this in linux, all based on some notion of a "location"; pci address or mac address, using startup scripts or udev rules. /martin From j.schoenwaelder@jacobs-university.de Mon Sep 24 04:57: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 7DE1A21F861B for ; Mon, 24 Sep 2012 04:57:33 -0700 (PDT) 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.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSSKAteuD+J9 for ; Mon, 24 Sep 2012 04:57:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 681BC21F85EA for ; Mon, 24 Sep 2012 04:57:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCC7720C1E; Mon, 24 Sep 2012 13:57:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FSGemicAg4Gb; Mon, 24 Sep 2012 13:57:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DA1E20C0A; Mon, 24 Sep 2012 13:57:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68C0F21F5C5C; Mon, 24 Sep 2012 13:57:26 +0200 (CEST) Date: Mon, 24 Sep 2012 13:57:25 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120924115725.GA49936@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> <20120924110040.GA49561@elstar.local> <20120924.132824.1800960469658429693.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120924.132824.1800960469658429693.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 11:57:33 -0000 On Mon, Sep 24, 2012 at 01:28:24PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Sep 24, 2012 at 12:39:26PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: > > > > > > > > > My only problem with the (type, location) pair in the role of that > > > > > anchor is that on some platforms it is not the natural way of > > > > > identifying interfaces and it may require additional effort to > > > > > figure out the hardware interface to which (type, location) refers. > > > > > > > > So could the operating systems's notion of an interface name be a > > > > valid 'location' value if there is no better one known? That is on > > > > Linux, I would have > > > > > > > > > > > > acme > > > > Interface for customer acme. > > > > ... > > > > ethernetCsmacd > > > > eth0 > > > > > > > > > > If I understand what Lada wrote correctly, this doesn't work. Once > > > you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone. > > > > > > On linux, it seems you must use PCI bus address for location, in order > > > to be truly generic. Of course, a vendor that happens to use linux as > > > the OS for its device can choose a more user-friendly location string. > > > > Yes, but this is the core of the question for me. Where is the > > system's notion of an interface name visible? On Linux, the OS refers > > to an interface by a name, not by location. If we accept that OS level > > name as a location, then after renaming 'eth0' to 'acme' all you have > > to do is update the element. > > What exactly does this mean, and who is "you" above? Do you mean that > all the client has to do is set to "acme"? But that would > imply that the end config is: > > > acme > Interface for customer acme. > ... > ethernetCsmacd > acme > > > This can't be used by the system after a reboot, since the interface > will be assigned the name 'eth0' (or whatever) by the kernel, before > it can be renamed. Sure, but if you mess with the system, you either need to do it completely or accept the consequences. My point was that system level interface renaming out of scope for us. > > Lada's original concern was > > that eth0 might become eth1 and vice versa if you update the kernel > > and reboot and he wanted to minimize the amount of config impacted by > > such a change. > > Right. It seems there are some ways to handle this in linux, all > based on some notion of a "location"; pci address or mac address, > using startup scripts or udev rules. So anything against allowing the OS level interface name in the location? /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 Sep 24 04:58: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 C1BC721F861D for ; Mon, 24 Sep 2012 04:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXTxvax3BOmy for ; Mon, 24 Sep 2012 04:58:54 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6E921F861C for ; Mon, 24 Sep 2012 04:58:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 739C81200050; Mon, 24 Sep 2012 13:58:53 +0200 (CEST) Date: Mon, 24 Sep 2012 13:58:53 +0200 (CEST) Message-Id: <20120924.135853.367703709615324184.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120924115725.GA49936@elstar.local> References: <20120924110040.GA49561@elstar.local> <20120924.132824.1800960469658429693.mbj@tail-f.com> <20120924115725.GA49936@elstar.local> X-Mailer: Mew version 6.4 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] interface keying - call for preferences 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, 24 Sep 2012 11:58:54 -0000 Juergen Schoenwaelder wrote: > So anything against allowing the OS level interface name in the > location? People are free to use whatever works for them. If OS level interface name works - fine. /martin From lhotka@nic.cz Mon Sep 24 05:19: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 BC7AE21F8661 for ; Mon, 24 Sep 2012 05:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTTOLp1wVvaa for ; Mon, 24 Sep 2012 05:19:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CF57C21F8646 for ; Mon, 24 Sep 2012 05:19:18 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C14DF13FAA4; Mon, 24 Sep 2012 14:19:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1348489157; bh=sOtlbLnKdcb7QBdFL004uyFqewFMj7ULYt7JmNrn5ko=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FIusE4AWeXL0ndQXnWK3C7oRykIH2v9AkRa2XOa1bJQYjfgSfIkUYiZv90loSw5HO nJuRI2aBNK2H8rIH0a8YmcGJoVepYDTpNCoioNKw3uHj07ISJc+Ge3uoOeOL9XS36Q nuKl1Gh9QMFh2xSrfaTBPOKYHwoZw5mAnMvLLjX8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120924.123926.835537078326158636.mbj@tail-f.com> Date: Mon, 24 Sep 2012 14:19:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120924090655.GB7231@elstar.local> <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 12:19:20 -0000 On Sep 24, 2012, at 12:39 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: >>=20 >>> My only problem with the (type, location) pair in the role of that >>> anchor is that on some platforms it is not the natural way of >>> identifying interfaces and it may require additional effort to >>> figure out the hardware interface to which (type, location) refers. >>=20 >> So could the operating systems's notion of an interface name be a >> valid 'location' value if there is no better one known? That is on >> Linux, I would have >>=20 >> >> acme >> Interface for customer acme. >> ... >> ethernetCsmacd >> eth0 >> >=20 > If I understand what Lada wrote correctly, this doesn't work. Once > you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone. Yes, so in this case the location value also has to be changed from = "eth0" to "acme". >=20 > On linux, it seems you must use PCI bus address for location, in order > to be truly generic. Of course, a vendor that happens to use linux as > the OS for its device can choose a more user-friendly location string. I think Juergen's proposal could work, too, although it is IMO better to = avoid potential differences in location semantics. I assume that every = device uses some kind of native interface identifiers and these should = appear in a clearly named leaf like "local-name". Location can stay as = an optional leaf, perhaps even state data - on Linux it could contain = e.g. the PCI address. Lada =20 >=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@nic.cz Mon Sep 24 05:41: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 8238821F8607 for ; Mon, 24 Sep 2012 05:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a476ZsDeJtD for ; Mon, 24 Sep 2012 05:41:11 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 984C121F866E for ; Mon, 24 Sep 2012 05:41:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0163F5405F4; Mon, 24 Sep 2012 14:41:05 +0200 (CEST) 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 kdJc+3w0hzus; Mon, 24 Sep 2012 14:41:00 +0200 (CEST) Received: from [172.29.2.201] (unknown [10.107.191.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8C07554030F; Mon, 24 Sep 2012 14:41:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ladislav Lhotka In-Reply-To: <20120924.132824.1800960469658429693.mbj@tail-f.com> Date: Mon, 24 Sep 2012 14:40:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> <20120924110040.GA49561@elstar.local> <20120924.132824.1800960469658429693.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1486) Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 12:41:11 -0000 On Sep 24, 2012, at 1:28 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Sep 24, 2012 at 12:39:26PM +0200, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> My only problem with the (type, location) pair in the role of that >>>>> anchor is that on some platforms it is not the natural way of >>>>> identifying interfaces and it may require additional effort to >>>>> figure out the hardware interface to which (type, location) = refers. >>>>=20 >>>> So could the operating systems's notion of an interface name be a >>>> valid 'location' value if there is no better one known? That is on >>>> Linux, I would have >>>>=20 >>>> >>>> acme >>>> Interface for customer acme. >>>> ... >>>> ethernetCsmacd >>>> eth0 >>>> >>>=20 >>> If I understand what Lada wrote correctly, this doesn't work. Once >>> you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone. >>>=20 >>> On linux, it seems you must use PCI bus address for location, in = order >>> to be truly generic. Of course, a vendor that happens to use linux = as >>> the OS for its device can choose a more user-friendly location = string. >>=20 >> Yes, but this is the core of the question for me. Where is the >> system's notion of an interface name visible? On Linux, the OS refers >> to an interface by a name, not by location. If we accept that OS = level >> name as a location, then after renaming 'eth0' to 'acme' all you have >> to do is update the element. >=20 > What exactly does this mean, and who is "you" above? Do you mean that > all the client has to do is set to "acme"? But that would > imply that the end config is: >=20 > > acme > Interface for customer acme. > ... > ethernetCsmacd > acme > >=20 > This can't be used by the system after a reboot, since the interface > will be assigned the name 'eth0' (or whatever) by the kernel, before > it can be renamed. If the system interface name is changed via init scripts, then "acme" is = already the right (and only) name when the NETCONF server starts. Maybe = you are assuming that the system name is to be changed via NETCONF, but = that's IMO out of scope for this discussion - an RPC would probably be = better for this.=20 >=20 >> Lada's original concern was >> that eth0 might become eth1 and vice versa if you update the kernel >> and reboot and he wanted to minimize the amount of config impacted by >> such a change. >=20 > Right. It seems there are some ways to handle this in linux, all > based on some notion of a "location"; pci address or mac address, > using startup scripts or udev rules. Even these addresses might change, e.g. when you replace the network = card or motherboard. Lada >=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 mbj@tail-f.com Mon Sep 24 11:22: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 C8A5C21F8834 for ; Mon, 24 Sep 2012 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNsY-HXTgW3J for ; Mon, 24 Sep 2012 11:22:00 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3964A21F882D for ; Mon, 24 Sep 2012 11:22:00 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7DF691200048; Mon, 24 Sep 2012 20:21:58 +0200 (CEST) Date: Mon, 24 Sep 2012 20:21:58 +0200 (CEST) Message-Id: <20120924.202158.488642842.mbj@tail-f.com> To: yihuan@cisco.com From: Martin Bjorklund In-Reply-To: References: <20120923.220052.492488023.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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, 24 Sep 2012 18:22:00 -0000 Hi, "Lisa Huang (yihuan)" wrote: > Acl-ip and acl-arp has no other relationship except both could filter on > ip address. From this point of view, it does not quite make sense for > acl-arp to import acl-ip. I think you maybe read too much meaning into the "import" statement? There does not have to be any relationship between a module and the module it imports, more than there are some definitions in the imported module that the importing module wants to reuse. This said, I agree you don't want to introduce unnecessary dependencies, but I don't think that's the case here. /martin From randy_presuhn@mindspring.com Mon Sep 24 11:28:57 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 387B921F8858 for ; Mon, 24 Sep 2012 11:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY69HyYNvi-3 for ; Mon, 24 Sep 2012 11:28:56 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id A592221F8850 for ; Mon, 24 Sep 2012 11:28:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EOknmA0amQ2ryKEA2z/YWe+b7dayIGEdItBJdIZxMRR9pmMg41F87pj9fcK5QSKi; 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 [76.254.55.72] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TGDOp-0001nB-U8 for netmod@ietf.org; Mon, 24 Sep 2012 14:28:56 -0400 Message-ID: <005e01cd9a83$8311fd80$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120919114451.GA39136@elstar.local> <505C71C6.5050000@seguesoft.com> <001a01cd981a$573d01c0$6b01a8c0@oemcomputer> <000401cd9826$27324ec0$6b01a8c0@oemcomputer> <20120924090655.GB7231@elstar.local> Date: Mon, 24 Sep 2012 11:36:27 -0700 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1d27f9a3de4bad8845dad480023025730350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.72 Subject: Re: [netmod] interface keying - call for preferences 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, 24 Sep 2012 18:28:57 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, September 24, 2012 2:06 AM > Subject: Re: [netmod] interface keying - call for preferences ... > The current I-D says yes, others argued for no. If the answer is yes, > how can a generic management applications learn about name > restrictions used by the underlying operating system? (Note that we > already have "how a client can learn which types and locations are > present on a certain device is outside the scope of this document", > making a truely generic client already impossible.) I think it's necessary to take it just a little bit farther. The "types and locations" are really properties of the currently invisible "hardware" interfaces. An administrator *may* choose to propagate some of that information one layer higher in the stack, but it's not logically necessary to do so. That's one reason why opinions diverge. This leads me to believe that it's unltimately simpler and cleaner to make those currently invisible "hardware" interfaces (e.g. physical connector) visible as "managed objects", even if not configurable ones. Taking this extra tiny step eliminates the temptation to look at the constraints on the reference (and it really is a reference, not a property) as syntactic ones, as well as reducing the degree of layering violation. (And it goes a long way toward making generic clients more feasible.) Randy From j.schoenwaelder@jacobs-university.de Tue Sep 25 00:22: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 C097F21F84E7 for ; Tue, 25 Sep 2012 00:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhivmZzlb97l for ; Tue, 25 Sep 2012 00:22:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1D31921F84F2 for ; Tue, 25 Sep 2012 00:22:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2624520C18; Tue, 25 Sep 2012 09:22:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JZ5li9sCsUpE; Tue, 25 Sep 2012 09:22:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7527620C16; Tue, 25 Sep 2012 09:22:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A657C21F8257; Tue, 25 Sep 2012 09:22:08 +0200 (CEST) Date: Tue, 25 Sep 2012 09:22:08 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120925072208.GB52571@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20120924090655.GB7231@elstar.local> <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> 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] interface keying - call for preferences 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, 25 Sep 2012 07:22:16 -0000 On Mon, Sep 24, 2012 at 02:19:17PM +0200, Ladislav Lhotka wrote: > > I think Juergen's proposal could work, too, although it is IMO > better to avoid potential differences in location semantics. I > assume that every device uses some kind of native interface > identifiers and these should appear in a clearly named leaf like > "local-name". Location can stay as an optional leaf, perhaps even > state data - on Linux it could contain e.g. the PCI address. I prefer to have one configurable reference to the 'hardware interface identifier as know by the underlying operating system' instead of two. Perhaps all we need to do is to rename the leaf location and revise its description and make it clear that the name leaf really carries an administratively assigned name. The concept of a location is not really well developed anyway, we can punt that until we ever seriously think about containment a la ENTITY-MIB. Now we need a good name, "location" seems to restrictive and "local-name" is somewhat unclear as well (what is local?). Any ideas? And I think we need to capture some of the outcomes of this discussion. For example, that operating system level changes of interface names affect the 'yet-to-be-named' leaf identifying a hardware interface but not the 'name' of an interface. The definition of an RPC to initiate operating system level changes of interface names might be a future addition but has been left out for now. And perhaps we should add examples showing in addition to flat hw interface numbers and structured hw interface identifiers also the use of os-level interface names. Perhaps also text discussing how administratively assigned interface names can help moving configs around easily if either the physical connection changes or the hw interface identifier changes (e.g., due to firmware upgrades or physical movement of line cards). /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 Tue Sep 25 01:43:38 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 2950921F84A2 for ; Tue, 25 Sep 2012 01:43:38 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4bJbrpzHYtQ for ; Tue, 25 Sep 2012 01:43:36 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E797921F849D for ; Tue, 25 Sep 2012 01:43:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 62CF1540699 for ; Tue, 25 Sep 2012 10:43:33 +0200 (CEST) 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 EkgCIlF8fw2C for ; Tue, 25 Sep 2012 10:43:30 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AC736540049 for ; Tue, 25 Sep 2012 10:43:25 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120925072208.GB52571@elstar.local> References: <20120924090655.GB7231@elstar.local> <20120924102024.GA7521@elstar.local> <20120924.123926.835537078326158636.mbj@tail-f.com> <20120925072208.GB52571@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 25 Sep 2012 10:43:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface keying - call for preferences 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, 25 Sep 2012 08:43:38 -0000 Juergen Schoenwaelder writes: > On Mon, Sep 24, 2012 at 02:19:17PM +0200, Ladislav Lhotka wrote: >> >> I think Juergen's proposal could work, too, although it is IMO >> better to avoid potential differences in location semantics. I >> assume that every device uses some kind of native interface >> identifiers and these should appear in a clearly named leaf like >> "local-name". Location can stay as an optional leaf, perhaps even >> state data - on Linux it could contain e.g. the PCI address. > > I prefer to have one configurable reference to the 'hardware interface > identifier as know by the underlying operating system' instead of two. > Perhaps all we need to do is to rename the leaf location and revise > its description and make it clear that the name leaf really carries an > administratively assigned name. The concept of a location is not > really well developed anyway, we can punt that until we ever seriously > think about containment a la ENTITY-MIB. Agreed. > > Now we need a good name, "location" seems to restrictive and > "local-name" is somewhat unclear as well (what is local?). Any > ideas? RFC 2863 uses the term "local name" in this sense. Another candidate could be "native-name". > > And I think we need to capture some of the outcomes of this > discussion. For example, that operating system level changes of > interface names affect the 'yet-to-be-named' leaf identifying a > hardware interface but not the 'name' of an interface. The definition > of an RPC to initiate operating system level changes of interface > names might be a future addition but has been left out for now. > > And perhaps we should add examples showing in addition to flat hw > interface numbers and structured hw interface identifiers also the use > of os-level interface names. Perhaps also text discussing how > administratively assigned interface names can help moving configs > around easily if either the physical connection changes or the hw > interface identifier changes (e.g., due to firmware upgrades or > physical movement of line cards). +1 Lada > > /js > > -- > 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@nic.cz Tue Sep 25 03:22: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 9909221F86D6 for ; Tue, 25 Sep 2012 03:22:49 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SARKkihblsNJ for ; Tue, 25 Sep 2012 03:22:49 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C2E3121F86D1 for ; Tue, 25 Sep 2012 03:22:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7EDE2540699 for ; Tue, 25 Sep 2012 12:22:46 +0200 (CEST) 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 VZr7MajcJFWy for ; Tue, 25 Sep 2012 12:22:41 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6B63C540049 for ; Tue, 25 Sep 2012 12:22:35 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120921154850.6A92C72E038@rfc-editor.org> References: <20120921154850.6A92C72E038@rfc-editor.org> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 25 Sep 2012 12:22:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 25 Sep 2012 10:22:49 -0000 Hi, this bug is now fixed in pyang. I only used a different name ("tag") for the attribute of the element, in order to follow the YIN convention. So the annotation looks e.g. like this: Please try it out. Thanks, Lada RFC Errata System writes: > The following errata report has been submitted for RFC6110, > "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6110&eid=3362 > > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak > > Section: 10.55. > > Original Text > ------------- > The 'unique' Statement > > This statement is mapped to the @nma:unique attribute. ARGUMENT MUST > be translated so that every node identifier in each of its components > is prefixed with the namespace prefix of the local module, unless the > prefix is already present. The result of this translation then > becomes the value of the @nma:unique attribute. > > For example, assuming that the local module prefix is "ex", > > unique "foo ex:bar/baz" > > is mapped to the following attribute/value pair: > > nma:unique="ex:foo ex:bar/ex:baz" > > Corrected Text > -------------- > The 'unique' Statement > > This statement is mapped to the element. It has one > mandatory attribute @key (with no namespace). ARGUMENT MUST > be translated so that every node identifier in each of its components > is prefixed with the namespace prefix of the local module, unless the > prefix is already present. The result of this translation then > becomes the value of the @key attribute. > > For example, assuming that the local module prefix is "ex", > > unique "foo ex:bar/baz" > > is mapped to the following element: > > > > Notes > ----- > A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6110 (draft-ietf-netmod-dsdl-map-10) > -------------------------------------- > Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content > Publication Date : February 2011 > Author(s) : L. Lhotka, Ed. > Category : PROPOSED STANDARD > Source : NETCONF Data Modeling Language > Area : Operations and Management > Stream : IETF > Verifying Party : IESG -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Sep 25 08:11: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 6EBDA1F040A for ; Tue, 25 Sep 2012 08:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGtmw2D0uGjL for ; Tue, 25 Sep 2012 08:11:51 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 53D4F1F0C94 for ; Tue, 25 Sep 2012 08:11:51 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 426F0120005A; Tue, 25 Sep 2012 17:11:49 +0200 (CEST) Date: Tue, 25 Sep 2012 17:11:48 +0200 (CEST) Message-Id: <20120925.171148.493408222.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120925072208.GB52571@elstar.local> References: <20120924.123926.835537078326158636.mbj@tail-f.com> <20120925072208.GB52571@elstar.local> X-Mailer: Mew version 6.4 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] interface keying - call for preferences 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, 25 Sep 2012 15:11:52 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 24, 2012 at 02:19:17PM +0200, Ladislav Lhotka wrote: > > > > I think Juergen's proposal could work, too, although it is IMO > > better to avoid potential differences in location semantics. I > > assume that every device uses some kind of native interface > > identifiers and these should appear in a clearly named leaf like > > "local-name". Location can stay as an optional leaf, perhaps even > > state data - on Linux it could contain e.g. the PCI address. > > I prefer to have one configurable reference to the 'hardware interface > identifier as know by the underlying operating system' instead of > two. Me too. And I do not think it would be a good idea to add another indirection by using something like 'local-name'. > Perhaps all we need to do is to rename the leaf location If there is a better name, fine. But I think this is probably more important: > and revise > its description But the question is what we need to add. Note that there are really *two* leafs that together refer to the correct hardware port - 'type' and 'location'. 'type' is needed as a separate leaf since we base augmentation on the type. > and make it clear that the name leaf really carries an > administratively assigned name. Hmm, does "administratively assigned name" imply "arbitrary"? If not, what exactly does "administratively assigned" mean? > The concept of a location is not > really well developed anyway I still think that you always can pick something relevant to use as a location. It seems most router vendors have been able to do this for some time now... I don't think we can find something more precise, that will be useful across vendors / OSes. > Now we need a good name, "location" seems to restrictive and > "local-name" is somewhat unclear as well (what is local?). Any > ideas? > > And I think we need to capture some of the outcomes of this > discussion. For example, that operating system level changes of > interface names affect the 'yet-to-be-named' leaf identifying a > hardware interface but not the 'name' of an interface. I don't think this is true in general. And implementing things this way leads to a pretty bad user experience - for example, if you use the kernel-assigned name as a 'location' on a linux system we have seen that things might break down if you upgrade the kernel etc. This is a well-known problem. So, the simple solution is to NOT use the kernel-assigned name for hw-identiifcation purposes. > The definition > of an RPC to initiate operating system level changes of interface > names might be a future addition but has been left out for now. > > And perhaps we should add examples showing in addition to flat hw > interface numbers and structured hw interface identifiers also the use > of os-level interface names. Perhaps also text discussing how > administratively assigned interface names can help moving configs > around easily if either the physical connection changes or the hw > interface identifier changes (e.g., due to firmware upgrades or > physical movement of line cards). I am actually still a bit confused. It is not clear to me what the real problem with the current 'location' leaf is. This thread started with a consensus call for some options that really boils down to whether the name MUST be arbitrary or not. It seems to me that most people preferred (a) - i.e., allow implementations to restrict the name of the interface. Lada wanted an optional config false leaf 'local-name', which I guess makes sense if the system implements a "mapping table" between the configured name and the kernel-assigned name. /martin From yihuan@cisco.com Tue Sep 25 10:13:10 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 AC3D721F87DB for ; Tue, 25 Sep 2012 10:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98hjFxzT8htD for ; Tue, 25 Sep 2012 10:13:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD0521F87A2 for ; Tue, 25 Sep 2012 10:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=759; q=dns/txt; s=iport; t=1348593190; x=1349802790; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8/oNye4T8VRR/BDQvUomCWDBWJyvVKQwOKwBRCftV0U=; b=icOSIQzXDXLWkBDzfxX+ET6Ni1iFv8tS3BwQM4d15KsRdyZ4ltYDrmpU NjYA+EnUEs6dIC1Z09hy4OxxZOOCytLKlDfOW2t5sIlpjxFdSVFsCmQn3 +rIzITeinvmlPEwRCMqgSBN5EzeTeVFtj+awwuKgqrDceqAY8J5DizevI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUFAD/lYVCtJXG+/2dsb2JhbABFhUS5HoEIgiABAQEEEgEnOAcSAQgOCh5CJQIEDgUih2OZC49WkHGRXAOVZo4/gWmCZ4IX X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="124946613" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 25 Sep 2012 17:13:09 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8PHD92G021694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Sep 2012 17:13:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Tue, 25 Sep 2012 12:13:09 -0500 From: "Lisa Huang (yihuan)" To: Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwN+9QGAAKS+G1D//+3SgIADOwcAgAAgrACAAVYHAIABCcEA Date: Tue, 25 Sep 2012 17:13:09 +0000 Message-ID: In-Reply-To: <20120924.202158.488642842.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19208.004 x-tm-as-result: No--32.805700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9699FEE06007D244AB381646B02B3C15@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 25 Sep 2012 17:13:10 -0000 Got it. I will address it in next revision. On 9/24/12 11:21 AM, "Martin Bjorklund" wrote: >Hi, > >"Lisa Huang (yihuan)" wrote: >> Acl-ip and acl-arp has no other relationship except both could filter on >> ip address. From this point of view, it does not quite make sense for >> acl-arp to import acl-ip. > >I think you maybe read too much meaning into the "import" statement? >There does not have to be any relationship between a module and the >module it imports, more than there are some definitions in the >imported module that the importing module wants to reuse. > >This said, I agree you don't want to introduce unnecessary >dependencies, but I don't think that's the case here. > > >/martin From andy@yumaworks.com Tue Sep 25 12:52: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 745711F0CD4 for ; Tue, 25 Sep 2012 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4IVf42VQGqX for ; Tue, 25 Sep 2012 12:52:04 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0A621F0CD2 for ; Tue, 25 Sep 2012 12:51:58 -0700 (PDT) Received: by qcac10 with SMTP id c10so6540629qca.31 for ; Tue, 25 Sep 2012 12:51:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=DmSapUGdgzBptBVmMfspXdoexeE39ApQruiTuhtSIu8=; b=e4cefaNuo4wbPABZrWslE9RbWd4lfnfay78YozabKJXOZ8Tn96T+QnyTvu+6JLq98f DoaR+vpAPumEH88N50tDcwEF0R0uFKsX0+hhT3xDX/m/M4T49BQ3PqLjvD7u7ZYmHGbe HXmi5aouOBFwQcggDBvBBaohl5UqgOZDzBGI31EhkLaSWht1j+SirXcwjCd3RCC8EzEb 41jBXnwSdg9X3iBmoaCXz1h8subSoZLqm8cBwr/Vy71ks8swtBad+d+IRhalU/t4FZWe 3iJhwv7NokWfxCCmEtho9uSe9+wcKAG9Dm6tLleck59/0PoY1KIhXgPBX+7aopoEn71J fAyg== MIME-Version: 1.0 Received: by 10.229.136.81 with SMTP id q17mr11927937qct.105.1348602717951; Tue, 25 Sep 2012 12:51:57 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Tue, 25 Sep 2012 12:51:57 -0700 (PDT) Date: Tue, 25 Sep 2012 12:51:57 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk77V3F8I1g5FttlAMORBORXj1/wqxiymRwOKpm4G/ZNGlEVgx/rDLxOinRp/Rsf1lpfz47 Subject: [netmod] YANG sub-module using definitions from the main module 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, 25 Sep 2012 19:52:04 -0000 Hi, I have a question about YANG sub-module restrictions: 4.1, para 6: Derived types and groupings can be defined in one module or submodule and used in either that location or in another module or submodule that imports or includes it. 7..2.2, para 3: (belongs-to prefix) All definitions in the local submodule and any included submodules can be accessed by using the prefix. These 2 sections do not permit a sub-module to use any top-level definitions, (e.g., typedef, identity, grouping) from the main module, even though the submodule is required to specify the prefix in the belongs-to-stmt. Section 6.2.1 clearly defines the definition namespaces, so I do not understand this restriction. It is arbitrary and not needed. I think this was done to prevent a parser from having to read in the main module, and processing "main:my-type" is too hard. I don't see how it is any harder than supporting "import foo" and resolving "foo:my-type". Why is this restriction in YANG? Andy From mbj@tail-f.com Tue Sep 25 12:55: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 4F5DE1F0CDD for ; Tue, 25 Sep 2012 12:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ltAhrkamD5G for ; Tue, 25 Sep 2012 12:55:40 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C40621F0CD8 for ; Tue, 25 Sep 2012 12:55:39 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FCFB1200048; Tue, 25 Sep 2012 21:55:38 +0200 (CEST) Date: Tue, 25 Sep 2012 21:55:37 +0200 (CEST) Message-Id: <20120925.215537.497329850.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 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] YANG sub-module using definitions from the main module 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, 25 Sep 2012 19:55:40 -0000 Andy Bierman wrote: > Hi, > > I have a question about YANG sub-module restrictions: > > 4.1, para 6: > > Derived types and groupings can be defined in one module or submodule and > used in either that location or in another module or submodule that > imports or includes it. > > 7..2.2, para 3: (belongs-to prefix) > > All definitions in the local submodule and any included submodules > can be accessed > by using the prefix. > > These 2 sections do not permit a sub-module to use any top-level definitions, > (e.g., typedef, identity, grouping) from the main module, even though the > submodule is required to specify the prefix in the belongs-to-stmt. > > Section 6.2.1 clearly defines the definition namespaces, so I > do not understand this restriction. It is arbitrary and not needed. > > I think this was done to prevent a parser from having to read in the > main module Yes. If a submodule has access to the entire module (including all submodules), you essentially always have to read *all* submodules when you parse *one* submodule. The idea was that each submodule should be self-contained, with explicit import/include of other modules/submodules. /martin From andy@yumaworks.com Tue Sep 25 12:59:12 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 0C9A41F0CD7 for ; Tue, 25 Sep 2012 12:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L320L0o4Udik for ; Tue, 25 Sep 2012 12:59:11 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5076B1F0417 for ; Tue, 25 Sep 2012 12:59:11 -0700 (PDT) Received: by qaec10 with SMTP id c10so4561541qae.10 for ; Tue, 25 Sep 2012 12:59:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aVTRAkuYwB3iIcYe6Ne+Q+nfnPB4HghoEJ/7MXMoPm0=; b=VoYY+bhKkB4thugO/f9+aPBwdsuvZjgtXF26rEE4NcwpwPvOloqInTUkrtJ6Ic2L1C BL1ksIWRqdktzBVOIpJ0ZHyaLdIzY+Hxw9WSePDpp4V3xg9j6qAnLzURsGiS6kxd1fN9 vRDQZo1GgYqZCKwT+WOFfF3VzOUYhRWR89SkqtR/6oHJfFzI6csz0PvBeL9rjQ2a+COO njd0f6DaetkZxNYJr6Eb/eB9XUbe4sN0C7zbfKtcUvnurusG/8zm9zl8czLBuAhrWvCt pSsGqEK4KzTpqz5WwpBcjL1GHdMV8EDJSP1U/XFEIpCbRqXAYCI3VdJjVh1UMFyl89XH pf7A== MIME-Version: 1.0 Received: by 10.224.181.205 with SMTP id bz13mr42169126qab.76.1348603150643; Tue, 25 Sep 2012 12:59:10 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Tue, 25 Sep 2012 12:59:10 -0700 (PDT) In-Reply-To: <20120925.215537.497329850.mbj@tail-f.com> References: <20120925.215537.497329850.mbj@tail-f.com> Date: Tue, 25 Sep 2012 12:59:10 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmaoZCVj5gDld+c2ioSnMEqJzBuHJBdtfbmjwAtR4xqWNjZqrmklrUv3ZtAPEZgs1+bVbAB Cc: netmod@ietf.org Subject: Re: [netmod] YANG sub-module using definitions from the main module 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, 25 Sep 2012 19:59:12 -0000 On Tue, Sep 25, 2012 at 12:55 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I have a question about YANG sub-module restrictions: >> >> 4.1, para 6: >> >> Derived types and groupings can be defined in one module or submodule and >> used in either that location or in another module or submodule that >> imports or includes it. >> >> 7..2.2, para 3: (belongs-to prefix) >> >> All definitions in the local submodule and any included submodules >> can be accessed >> by using the prefix. >> >> These 2 sections do not permit a sub-module to use any top-level definitions, >> (e.g., typedef, identity, grouping) from the main module, even though the >> submodule is required to specify the prefix in the belongs-to-stmt. >> >> Section 6.2.1 clearly defines the definition namespaces, so I >> do not understand this restriction. It is arbitrary and not needed. >> >> I think this was done to prevent a parser from having to read in the >> main module > > Yes. If a submodule has access to the entire module (including all > submodules), you essentially always have to read *all* submodules when > you parse *one* submodule. The idea was that each submodule should be > self-contained, with explicit import/include of other > modules/submodules. > > Maybe if this text was in the RFC it would help people understand this subtle detail. > /martin Andy From j.schoenwaelder@jacobs-university.de Tue Sep 25 23:23: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 3B21221F848F for ; Tue, 25 Sep 2012 23:23:26 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihBgrqEwkisb for ; Tue, 25 Sep 2012 23:23:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 02B2121F847F for ; Tue, 25 Sep 2012 23:23:24 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0362120C31; Wed, 26 Sep 2012 08:23:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mckno7eJNJ8Q; Wed, 26 Sep 2012 08:23:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 813C820C08; Wed, 26 Sep 2012 08:23:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C24732202F6E; Wed, 26 Sep 2012 08:23:18 +0200 (CEST) Date: Wed, 26 Sep 2012 08:23:18 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120926062318.GB58005@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20120924.123926.835537078326158636.mbj@tail-f.com> <20120925072208.GB52571@elstar.local> <20120925.171148.493408222.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120925.171148.493408222.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 26 Sep 2012 06:23:26 -0000 On Tue, Sep 25, 2012 at 05:11:48PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Sep 24, 2012 at 02:19:17PM +0200, Ladislav Lhotka wrote: > > > > > > I think Juergen's proposal could work, too, although it is IMO > > > better to avoid potential differences in location semantics. I > > > assume that every device uses some kind of native interface > > > identifiers and these should appear in a clearly named leaf like > > > "local-name". Location can stay as an optional leaf, perhaps even > > > state data - on Linux it could contain e.g. the PCI address. > > > > I prefer to have one configurable reference to the 'hardware interface > > identifier as know by the underlying operating system' instead of > > two. > > Me too. And I do not think it would be a good idea to add another > indirection by using something like 'local-name'. > > > Perhaps all we need to do is to rename the leaf location > > If there is a better name, fine. But I think this is probably more > important: > > > and revise > > its description > > But the question is what we need to add. > > Note that there are really *two* leafs that together refer to the > correct hardware port - 'type' and 'location'. 'type' is needed as a > separate leaf since we base augmentation on the type. > > > and make it clear that the name leaf really carries an > > administratively assigned name. > > Hmm, does "administratively assigned name" imply "arbitrary"? If not, > what exactly does "administratively assigned" mean? Yes, it means an administrator assigns a name that he/she finds suitable, not necessarily a name the underlying system dictates. > > The concept of a location is not > > really well developed anyway > > I still think that you always can pick something relevant to use as a > location. It seems most router vendors have been able to do this for > some time now... > > I don't think we can find something more precise, that will be useful > across vendors / OSes. Some router vendors encode module/port numbers in interface names, but the result is really an encoding of location information into a name not just location information. The current text does not seem to imply that en5 or eth5 would be suitable 'location' values. I believe what we really store in the leaf is the system's local name of an interface, which might or might not include location information. > > Now we need a good name, "location" seems to restrictive and > > "local-name" is somewhat unclear as well (what is local?). Any > > ideas? > > > > And I think we need to capture some of the outcomes of this > > discussion. For example, that operating system level changes of > > interface names affect the 'yet-to-be-named' leaf identifying a > > hardware interface but not the 'name' of an interface. > > I don't think this is true in general. And implementing things this > way leads to a pretty bad user experience - for example, if you use > the kernel-assigned name as a 'location' on a linux system we have > seen that things might break down if you upgrade the kernel etc. This > is a well-known problem. So, the simple solution is to NOT use the > kernel-assigned name for hw-identiifcation purposes. But as you mentioned before, system level software can make sure interfaces are properly named. I think we need to tie into the local system's interface name since this is visible on other interfaces, e.g. MIBs, CLIs, SYSLOG. A kernel randomly naming interfaces is bad but the problem is bigger than just YANG data models. > > The definition > > of an RPC to initiate operating system level changes of interface > > names might be a future addition but has been left out for now. > > > > And perhaps we should add examples showing in addition to flat hw > > interface numbers and structured hw interface identifiers also the use > > of os-level interface names. Perhaps also text discussing how > > administratively assigned interface names can help moving configs > > around easily if either the physical connection changes or the hw > > interface identifier changes (e.g., due to firmware upgrades or > > physical movement of line cards). > > > I am actually still a bit confused. It is not clear to me what the > real problem with the current 'location' leaf is. This thread started > with a consensus call for some options that really boils down to > whether the name MUST be arbitrary or not. It seems to me that most > people preferred (a) - i.e., allow implementations to restrict the > name of the interface. > > Lada wanted an optional config false leaf 'local-name', which I guess > makes sense if the system implements a "mapping table" between the > configured name and the kernel-assigned name. You argue that location can't use the system's interface name as a value since that value might change arbitrarily still you argue that the system's interface name be used to name an interface even though that can change arbitrarily. /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 Sep 25 23:56: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 D570A21F87C8 for ; Tue, 25 Sep 2012 23:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMOSDfQ8n+2z for ; Tue, 25 Sep 2012 23:56:46 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BD9E721F8464 for ; Tue, 25 Sep 2012 23:56:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E2E351200048; Wed, 26 Sep 2012 08:56:43 +0200 (CEST) Date: Wed, 26 Sep 2012 08:56:43 +0200 (CEST) Message-Id: <20120926.085643.852255271947498935.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120926062318.GB58005@elstar.local> References: <20120925072208.GB52571@elstar.local> <20120925.171148.493408222.mbj@tail-f.com> <20120926062318.GB58005@elstar.local> X-Mailer: Mew version 6.4 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] interface keying - call for preferences 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, 26 Sep 2012 06:56:46 -0000 Juergen Schoenwaelder wrote: > On Tue, Sep 25, 2012 at 05:11:48PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > and make it clear that the name leaf really carries an > > > administratively assigned name. > > > > Hmm, does "administratively assigned name" imply "arbitrary"? If not, > > what exactly does "administratively assigned" mean? > > Yes, it means an administrator assigns a name that he/she finds > suitable, not necessarily a name the underlying system dictates. So going back to your original poll in this thread, it seems you prefer alternative (b), right? > > > The concept of a location is not > > > really well developed anyway > > > > I still think that you always can pick something relevant to use as a > > location. It seems most router vendors have been able to do this for > > some time now... > > > > I don't think we can find something more precise, that will be useful > > across vendors / OSes. > > Some router vendors encode module/port numbers in interface names, but > the result is really an encoding of location information into a name > not just location information. The current text does not seem to imply > that en5 or eth5 would be suitable 'location' values. I think the current text allows this. It says: The device-specific location of the interface of a particular type. The format of the location string depends on the interface type and the device. Doesn't that imply that a device can pick any format it likes? > I believe what > we really store in the leaf is the system's local name of an > interface, which might or might not include location information. My concern with this approach is that you most probably get information overlap. In order to configure an interface, you'll need to do: name: acme type: ethernetCsmacd local-name: eth1 With the current proposal, there is overlap only if the device imposes the name restrictions: name: fastethernet-1/0 type: ethernetCsmacd location: 1/0 If the device does not impose any restrictions, you can do: name: acme type: ethernetCsmacd location: 1/0 > > > Now we need a good name, "location" seems to restrictive and > > > "local-name" is somewhat unclear as well (what is local?). Any > > > ideas? > > > > > > And I think we need to capture some of the outcomes of this > > > discussion. For example, that operating system level changes of > > > interface names affect the 'yet-to-be-named' leaf identifying a > > > hardware interface but not the 'name' of an interface. > > > > I don't think this is true in general. And implementing things this > > way leads to a pretty bad user experience - for example, if you use > > the kernel-assigned name as a 'location' on a linux system we have > > seen that things might break down if you upgrade the kernel etc. This > > is a well-known problem. So, the simple solution is to NOT use the > > kernel-assigned name for hw-identiifcation purposes. > > But as you mentioned before, system level software can make sure > interfaces are properly named. I think we need to tie into the local > system's interface name since this is visible on other interfaces, > e.g. MIBs, CLIs, SYSLOG. I think that a device that implements these arbitrary interface name, will use the arbitrary name "locally", i.e., this arbitrary name will show up in SNMP, CLI, SYSLOG. This is how it works on Linux, according to lada. > A kernel randomly naming interfaces is bad > but the problem is bigger than just YANG data models. Agreed. > > > The definition > > > of an RPC to initiate operating system level changes of interface > > > names might be a future addition but has been left out for now. > > > > > > And perhaps we should add examples showing in addition to flat hw > > > interface numbers and structured hw interface identifiers also the use > > > of os-level interface names. Perhaps also text discussing how > > > administratively assigned interface names can help moving configs > > > around easily if either the physical connection changes or the hw > > > interface identifier changes (e.g., due to firmware upgrades or > > > physical movement of line cards). > > > > > > I am actually still a bit confused. It is not clear to me what the > > real problem with the current 'location' leaf is. This thread started > > with a consensus call for some options that really boils down to > > whether the name MUST be arbitrary or not. It seems to me that most > > people preferred (a) - i.e., allow implementations to restrict the > > name of the interface. > > > > Lada wanted an optional config false leaf 'local-name', which I guess > > makes sense if the system implements a "mapping table" between the > > configured name and the kernel-assigned name. > > You argue that location can't use the system's interface name as a > value since that value might change arbitrarily I argue that IF the kernel-assigned name can change "arbitrarily", THEN it is a bad idead to use the kernel-assigned name for identification purposes. If the kernel-assigned name does not change "arbitrarily", then it can be used. > still you argue that > the system's interface name be used to name an interface even though > that can change arbitrarily. I hope I didn't say that :) /martin From jernej.tuljak@mg-soft.si Wed Sep 26 00:51: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 C17D721F87CB for ; Wed, 26 Sep 2012 00:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY+A90jaHJTJ for ; Wed, 26 Sep 2012 00:51:43 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D940921F87C5 for ; Wed, 26 Sep 2012 00:51:42 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8Q7pfp5023127 for ; Wed, 26 Sep 2012 09:51:41 +0200 Message-ID: <5062B40C.109@mg-soft.com> Date: Wed, 26 Sep 2012 09:51:40 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <20120921154850.6A92C72E038@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 07:51:43 -0000 Dne 25.9.2012 12:22, piše Ladislav Lhotka: > Hi, > > this bug is now fixed in pyang. I only used a different name ("tag") for the attribute of the element, in order to follow the YIN convention. So the annotation looks e.g. like this: > > > > Please try it out. Didn't test the transformation, but since changes to it are semantically equivalent to what I did to fix this and it works for us, I can assume it works for you. Our hybrid schema were exactly the same, except for attribute naming. Jernej > Thanks, Lada > > RFC Errata System writes: > >> The following errata report has been submitted for RFC6110, >> "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6110&eid=3362 >> >> -------------------------------------- >> Type: Technical >> Reported by: Jernej Tuljak >> >> Section: 10.55. >> >> Original Text >> ------------- >> The 'unique' Statement >> >> This statement is mapped to the @nma:unique attribute. ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @nma:unique attribute. >> >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following attribute/value pair: >> >> nma:unique="ex:foo ex:bar/ex:baz" >> >> Corrected Text >> -------------- >> The 'unique' Statement >> >> This statement is mapped to the element. It has one >> mandatory attribute @key (with no namespace). ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @key attribute. >> >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following element: >> >> >> >> Notes >> ----- >> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6110 (draft-ietf-netmod-dsdl-map-10) >> -------------------------------------- >> Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content >> Publication Date : February 2011 >> Author(s) : L. Lhotka, Ed. >> Category : PROPOSED STANDARD >> Source : NETCONF Data Modeling Language >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From lhotka@nic.cz Wed Sep 26 01:07: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 836E921F87ED for ; Wed, 26 Sep 2012 01:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9vdPYCOSMdC for ; Wed, 26 Sep 2012 01:07:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5A67321F87F8 for ; Wed, 26 Sep 2012 01:07:12 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3218F140074; Wed, 26 Sep 2012 10:07:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1348646827; bh=YxmjzHBKYigvLGAD2uDdx7FWeMkqqdK49bP3+vPj8rQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K2eRxW+P5jCpxSR07eItFvsQpciPA8YRBi5GE31O1a59DPuRlwYX6QL5MgHmtUDwr 4LuZml2qDE3s3qgn3ZPfc9ZQappvt5Q2IMvWGFdf8FFPl50nhmzuY+KAVmNecYOUDG k1itChkKpxQm/4HMe5/ZKIGx2betaNRZg5ySHXtY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Ladislav Lhotka In-Reply-To: <5062B40C.109@mg-soft.com> Date: Wed, 26 Sep 2012 10:07:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120921154850.6A92C72E038@rfc-editor.org> <5062B40C.109@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1498) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 08:07:13 -0000 On Sep 26, 2012, at 9:51 AM, Jernej Tuljak = wrote: > Dne 25.9.2012 12:22, pi=9Ae Ladislav Lhotka: >> Hi, >>=20 >> this bug is now fixed in pyang. I only used a different name ("tag") = for the attribute of the element, in order to follow the = YIN convention. So the annotation looks e.g. like this: >>=20 >> >>=20 >> Please try it out. >=20 > Didn't test the transformation, but since changes to it are = semantically equivalent to what I did to fix this and it works for us, I = can assume it works for you. Our hybrid schema were exactly the same, = except for attribute naming. OK, thanks. Will you change the attribute name, so that we don't differ = on this? Lada =20 >=20 > Jernej >=20 >> Thanks, Lada >>=20 >> RFC Errata System writes: >>=20 >>> The following errata report has been submitted for RFC6110, >>> "Mapping YANG to Document Schema Definition Languages and Validating = NETCONF Content". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6110&eid=3D3362 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Jernej Tuljak >>>=20 >>> Section: 10.55. >>>=20 >>> Original Text >>> ------------- >>> The 'unique' Statement >>>=20 >>> This statement is mapped to the @nma:unique attribute. ARGUMENT = MUST >>> be translated so that every node identifier in each of its = components >>> is prefixed with the namespace prefix of the local module, unless = the >>> prefix is already present. The result of this translation then >>> becomes the value of the @nma:unique attribute. >>>=20 >>> For example, assuming that the local module prefix is "ex", >>>=20 >>> unique "foo ex:bar/baz" >>>=20 >>> is mapped to the following attribute/value pair: >>>=20 >>> nma:unique=3D"ex:foo ex:bar/ex:baz" >>>=20 >>> Corrected Text >>> -------------- >>> The 'unique' Statement >>>=20 >>> This statement is mapped to the element. It has one >>> mandatory attribute @key (with no namespace). ARGUMENT MUST >>> be translated so that every node identifier in each of its = components >>> is prefixed with the namespace prefix of the local module, unless = the >>> prefix is already present. The result of this translation then >>> becomes the value of the @key attribute. >>>=20 >>> For example, assuming that the local module prefix is "ex", >>>=20 >>> unique "foo ex:bar/baz" >>>=20 >>> is mapped to the following element: >>>=20 >>> >>>=20 >>> Notes >>> ----- >>> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot = be mapped into a single @nma:unique attribute. It should be mapped into = an element instead, much like the must-stmt. Additional changes may be = required throughout the document. >>>=20 >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC6110 (draft-ietf-netmod-dsdl-map-10) >>> -------------------------------------- >>> Title : Mapping YANG to Document Schema Definition = Languages and Validating NETCONF Content >>> Publication Date : February 2011 >>> Author(s) : L. Lhotka, Ed. >>> Category : PROPOSED STANDARD >>> Source : NETCONF Data Modeling Language >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Wed Sep 26 01:12: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 1B47321F87E5 for ; Wed, 26 Sep 2012 01:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcJvIQ-vk87l for ; Wed, 26 Sep 2012 01:12:29 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 17BC521F87CB for ; Wed, 26 Sep 2012 01:12:27 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8Q8CMAS023516; Wed, 26 Sep 2012 10:12:22 +0200 Message-ID: <5062B8E4.6090303@mg-soft.com> Date: Wed, 26 Sep 2012 10:12:20 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Benoit Claise , Ladislav Lhotka References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> In-Reply-To: <506022CA.9030200@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rbonica@juniper.net, lhotka@cesnet.cz, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 08:12:30 -0000 Dne 24.9.2012 11:07, piše Benoit Claise: > Hi, > > How do we want to treat this? > Updating the errata 3362, or a new one? > We should probably determine what the text of the errata should be. The one I reported is now outdated, so unless it can be updated, a new one should be created. As far as I can see the changes to Table 2, 12.16. title (plus TOC entry) and 11.2. are of an editorial nature only ("@nma:unique" --> ""). I've already posted what I think the content of 10.55. should be and I don't mind the attribute being renamed to "@tag" (the way Ladislav suggested). Honestly, I put the first word that popped into my mind when I created the report. We could also forget about using an attribute and just put the unique-stmt's argument into the text value of the element but I would prefer to have it as an attribute (also seems like a less invasive change). The "unique-attribute" definition in Appendix A should be changed from to (I think). The content of 12.16. also needs modification so it reflects the change made in 10.55. The mapping of this annotation is almost identical as for @nma:key, see Section 12.8, with two small differences: o The value of @nma:unique is a list of descendant schema node identifiers rather than simple leaf names. However, the XPath expressions specified in Section 12.8 work without any modifications if the descendant schema node identifiers are substituted for k_1, k_2, ..., k_n. o The message appearing as the text of is different: "Violated uniqueness for list CONTELEM". could be The mapping of this annotation element's @tag attribute is almost identical as for @nma:key, see Section 12.8, with two small differences: o The value of @tag is a list of descendant schema node identifiers rather than simple leaf names. However, the XPath expressions specified in Section 12.8 work without any modifications if the descendant schema node identifiers are substituted for k_1, k_2, ..., k_n. o The message appearing as the text of is different: "Violated uniqueness for list CONTELEM". Only the @tag attribute of this annotation element is mapped. but it may have to be rewritten to make it clearer. Jernej > Regards, Benoit. >> On Sep 24, 2012, at 10:35 AM, Juergen Schoenwaelder >> wrote: >> >>> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >>> >>> [...] >>> >>>> Notes >>>> ----- >>>> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot >>>> be mapped into a single @nma:unique attribute. It should be mapped >>>> into an element instead, much like the must-stmt. Additional >>>> changes may be required throughout the document. >>>> >>> Would it make sense to identify the other changes that may be >>> required? I quick search leads to: >>> >>> - Table 2 >>> - 2nd paragraph of section 11.2 >>> - section 12.16 (including its title) >>> - definition of unique-attribute in appendix A >> Yes, this list (+ section 10.55) is all that needs to be changed. >> >> Lada >> >>> Anything else I am missing? >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> -- >> Ladislav Lhotka >> PGP Key ID: E74E8C0C >> >> >> >> >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Wed Sep 26 01:19: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 B872021F8674 for ; Wed, 26 Sep 2012 01:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1raSUzzkIY4A for ; Wed, 26 Sep 2012 01:19:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6F21F87A5 for ; Wed, 26 Sep 2012 01:19:07 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7A00F140074; Wed, 26 Sep 2012 10:19:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1348647546; bh=+TgJ72cLOWIMe3Lje2HqXXm2Anf7KcjcPnRbGwkt9TY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=C6BzdKMYWZldZ4zBCitJgqVcFwRmhj0wxLc8K6nyuvzARcN5FwU7KbBYaVLMKLRVu gpLUH3381VZDCYT0j2tAy2g4MkVcgmPVRAEkx41p6NY99/kvr6xReNm8Y2+0CIuOkI o1KWsL9JK8Kp0SEouCSQm9Zo38SAN1e2d9ZUDhz0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Ladislav Lhotka In-Reply-To: <5062B8E4.6090303@mg-soft.com> Date: Wed, 26 Sep 2012 10:19:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1498) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Ladislav Lhotka , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 08:19:08 -0000 On Sep 26, 2012, at 10:12 AM, Jernej Tuljak = wrote: > Dne 24.9.2012 11:07, pi=9Ae Benoit Claise: >> Hi, >>=20 >> How do we want to treat this? >> Updating the errata 3362, or a new one? >>=20 >=20 > We should probably determine what the text of the errata should be. = The one I reported is now outdated, so unless it can be updated, a new = one should be created. I don't have any experience with the errata procedure but I think the = first decision should be whether this qualifies as an erratum, because = indeed it changes the DSDL mapping "protocol", as Martin pointed out. Who is entitled to make this decision? Lada =20 >=20 > As far as I can see the changes to Table 2, 12.16. title (plus TOC = entry) and 11.2. are of an editorial nature only ("@nma:unique" --> = ""). >=20 > I've already posted what I think the content of 10.55. should be and I = don't mind the attribute being renamed to "@tag" (the way Ladislav = suggested). Honestly, I put the first word that popped into my mind when = I created the report. We could also forget about using an attribute and = just put the unique-stmt's argument into the text value of the = element but I would prefer to have it as an attribute (also = seems like a less invasive change). >=20 > The "unique-attribute" definition in Appendix A should be changed from >=20 > > > > > > > > > >=20 > to >=20 > > > > > > > > > > > >=20 > (I think). >=20 > The content of 12.16. also needs modification so it reflects the = change made in 10.55. >=20 > The mapping of this annotation is almost identical as for @nma:key, > see Section 12.8, with two small differences: >=20 > o The value of @nma:unique is a list of descendant schema node > identifiers rather than simple leaf names. However, the XPath > expressions specified in Section 12.8 work without any > modifications if the descendant schema node identifiers are > substituted for k_1, k_2, ..., k_n. >=20 > o The message appearing as the text of is different: > "Violated uniqueness for list CONTELEM". >=20 > could be >=20 > The mapping of this annotation element's @tag attribute is almost > identical as for @nma:key, see Section 12.8, with two small = differences: >=20 > o The value of @tag is a list of descendant schema node > identifiers rather than simple leaf names. However, the XPath > expressions specified in Section 12.8 work without any > modifications if the descendant schema node identifiers are > substituted for k_1, k_2, ..., k_n. >=20 > o The message appearing as the text of is different: > "Violated uniqueness for list CONTELEM". >=20 > Only the @tag attribute of this annotation element is mapped. >=20 > but it may have to be rewritten to make it clearer. >=20 > Jernej >=20 >> Regards, Benoit. >>> On Sep 24, 2012, at 10:35 AM, Juergen Schoenwaelder = wrote: >>>=20 >>>> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >>>>=20 >>>> [...] >>>>=20 >>>>> Notes >>>>> ----- >>>>> A list's unique-stmt has a cardinality of 0..1. Therefore it = cannot be mapped into a single @nma:unique attribute. It should be = mapped into an element instead, much like the must-stmt. Additional = changes may be required throughout the document. >>>>>=20 >>>> Would it make sense to identify the other changes that may be >>>> required? I quick search leads to: >>>>=20 >>>> - Table 2 >>>> - 2nd paragraph of section 11.2 >>>> - section 12.16 (including its title) >>>> - definition of unique-attribute in appendix A >>> Yes, this list (+ section 10.55) is all that needs to be changed. >>>=20 >>> Lada >>>=20 >>>> Anything else I am missing? >>>>=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 >>> Ladislav Lhotka >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Sep 26 02:37:38 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 3D43821F87B5 for ; Wed, 26 Sep 2012 02:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCyHwgdBoT7X for ; Wed, 26 Sep 2012 02:37:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 80E6721F8600 for ; Wed, 26 Sep 2012 02:37:37 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D161B20C2F; Wed, 26 Sep 2012 11:37:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lypE6PSV3U9X; Wed, 26 Sep 2012 11:37:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2519620C68; Wed, 26 Sep 2012 11:37:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5F9B12203689; Wed, 26 Sep 2012 11:37:28 +0200 (CEST) Date: Wed, 26 Sep 2012 11:37:27 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120926093725.GA58512@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jernej Tuljak , Ladislav Lhotka , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ladislav Lhotka , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 09:37:38 -0000 On Wed, Sep 26, 2012 at 10:19:08AM +0200, Ladislav Lhotka wrote: > > On Sep 26, 2012, at 10:12 AM, Jernej Tuljak wrote: > > > Dne 24.9.2012 11:07, piÅ¡e Benoit Claise: > >> Hi, > >> > >> How do we want to treat this? > >> Updating the errata 3362, or a new one? > >> > > > > We should probably determine what the text of the errata should be. The one I reported is now outdated, so unless it can be updated, a new one should be created. > > I don't have any experience with the errata procedure but I think the first decision should be whether this qualifies as an erratum, because indeed it changes the DSDL mapping "protocol", as Martin pointed out. > > Who is entitled to make this decision? > I have moved this question over to Benoit since I think we need advice from the ADs here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Wed Sep 26 02:49: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 D91CF21F87BD for ; Wed, 26 Sep 2012 02:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.672 X-Spam-Level: X-Spam-Status: No, score=-4.672 tagged_above=-999 required=5 tests=[AWL=-2.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KklPwjzHw98q for ; Wed, 26 Sep 2012 02:49:49 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD2721F87BC for ; Wed, 26 Sep 2012 02:49:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8Q9niDc012100; Wed, 26 Sep 2012 11:49:44 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8Q9ngEH007272; Wed, 26 Sep 2012 11:49:42 +0200 (CEST) Message-ID: <5062CFB6.3060502@cisco.com> Date: Wed, 26 Sep 2012 11:49:42 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: jernej.tuljak@mg-soft.com, lhotka@cesnet.cz, rbonica@juniper.net, david.kessens@nsn.com, netmod@ietf.org References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> In-Reply-To: <20120924083532.GB7097@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 09:49:50 -0000 Dear all, While I'm researching on the question "how far can we go with an errata", could someone please send to the list the OLD/NEW changes for the list below. That would help for the evaluation. Regards, Benoit. > On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: > > [...] > >> Notes >> ----- >> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. >> > Would it make sense to identify the other changes that may be > required? I quick search leads to: > > - Table 2 > - 2nd paragraph of section 11.2 > - section 12.16 (including its title) > - definition of unique-attribute in appendix A > > Anything else I am missing? > > /js > From lhotka@nic.cz Wed Sep 26 04:57: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 7C71821F8820 for ; Wed, 26 Sep 2012 04:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xoeit2P9pgM6 for ; Wed, 26 Sep 2012 04:57:03 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 908CD21F881F for ; Wed, 26 Sep 2012 04:57:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9A37D5402F0 for ; Wed, 26 Sep 2012 13:56:57 +0200 (CEST) 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 gOLiPstD+lvi for ; Wed, 26 Sep 2012 13:56:51 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 216A1540113 for ; Wed, 26 Sep 2012 13:56:47 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120925.171148.493408222.mbj@tail-f.com> References: <20120924.123926.835537078326158636.mbj@tail-f.com> <20120925072208.GB52571@elstar.local> <20120925.171148.493408222.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 26 Sep 2012 13:56:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface keying - call for preferences 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, 26 Sep 2012 11:57:04 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Mon, Sep 24, 2012 at 02:19:17PM +0200, Ladislav Lhotka wrote: >> > >> > I think Juergen's proposal could work, too, although it is IMO >> > better to avoid potential differences in location semantics. I >> > assume that every device uses some kind of native interface >> > identifiers and these should appear in a clearly named leaf like >> > "local-name". Location can stay as an optional leaf, perhaps even >> > state data - on Linux it could contain e.g. the PCI address. >> >> I prefer to have one configurable reference to the 'hardware interface >> identifier as know by the underlying operating system' instead of >> two. > > Me too. And I do not think it would be a good idea to add another > indirection by using something like 'local-name'. > >> Perhaps all we need to do is to rename the leaf location > > If there is a better name, fine. But I think this is probably more > important: > >> and revise >> its description > > But the question is what we need to add. Device-specific name of the interface which is used, e. g., at the device's local console. > > Note that there are really *two* leafs that together refer to the > correct hardware port - 'type' and 'location'. 'type' is needed as a > separate leaf since we base augmentation on the type. I don't think so - local-name, or whatever it is called, should be sufficient. The 'type' can stay and may still be used in the same way for augments. > >> and make it clear that the name leaf really carries an >> administratively assigned name. > > Hmm, does "administratively assigned name" imply "arbitrary"? If not, > what exactly does "administratively assigned" mean? I think it should be arbitrary, and the name needn't exist outside NETCONF. > >> The concept of a location is not >> really well developed anyway > > I still think that you always can pick something relevant to use as a > location. It seems most router vendors have been able to do this for > some time now... > > I don't think we can find something more precise, that will be useful > across vendors / OSes. Platform-specific data with more descriptive names can be augmented, for Linux it could be "pci-address". However, this information is no more crucial. > >> Now we need a good name, "location" seems to restrictive and >> "local-name" is somewhat unclear as well (what is local?). Any >> ideas? >> >> And I think we need to capture some of the outcomes of this >> discussion. For example, that operating system level changes of >> interface names affect the 'yet-to-be-named' leaf identifying a >> hardware interface but not the 'name' of an interface. > > I don't think this is true in general. And implementing things this > way leads to a pretty bad user experience - for example, if you use > the kernel-assigned name as a 'location' on a linux system we have > seen that things might break down if you upgrade the kernel etc. This > is a well-known problem. So, the simple solution is to NOT use the > kernel-assigned name for hw-identiifcation purposes. What I think is important is not to use the native name as the key of the "interface" list. It that name is in another leaf, it is easy to update the configuration if the native name changes. > >> The definition >> of an RPC to initiate operating system level changes of interface >> names might be a future addition but has been left out for now. >> >> And perhaps we should add examples showing in addition to flat hw >> interface numbers and structured hw interface identifiers also the use >> of os-level interface names. Perhaps also text discussing how >> administratively assigned interface names can help moving configs >> around easily if either the physical connection changes or the hw >> interface identifier changes (e.g., due to firmware upgrades or >> physical movement of line cards). > > > I am actually still a bit confused. It is not clear to me what the > real problem with the current 'location' leaf is. This thread started > with a consensus call for some options that really boils down to > whether the name MUST be arbitrary or not. It seems to me that most > people preferred (a) - i.e., allow implementations to restrict the > name of the interface. > > Lada wanted an optional config false leaf 'local-name', which I guess > makes sense if the system implements a "mapping table" between the > configured name and the kernel-assigned name. I have never said that 'local-name' can be config false because it realizes the binding between the (arbitrary) name of an 'interface' entry and physical interface. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Sep 26 05:53:34 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 9CE8421F8452 for ; Wed, 26 Sep 2012 05:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm9zbOz4zjvv for ; Wed, 26 Sep 2012 05:53:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5531221F8464 for ; Wed, 26 Sep 2012 05:53:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C094A5402F0; Wed, 26 Sep 2012 14:53:30 +0200 (CEST) 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 J6vIB+NkTXfC; Wed, 26 Sep 2012 14:53:26 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7DA42540049; Wed, 26 Sep 2012 14:53:21 +0200 (CEST) From: Ladislav Lhotka To: Benoit Claise , jernej.tuljak@mg-soft.com, rbonica@juniper.net, david.kessens@nsn.com, netmod@ietf.org In-Reply-To: <5062CFB6.3060502@cisco.com> References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <5062CFB6.3060502@cisco.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Benoit Claise , jernej.tuljak@mg-soft.com, rbonica@juniper.net, david.kessens@nsn.com, netmod@ietf.org Date: Wed, 26 Sep 2012 14:53:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 26 Sep 2012 12:53:34 -0000 Benoit Claise writes: > Dear all, > > While I'm researching on the question "how far can we go with an > errata", could someone please send to the list the OLD/NEW changes for > the list below. That would help for the evaluation. Here it is: Sec. 5.3, entry in Table 2: --------------------------- OLD | @nma:unique | 10.55 | | NEW | | 10.55 | | Sec. 10.55: ----------- OLD This statement is mapped to the @nma:unique attribute. ARGUMENT MUST be translated so that every node identifier in each of its components is prefixed with the namespace prefix of the local module, unless the prefix is already present. The result of this translation then becomes the value of the @nma:unique attribute. For example, assuming that the local module prefix is "ex", unique "foo ex:bar/baz" is mapped to the following attribute/value pair: nma:unique="ex:foo ex:bar/ex:baz" NEW This statement is mapped to the element. ARGUMENT MUST be translated so that every node identifier in each of its components is prefixed with the namespace prefix of the local module, unless the prefix is already present. The result of this translation then becomes the value of the @tag attribute which is attached to the element. For example, assuming that the local module prefix is "ex", unique "foo ex:bar/baz" is mapped to the following annotation element: Sec. 11.2, second paragraph: ---------------------------- OLD In a Schematron schema generated by the second mapping step, the basic unit of organization is a rule represented by the element. The following NETMOD-specific annotations from the hybrid schema (henceforth called "semantic annotations") are mapped to corresponding Schematron rules: , @nma:key, @nma:unique, @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: leaf-list, and also @nma:mandatory appearing as an attribute of (see Section 11.2.1). NEW In a Schematron schema generated by the second mapping step, the basic unit of organization is a rule represented by the element. The following NETMOD-specific annotations from the hybrid schema (henceforth called "semantic annotations") are mapped to corresponding Schematron rules: , , @nma:key, @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: leaf-list, and also @nma:mandatory appearing as an attribute of (see Section 11.2.1). Sec. 12.16 (including its title): ----------- OLD 12.16. The @nma:unique Annotation The mapping of this annotation is almost identical as for @nma:key, see Section 12.8, with two small differences: o The value of @nma:unique is a list of descendant schema node identifiers rather than simple leaf names. However, the XPath expressions specified in Section 12.8 work without any modifications if the descendant schema node identifiers are substituted for k_1, k_2, ..., k_n. o The message appearing as the text of is different: "Violated uniqueness for list CONTELEM". NEW 12.16. The Annotation The mapping of this annotation is similar to @nma:key, see Section 12.8, with two small differences: o The value of the @tag attribute of is a list of descendant schema node identifiers rather than simple leaf names. However, the XPath expressions specified in Section 12.8 work without any modifications if the descendant schema node identifiers are substituted for k_1, k_2, ..., k_n. o The message appearing as the text of is different: "Violated uniqueness of NODES", where NODES is the value of the @tag attribute. Appendix A: ----------- OLD NEW Thanks, Lada > > Regards, Benoit. >> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >> >> [...] >> >>> Notes >>> ----- >>> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. >>> >> Would it make sense to identify the other changes that may be >> required? I quick search leads to: >> >> - Table 2 >> - 2nd paragraph of section 11.2 >> - section 12.16 (including its title) >> - definition of unique-attribute in appendix A >> >> Anything else I am missing? >> >> /js >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From muthu@cisco.com Wed Sep 26 22:34:14 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 1526921F8555 for ; Wed, 26 Sep 2012 22:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyJ1HTfjFSmC for ; Wed, 26 Sep 2012 22:34:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CD6CA21F853E for ; Wed, 26 Sep 2012 22:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12323; q=dns/txt; s=iport; t=1348724053; x=1349933653; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=NdJXfZc6aAvyUjq8I3iyluXhqSjtYOvJ6rl6pIBtlxQ=; b=SjBSFONK11nJuxGxDxtlgDJ7LhfgeTG2maGiodb+viCaZ8sl+1uO/a2z Uj8Z1IZzUrHm1uy7bzoqeYi5wXlQDSkMP+kq+Rsb8Oo9ZhwMs4zeBks3V LEbIeb4pMEFOXf2Nm2rOeXXSRXwFN5H7QW7Fa5Wg+Rg3T0l+6fH943gGV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD3kY1CtJV2Y/2dsb2JhbABFgku7QoEIgiABAgQSARpeAQgRAwECKDkUCQgBAQQBEgkZh2MLl1agDYsYhh0DlWmOQoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,493,1344211200"; d="scan'208,217";a="125801880" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 27 Sep 2012 05:34:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8R5YCfu021137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Sep 2012 05:34:12 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.58]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 27 Sep 2012 00:34:12 -0500 From: "Muthumayan Madhayyan (muthu)" To: "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwUlCAGA Date: Thu, 27 Sep 2012 05:34:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.83.162] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--40.126100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC892C3E5094Fmuthuciscocom_" MIME-Version: 1.0 Subject: Re: [netmod] YANG module for ACL configuration 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, 27 Sep 2012 05:34:14 -0000 --_000_CC892C3E5094Fmuthuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One other useful RPC for this ACL module would be a mechanism to re-sequenc= e ACE sequence numbers. Something like: rpc resequence-acl { description "This RPC is to re-number sequence numbers of ACE entr= ies in an ACL. The first ACE entry would use the 'start' number and su= bsequent ACE entries would be assigned increasing sequence numbers 'interva= l' apart. "; input { leaf acl-name { type string; mandatory true; description "This name is the acl name."; } leaf start { type Sequence-Number; description "Starting sequence-num for the first ACE in an ACL."; } leaf interval { type uint32; description "Gap between sequence number assigned to consecutive A= CE entries"; } } } Thanks, - muthu From: "Alexander Clemm (alex)" > Date: Friday, August 31, 2012 4:03 PM To: "netmod@ietf.org" > Subject: [netmod] YANG module for ACL configuration Dear All, we have just posted an Internet Draft of a YANG model for ACL configuration= : http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt This document defines a YANG data model for Access Control Lists (ACLs) on = a device. An ACL is an ordered set of rules that is used to filter traffic = on a networking device. In the draft you will find details of how the model= is designed and the corresponding YANG modules. We are hoping that this model is of interest to this group. Please take a = look and let us know your thoughts and comments. Thanks, Alex & Lisa --_000_CC892C3E5094Fmuthuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
One other useful RPC for this ACL module would be a mechanism to re-se= quence ACE sequence numbers.

Something like:

     rpc resequence=
-acl {
         description "This RPC is to re-number sequence numbers of ACE=
 entries 
         in an ACL.=
 The first ACE entry would use the 'start' number and subsequent
         ACE entrie=
s would be assigned increasing sequence numbers 'interval' apart. ";

         input {
             leaf acl-name {
                 type string;
                 mandatory true;
                 description "This name is the acl name.";
             }
             leaf start {
                 type Sequence-Number;
                 description
                     "Starting sequence-num for the first ACE in an AC=
L.";


             }

             leaf i=
nterval {


              =
   type uint32;
                 description
                     "Gap between sequence number assigned to consecut=
ive ACE entries";
             }
         }
     }




Thanks,


- muthu


From: "Alexander Clemm (alex)&= quot; <alex@cisco.com>
Date: Friday, August 31, 2012 4:03 = PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] YANG module for A= CL configuration

Dear All,

 

we have just posted an Internet Draft of a YANG m= odel for ACL configuration:

http://www.ietf.org/internet-drafts/draft-huan= g-netmod-acl-00.txt

 

This document defines a YANG data model for Acces= s Control Lists (ACLs) on a device. An ACL is an ordered set of rules that = is used to filter traffic on a networking device. In the draft you will fin= d details of how the model is designed and the corresponding YANG modules. 

 

We are hoping that this model is of interest to t= his group.  Please take a look and let us know your thoughts and comme= nts. 

 

Thanks,

 

Alex & Lisa

 

 

 --_000_CC892C3E5094Fmuthuciscocom_-- From lhotka@nic.cz Wed Sep 26 23:22:07 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 D79FE21F8462 for ; Wed, 26 Sep 2012 23:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn9dJiTmwvBw for ; Wed, 26 Sep 2012 23:22:07 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CE58921F845E for ; Wed, 26 Sep 2012 23:22:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 3248954032B for ; Thu, 27 Sep 2012 08:22:01 +0200 (CEST) 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 2XVuDOBdr9fE for ; Thu, 27 Sep 2012 08:21:56 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3666C5401CF for ; Thu, 27 Sep 2012 08:21:52 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120926.085643.852255271947498935.mbj@tail-f.com> References: <20120925072208.GB52571@elstar.local> <20120925.171148.493408222.mbj@tail-f.com> <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 27 Sep 2012 08:21:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface keying - call for preferences 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, 27 Sep 2012 06:22:08 -0000 Martin Bjorklund writes: > > My concern with this approach is that you most probably get > information overlap. In order to configure an interface, you'll > need to do: > > name: acme > type: ethernetCsmacd > local-name: eth1 It is not always so. The Ethernet interface on my Mac carries the name "en0" and FreeBSD uses names like "em0" or "bge1". Even on Linux we can have this: name: acme type: ethernetCsmacd local-name: foo > > With the current proposal, there is overlap only if the device imposes > the name restrictions: > > name: fastethernet-1/0 > type: ethernetCsmacd > location: 1/0 > > If the device does not impose any restrictions, you can do: > > name: acme > type: ethernetCsmacd > location: 1/0 On devices that do not use the concept of location consistently this means that the configuration contains no reliable info about the local interface name. > >> > > Now we need a good name, "location" seems to restrictive and >> > > "local-name" is somewhat unclear as well (what is local?). Any >> > > ideas? >> > > >> > > And I think we need to capture some of the outcomes of this >> > > discussion. For example, that operating system level changes of >> > > interface names affect the 'yet-to-be-named' leaf identifying a >> > > hardware interface but not the 'name' of an interface. >> > >> > I don't think this is true in general. And implementing things this >> > way leads to a pretty bad user experience - for example, if you use >> > the kernel-assigned name as a 'location' on a linux system we have >> > seen that things might break down if you upgrade the kernel etc. This >> > is a well-known problem. So, the simple solution is to NOT use the >> > kernel-assigned name for hw-identiifcation purposes. >> >> But as you mentioned before, system level software can make sure >> interfaces are properly named. I think we need to tie into the local >> system's interface name since this is visible on other interfaces, >> e.g. MIBs, CLIs, SYSLOG. > > I think that a device that implements these arbitrary interface name, > will use the arbitrary name "locally", i.e., this arbitrary name will > show up in SNMP, CLI, SYSLOG. This is how it works on Linux, > according to lada. We have to distinguish between two cases: 1. Local name of an interface can be changed to an arbitrary string at the system level. 2. The "name" key of the "interface" list is arbitrary. My point is that 2 should hold for any implementation of the interfaces module, independently of 1. The actual local name always has to be filled in the local-name leaf, no matter what the local name is - this realizes the link between NETCONF interface configuration and a physical interface. And the link can be easily updated in one place if the local name changes. Lada > >> A kernel randomly naming interfaces is bad >> but the problem is bigger than just YANG data models. > > Agreed. > >> > > The definition >> > > of an RPC to initiate operating system level changes of interface >> > > names might be a future addition but has been left out for now. >> > > >> > > And perhaps we should add examples showing in addition to flat hw >> > > interface numbers and structured hw interface identifiers also the use >> > > of os-level interface names. Perhaps also text discussing how >> > > administratively assigned interface names can help moving configs >> > > around easily if either the physical connection changes or the hw >> > > interface identifier changes (e.g., due to firmware upgrades or >> > > physical movement of line cards). >> > >> > >> > I am actually still a bit confused. It is not clear to me what the >> > real problem with the current 'location' leaf is. This thread started >> > with a consensus call for some options that really boils down to >> > whether the name MUST be arbitrary or not. It seems to me that most >> > people preferred (a) - i.e., allow implementations to restrict the >> > name of the interface. >> > >> > Lada wanted an optional config false leaf 'local-name', which I guess >> > makes sense if the system implements a "mapping table" between the >> > configured name and the kernel-assigned name. >> >> You argue that location can't use the system's interface name as a >> value since that value might change arbitrarily > > I argue that IF the kernel-assigned name can change "arbitrarily", > THEN it is a bad idead to use the kernel-assigned name for > identification purposes. > > If the kernel-assigned name does not change "arbitrarily", then it can > be used. > >> still you argue that >> the system's interface name be used to name an interface even though >> that can change arbitrarily. > > I hope I didn't say that :) > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Sep 27 00:00: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 06C0F21F86D3 for ; Thu, 27 Sep 2012 00:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozOGak4+FpJJ for ; Thu, 27 Sep 2012 00:00:29 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAC121F86D0 for ; Thu, 27 Sep 2012 00:00:29 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 741F01200D5F; Thu, 27 Sep 2012 09:00:27 +0200 (CEST) Date: Thu, 27 Sep 2012 09:00:27 +0200 (CEST) Message-Id: <20120927.090027.1105304236918687664.mbj@tail-f.com> To: muthu@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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, 27 Sep 2012 07:00:30 -0000 "Muthumayan Madhayyan (muthu)" wrote: > One other useful RPC for this ACL module would be a mechanism to > re-sequence ACE sequence numbers. This is the reason why YANG has ordered-by user lists. With an ordered-by user list you avoid the renumbering problem, and give the user the ability to move entires without renaming/renumbering them. Note that *if* such an RPC operation is introduced, it at least need to take the configuration datastore as argument (candidate, running). /martin > > Something like: > > > rpc resequence-acl { > description "This RPC is to re-number sequence numbers of ACE entries > > in an ACL. The first ACE entry would use the 'start' number and > subsequent > > ACE entries would be assigned increasing sequence numbers 'interval' > apart. "; > > input { > leaf acl-name { > type string; > mandatory true; > description "This name is the acl name."; > } > leaf start { > type Sequence-Number; > description > "Starting sequence-num for the first ACE in an ACL."; > > } > > leaf interval { > > type uint32; > description > "Gap between sequence number assigned to consecutive ACE > entries"; > > } > > } } > > Thanks, > > - muthu > > > From: "Alexander Clemm (alex)" > > Date: Friday, August 31, 2012 4:03 PM > To: "netmod@ietf.org" > > > Subject: [netmod] YANG module for ACL configuration > > > Dear All, > > > > we have just posted an Internet Draft of a YANG model for ACL > configuration: > > http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt > > > > This document defines a YANG data model for Access Control Lists > (ACLs) on a device. An ACL is an ordered set of rules that is used to > filter traffic on a networking device. In the draft you will find > details of how the model is designed and the corresponding YANG > modules. > > > > We are hoping that this model is of interest to this group. Please > take a look and let us know your thoughts and comments. > > > > Thanks, > > > > Alex & Lisa > > > From mbj@tail-f.com Thu Sep 27 00:16: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 C91EA21F86DF for ; Thu, 27 Sep 2012 00:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUI3Khp80LCa for ; Thu, 27 Sep 2012 00:16:58 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3DD21F86D9 for ; Thu, 27 Sep 2012 00:16:58 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D9BE21200D5F; Thu, 27 Sep 2012 09:16:56 +0200 (CEST) Date: Thu, 27 Sep 2012 09:16:56 +0200 (CEST) Message-Id: <20120927.091656.1385318774262851643.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interface keying - call for preferences 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, 27 Sep 2012 07:16:58 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > > > My concern with this approach is that you most probably get > > information overlap. In order to configure an interface, you'll > > need to do: > > > > name: acme > > type: ethernetCsmacd > > local-name: eth1 > > It is not always so. The Ethernet interface on my Mac carries the name > "en0" and FreeBSD uses names like "em0" or "bge1". But these are the names of the drivers, for the specific types. > Even on Linux we > can have this: > > name: acme > type: ethernetCsmacd > local-name: foo We *can*, but it depends on the implementation. > > With the current proposal, there is overlap only if the device imposes > > the name restrictions: > > > > name: fastethernet-1/0 > > type: ethernetCsmacd > > location: 1/0 > > > > If the device does not impose any restrictions, you can do: > > > > name: acme > > type: ethernetCsmacd > > location: 1/0 > > On devices that do not use the concept of location consistently this > means that the configuration contains no reliable info about the local > interface name. This is why a config false leaf 'local-name' would be useful. > We have to distinguish between two cases: > > 1. Local name of an interface can be changed to an arbitrary string at > the system level. > > 2. The "name" key of the "interface" list is arbitrary. > > My point is that 2 should hold for any implementation of the > interfaces module, independently of 1. > > The actual local name always has to be filled in the local-name leaf, > no matter what the local name is - this realizes the link between > NETCONF interface configuration and a physical interface. And the link > can be easily updated in one place if the local name changes. This means that the user somehow must figure out the kernel-assigned name for say the 4th ethernet port on the device. With a location leaf, you move this task to the implementation (*), and let the user just specify the location "4". This design at least makes it possible to do a user-friendly product... (*) it would still be up to each implementation. An implementation that wants to use the kernel-assigned name as hw-reference can still do that. /martin From bclaise@cisco.com Thu Sep 27 03:20: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 1656521F869D for ; Thu, 27 Sep 2012 03:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.678 X-Spam-Level: X-Spam-Status: No, score=-4.678 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwoess2kz79f for ; Thu, 27 Sep 2012 03:20:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3217321F869C for ; Thu, 27 Sep 2012 03:20:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8RAKBMY013883; Thu, 27 Sep 2012 12:20:11 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8RAK6mi013967; Thu, 27 Sep 2012 12:20:07 +0200 (CEST) Message-ID: <50642856.6030703@cisco.com> Date: Thu, 27 Sep 2012 12:20:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ladislav Lhotka , Jernej Tuljak , Ladislav Lhotka , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> In-Reply-To: <20120926093725.GA58512@elstar.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 27 Sep 2012 10:20:15 -0000 Dear all, >> I don't have any experience with the errata procedure but I think the first decision should be whether this qualifies as an erratum, because indeed it changes the DSDL mapping "protocol", as Martin pointed out. >> >> Who is entitled to make this decision? >> > I have moved this question over to Benoit since I think we need advice > from the ADs here. Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as background information... - As far as I can tell, we agree that this is a bug in the specification. So an errata should be filed. - As far as I can tell, we fall into: "Only errors that could cause implementation or deployment problems or significant confusion should be Approved." - As far as I can tell, we don't fall into: "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected" I'm in favor to keep the process simple, and to verify the errata, instead of producing a new RFC. However, before doing so, we want to be a safe side, basically making sure that there are no other implementations for which this bug fix (read non-backward compatibility change) would cause a problem. So let me propose the following: - We keep the errata 3362 open for now - Since errata 3362 needs to updated (and since we can't update this errata without approving/rejecting AFAIK), we create a new errata with all the changes, as agreed on the mailing list. Do we have an agreement on what Lada proposed? - I send a kind of LC email to the mailing list, with this new errata - If no issue during this LC, I reject errata 3362 (pointing to the new errata), and I verify the new one. Regards, Benoit. > /js > From bclaise@cisco.com Thu Sep 27 03:21: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 F0CB121F86BA for ; Thu, 27 Sep 2012 03:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.656 X-Spam-Level: X-Spam-Status: No, score=-8.656 tagged_above=-999 required=5 tests=[AWL=1.943, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wou7kFK9uWtj for ; Thu, 27 Sep 2012 03:21:16 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0521721F869D for ; Thu, 27 Sep 2012 03:21:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8RALCQo013969; Thu, 27 Sep 2012 12:21:12 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8RALBUA014615; Thu, 27 Sep 2012 12:21:11 +0200 (CEST) Message-ID: <50642897.9060700@cisco.com> Date: Thu, 27 Sep 2012 12:21:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: jernej.tuljak@mg-soft.com, rbonica@juniper.net, david.kessens@nsn.com, netmod@ietf.org References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <5062CFB6.3060502@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 27 Sep 2012 10:21:17 -0000 Hi Lada, Thanks for this. WG, any objections to the changes below? Regards, Benoit. > Benoit Claise writes: > >> Dear all, >> >> While I'm researching on the question "how far can we go with an >> errata", could someone please send to the list the OLD/NEW changes for >> the list below. That would help for the evaluation. > Here it is: > > Sec. 5.3, entry in Table 2: > --------------------------- > > OLD > > | @nma:unique | 10.55 | | > > NEW > > | | 10.55 | | > > Sec. 10.55: > ----------- > > OLD > > This statement is mapped to the @nma:unique attribute. ARGUMENT MUST > be translated so that every node identifier in each of its components > is prefixed with the namespace prefix of the local module, unless the > prefix is already present. The result of this translation then > becomes the value of the @nma:unique attribute. > > For example, assuming that the local module prefix is "ex", > > unique "foo ex:bar/baz" > > is mapped to the following attribute/value pair: > > nma:unique="ex:foo ex:bar/ex:baz" > > NEW > > This statement is mapped to the element. ARGUMENT MUST > be translated so that every node identifier in each of its components > is prefixed with the namespace prefix of the local module, unless the > prefix is already present. The result of this translation then > becomes the value of the @tag attribute which is attached to the > element. > > For example, assuming that the local module prefix is "ex", > > unique "foo ex:bar/baz" > > is mapped to the following annotation element: > > > > Sec. 11.2, second paragraph: > ---------------------------- > > OLD > > In a Schematron schema generated by the second mapping step, the > basic unit of organization is a rule represented by the > element. The following NETMOD-specific annotations from the hybrid > schema (henceforth called "semantic annotations") are mapped to > corresponding Schematron rules: , @nma:key, @nma:unique, > @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: > leaf-list, and also @nma:mandatory appearing as an attribute of choice> (see Section 11.2.1). > > NEW > > In a Schematron schema generated by the second mapping step, the > basic unit of organization is a rule represented by the > element. The following NETMOD-specific annotations from the hybrid > schema (henceforth called "semantic annotations") are mapped to > corresponding Schematron rules: , , @nma:key, > @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: > leaf-list, and also @nma:mandatory appearing as an attribute of choice> (see Section 11.2.1). > > Sec. 12.16 (including its title): > ----------- > > OLD > > 12.16. The @nma:unique Annotation > > The mapping of this annotation is almost identical as for @nma:key, > see Section 12.8, with two small differences: > > o The value of @nma:unique is a list of descendant schema node > identifiers rather than simple leaf names. However, the XPath > expressions specified in Section 12.8 work without any > modifications if the descendant schema node identifiers are > substituted for k_1, k_2, ..., k_n. > > o The message appearing as the text of is different: > "Violated uniqueness for list CONTELEM". > > NEW > > 12.16. The Annotation > > The mapping of this annotation is similar to @nma:key, > see Section 12.8, with two small differences: > > o The value of the @tag attribute of is a list of > descendant schema node identifiers rather than simple leaf names. > However, the XPath expressions specified in Section 12.8 work > without any modifications if the descendant schema node > identifiers are substituted for k_1, k_2, ..., k_n. > > o The message appearing as the text of is different: > "Violated uniqueness of NODES", where NODES is the value of the > @tag attribute. > > Appendix A: > ----------- > > OLD > > > > > > > > > > > > NEW > > > > > > > > > > > > Thanks, Lada > >> Regards, Benoit. >>> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >>> >>> [...] >>> >>>> Notes >>>> ----- >>>> A list's unique-stmt has a cardinality of 0..1. Therefore it cannot be mapped into a single @nma:unique attribute. It should be mapped into an element instead, much like the must-stmt. Additional changes may be required throughout the document. >>>> >>> Would it make sense to identify the other changes that may be >>> required? I quick search leads to: >>> >>> - Table 2 >>> - 2nd paragraph of section 11.2 >>> - section 12.16 (including its title) >>> - definition of unique-attribute in appendix A >>> >>> Anything else I am missing? >>> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From jernej.tuljak@mg-soft.si Thu Sep 27 05:03:23 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 AE0CE21F8456 for ; Thu, 27 Sep 2012 05:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBN66F5jCeY1 for ; Thu, 27 Sep 2012 05:03:23 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D30A521F8446 for ; Thu, 27 Sep 2012 05:03:22 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8RC3H9o013624; Thu, 27 Sep 2012 14:03:17 +0200 Message-ID: <50644083.2060805@mg-soft.com> Date: Thu, 27 Sep 2012 14:03:15 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Benoit Claise References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> In-Reply-To: <50642856.6030703@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, Ladislav Lhotka , rbonica@juniper.net, lhotka@cesnet.cz Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 27 Sep 2012 12:03:23 -0000 Dne 27.9.2012 12:20, piÅ¡e Benoit Claise: > Dear all, >>> I don't have any experience with the errata procedure but I think >>> the first decision should be whether this qualifies as an erratum, >>> because indeed it changes the DSDL mapping "protocol", as Martin >>> pointed out. >>> >>> Who is entitled to make this decision? >>> >> I have moved this question over to Benoit since I think we need advice >> from the ADs here. > > Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as > background information... > - As far as I can tell, we agree that this is a bug in the > specification. So an errata should be filed. > - As far as I can tell, we fall into: "Only errors that could cause > implementation or deployment problems or significant confusion should > be Approved." > - As far as I can tell, we don't fall into: "Changes that modify the > working of a protocol to something that might be different from the > intended consensus when the document was approved should be either > Hold for Document Update or Rejected" > > I'm in favor to keep the process simple, and to verify the errata, > instead of producing a new RFC. > > However, before doing so, we want to be a safe side, basically making > sure that there are no other implementations for which this bug fix > (read non-backward compatibility change) would cause a problem. > > So let me propose the following: > - We keep the errata 3362 open for now > - Since errata 3362 needs to updated (and since we can't update this > errata without approving/rejecting AFAIK), we create a new errata with > all the changes, as agreed on the mailing list. Do we have an > agreement on what Lada proposed? > - I send a kind of LC email to the mailing list, with this new errata > - If no issue during this LC, I reject errata 3362 (pointing to the > new errata), and I verify the new one. > I agree with this proposal. Jernej > Regards, Benoit. >> /js >> From jernej.tuljak@mg-soft.si Thu Sep 27 05:33: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 059B121F8464 for ; Thu, 27 Sep 2012 05:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFn6hhTa79AB for ; Thu, 27 Sep 2012 05:33:31 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D268521F845E for ; Thu, 27 Sep 2012 05:33:30 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q8RCXRGx014218; Thu, 27 Sep 2012 14:33:27 +0200 Message-ID: <50644795.5030202@mg-soft.com> Date: Thu, 27 Sep 2012 14:33:25 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Benoit Claise References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <5062CFB6.3060502@cisco.com> <50642897.9060700@cisco.com> In-Reply-To: <50642897.9060700@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rbonica@juniper.net, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 27 Sep 2012 12:33:32 -0000 Dne 27.9.2012 12:21, piše Benoit Claise: > Hi Lada, > > Thanks for this. > WG, any objections to the changes below? Table of contents is also a place where "@nma:unique" text appears, so perhaps the following is missing: Table of contents ------------------- OLD 12.16. The @nma:unique Annotation ..............................74 NEW 12.16. The Annotation .............................74 Not sure if this is necessary though, since "Sec. 12.16 (including its title)" might imply this change too. The rest seems okay to me. Jernej > > Regards, Benoit. > >> Benoit Claise writes: >> >>> Dear all, >>> >>> While I'm researching on the question "how far can we go with an >>> errata", could someone please send to the list the OLD/NEW changes for >>> the list below. That would help for the evaluation. >> Here it is: >> >> Sec. 5.3, entry in Table 2: >> --------------------------- >> >> OLD >> >> | @nma:unique | 10.55 | | >> >> NEW >> >> | | 10.55 | | >> >> Sec. 10.55: >> ----------- >> >> OLD >> >> This statement is mapped to the @nma:unique attribute. ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @nma:unique attribute. >> >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following attribute/value pair: >> >> nma:unique="ex:foo ex:bar/ex:baz" >> >> NEW >> >> This statement is mapped to the element. ARGUMENT MUST >> be translated so that every node identifier in each of its components >> is prefixed with the namespace prefix of the local module, unless the >> prefix is already present. The result of this translation then >> becomes the value of the @tag attribute which is attached to the >> element. >> >> For example, assuming that the local module prefix is "ex", >> >> unique "foo ex:bar/baz" >> >> is mapped to the following annotation element: >> >> >> >> Sec. 11.2, second paragraph: >> ---------------------------- >> >> OLD >> >> In a Schematron schema generated by the second mapping step, the >> basic unit of organization is a rule represented by the >> element. The following NETMOD-specific annotations from the hybrid >> schema (henceforth called "semantic annotations") are mapped to >> corresponding Schematron rules: , @nma:key, @nma:unique, >> @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: >> leaf-list, and also @nma:mandatory appearing as an attribute of > choice> (see Section 11.2.1). >> >> NEW >> >> In a Schematron schema generated by the second mapping step, the >> basic unit of organization is a rule represented by the >> element. The following NETMOD-specific annotations from the hybrid >> schema (henceforth called "semantic annotations") are mapped to >> corresponding Schematron rules: , , @nma:key, >> @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: >> leaf-list, and also @nma:mandatory appearing as an attribute of > choice> (see Section 11.2.1). >> >> Sec. 12.16 (including its title): >> ----------- >> >> OLD >> >> 12.16. The @nma:unique Annotation >> >> The mapping of this annotation is almost identical as for @nma:key, >> see Section 12.8, with two small differences: >> >> o The value of @nma:unique is a list of descendant schema node >> identifiers rather than simple leaf names. However, the XPath >> expressions specified in Section 12.8 work without any >> modifications if the descendant schema node identifiers are >> substituted for k_1, k_2, ..., k_n. >> >> o The message appearing as the text of is different: >> "Violated uniqueness for list CONTELEM". >> >> NEW >> >> 12.16. The Annotation >> >> The mapping of this annotation is similar to @nma:key, >> see Section 12.8, with two small differences: >> >> o The value of the @tag attribute of is a list of >> descendant schema node identifiers rather than simple leaf names. >> However, the XPath expressions specified in Section 12.8 work >> without any modifications if the descendant schema node >> identifiers are substituted for k_1, k_2, ..., k_n. >> >> o The message appearing as the text of is different: >> "Violated uniqueness of NODES", where NODES is the value of the >> @tag attribute. >> >> Appendix A: >> ----------- >> >> OLD >> >> >> >> >> >> >> >> >> >> >> >> NEW >> >> >> >> >> >> >> >> >> >> >> >> Thanks, Lada >> >>> Regards, Benoit. >>>> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >>>> >>>> [...] >>>>> Notes >>>>> ----- >>>>> A list's unique-stmt has a cardinality of 0..1. Therefore it >>>>> cannot be mapped into a single @nma:unique attribute. It should be >>>>> mapped into an element instead, much like the must-stmt. >>>>> Additional changes may be required throughout the document. >>>>> >>>> Would it make sense to identify the other changes that may be >>>> required? I quick search leads to: >>>> >>>> - Table 2 >>>> - 2nd paragraph of section 11.2 >>>> - section 12.16 (including its title) >>>> - definition of unique-attribute in appendix A >>>> >>>> Anything else I am missing? >>>> >>>> /js >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Thu Sep 27 07:17: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 1FFE321F852A for ; Thu, 27 Sep 2012 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I96-hNnH8os for ; Thu, 27 Sep 2012 07:17:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1974421F84F5 for ; Thu, 27 Sep 2012 07:17:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9DF7354032B; Thu, 27 Sep 2012 16:17:38 +0200 (CEST) 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 Om19QydUaxd1; Thu, 27 Sep 2012 16:17:23 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1FB855401CF; Thu, 27 Sep 2012 16:17:17 +0200 (CEST) From: Ladislav Lhotka To: Jernej Tuljak , Benoit Claise In-Reply-To: <50644795.5030202@mg-soft.com> References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <5062CFB6.3060502@cisco.com> <50642897.9060700@cisco.com> <50644795.5030202@mg-soft.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Jernej Tuljak , Benoit Claise , rbonica@juniper.net, netmod@ietf.org Date: Thu, 27 Sep 2012 16:16:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: rbonica@juniper.net, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 27 Sep 2012 14:17:46 -0000 Jernej Tuljak writes: > Dne 27.9.2012 12:21, pi=C5=A1e Benoit Claise: >> Hi Lada, >> >> Thanks for this. >> WG, any objections to the changes below? > > Table of contents is also a place where "@nma:unique" text appears, so=20 > perhaps the following is missing: > > Table of contents > ------------------- > > OLD > > 12.16. The @nma:unique Annotation ..............................74 > > NEW > > 12.16. The Annotation .............................74 > > > Not sure if this is necessary though, since "Sec. 12.16 (including its=20 > title)" might imply this change too. Well, yes and no. The table of contents is generated automatically from XML= but I assume errata are specified against the text version, so the TOC upd= ate should probably be included, too. Thanks, Lada > > The rest seems okay to me. > > Jernej > >> >> Regards, Benoit. >> >>> Benoit Claise writes: >>> >>>> Dear all, >>>> >>>> While I'm researching on the question "how far can we go with an >>>> errata", could someone please send to the list the OLD/NEW changes for >>>> the list below. That would help for the evaluation. >>> Here it is: >>> >>> Sec. 5.3, entry in Table 2: >>> --------------------------- >>> >>> OLD >>> >>> | @nma:unique | 10.55 | | >>> >>> NEW >>> >>> | | 10.55 | | >>> >>> Sec. 10.55: >>> ----------- >>> >>> OLD >>> >>> This statement is mapped to the @nma:unique attribute. ARGUMENT MUST >>> be translated so that every node identifier in each of its components >>> is prefixed with the namespace prefix of the local module, unless the >>> prefix is already present. The result of this translation then >>> becomes the value of the @nma:unique attribute. >>> >>> For example, assuming that the local module prefix is "ex", >>> >>> unique "foo ex:bar/baz" >>> >>> is mapped to the following attribute/value pair: >>> >>> nma:unique=3D"ex:foo ex:bar/ex:baz" >>> >>> NEW >>> >>> This statement is mapped to the element. ARGUMENT MUST >>> be translated so that every node identifier in each of its components >>> is prefixed with the namespace prefix of the local module, unless the >>> prefix is already present. The result of this translation then >>> becomes the value of the @tag attribute which is attached to the >>> element. >>> >>> For example, assuming that the local module prefix is "ex", >>> >>> unique "foo ex:bar/baz" >>> >>> is mapped to the following annotation element: >>> >>> >>> >>> Sec. 11.2, second paragraph: >>> ---------------------------- >>> >>> OLD >>> >>> In a Schematron schema generated by the second mapping step, the >>> basic unit of organization is a rule represented by the >>> element. The following NETMOD-specific annotations from the hybrid >>> schema (henceforth called "semantic annotations") are mapped to >>> corresponding Schematron rules: , @nma:key, @nma:unique, >>> @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: >>> leaf-list, and also @nma:mandatory appearing as an attribute of >> choice> (see Section 11.2.1). >>> >>> NEW >>> >>> In a Schematron schema generated by the second mapping step, the >>> basic unit of organization is a rule represented by the >>> element. The following NETMOD-specific annotations from the hybrid >>> schema (henceforth called "semantic annotations") are mapped to >>> corresponding Schematron rules: , , @nma:key, >>> @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma: >>> leaf-list, and also @nma:mandatory appearing as an attribute of >> choice> (see Section 11.2.1). >>> >>> Sec. 12.16 (including its title): >>> ----------- >>> >>> OLD >>> >>> 12.16. The @nma:unique Annotation >>> >>> The mapping of this annotation is almost identical as for @nma:key, >>> see Section 12.8, with two small differences: >>> >>> o The value of @nma:unique is a list of descendant schema node >>> identifiers rather than simple leaf names. However, the XPath >>> expressions specified in Section 12.8 work without any >>> modifications if the descendant schema node identifiers are >>> substituted for k_1, k_2, ..., k_n. >>> >>> o The message appearing as the text of is different: >>> "Violated uniqueness for list CONTELEM". >>> >>> NEW >>> >>> 12.16. The Annotation >>> >>> The mapping of this annotation is similar to @nma:key, >>> see Section 12.8, with two small differences: >>> >>> o The value of the @tag attribute of is a list of >>> descendant schema node identifiers rather than simple leaf names. >>> However, the XPath expressions specified in Section 12.8 work >>> without any modifications if the descendant schema node >>> identifiers are substituted for k_1, k_2, ..., k_n. >>> >>> o The message appearing as the text of is different: >>> "Violated uniqueness of NODES", where NODES is the value of the >>> @tag attribute. >>> >>> Appendix A: >>> ----------- >>> >>> OLD >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> NEW >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, Lada >>> >>>> Regards, Benoit. >>>>> On Fri, Sep 21, 2012 at 08:48:50AM -0700, RFC Errata System wrote: >>>>> >>>>> [...] >>>>>> Notes >>>>>> ----- >>>>>> A list's unique-stmt has a cardinality of 0..1. Therefore it=20 >>>>>> cannot be mapped into a single @nma:unique attribute. It should be=20 >>>>>> mapped into an element instead, much like the must-stmt.=20 >>>>>> Additional changes may be required throughout the document. >>>>>> >>>>> Would it make sense to identify the other changes that may be >>>>> required? I quick search leads to: >>>>> >>>>> - Table 2 >>>>> - 2nd paragraph of section 11.2 >>>>> - section 12.16 (including its title) >>>>> - definition of unique-attribute in appendix A >>>>> >>>>> Anything else I am missing? >>>>> >>>>> /js >>>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Sep 27 07:24:29 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 CEA0721F853B for ; Thu, 27 Sep 2012 07:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dZt0czmz1HV for ; Thu, 27 Sep 2012 07:24:29 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A22F21F8437 for ; Thu, 27 Sep 2012 07:24:29 -0700 (PDT) Received: by qcac10 with SMTP id c10so1649400qca.31 for ; Thu, 27 Sep 2012 07:24:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pWhNr+YvSQZmuexXaCvwGUh6JXwBqrtQ9N08Pgr3lKg=; b=aCjwfjLc2UE1rlfv5bHnQh64vV8xOpr9x0FVfdiL/rjbXlQuwA5mmkFlpWci1EsTMJ xZ2qVrLpY5ozymMK+FvJjP8lnHdDrNRqUXzCX6XmiV1JWz4DufT2Z01IJOQhmmxjcyLh rqGefqXjI0+2neqwfqvKxd8MN+zzWF089OFKKwTiJMeKnW5GhqQmQ5tz2rxxaFwGBVWx ZZaBFhMC4vqER2jzCj5nEQYxL8th59GJB4Hr38xXMI9g3AKsAhNkaInkaoEWsBF3sHtw SeuEvalpb0xHDukVy70vUqM+1Lf+7SFVe9zkOXbQHjra7C34ElTy0+tScFNsFTqez5zq iVbA== MIME-Version: 1.0 Received: by 10.229.135.11 with SMTP id l11mr2503213qct.116.1348755868508; Thu, 27 Sep 2012 07:24:28 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Thu, 27 Sep 2012 07:24:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Sep 2012 07:24:28 -0700 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmpPo4SEFL3AyXNpoD7Es86wIMeZp/kDdO9JHZubx+HUK8mXXUTdPQC3FrQIKE/zBnqj9ip Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 27 Sep 2012 14:24:29 -0000 Hi, I would be strongly opposed to replacement of the standard editing mechanisms with data-model specific operations. I do not see anything special about the ACE lists such that 'ordered-by user' would not work. Andy On Wed, Sep 26, 2012 at 10:34 PM, Muthumayan Madhayyan (muthu) wrote: > One other useful RPC for this ACL module would be a mechanism to re-sequence > ACE sequence numbers. > > Something like: > > rpc resequence-acl { > description "This RPC is to re-number sequence numbers of ACE > entries > > in an ACL. The first ACE entry would use the 'start' number and > subsequent > > ACE entries would be assigned increasing sequence numbers > 'interval' apart. "; > > input { > leaf acl-name { > type string; > mandatory true; > description "This name is the acl name."; > } > leaf start { > type Sequence-Number; > description > "Starting sequence-num for the first ACE in an ACL."; > > } > > leaf interval { > > type uint32; > description > "Gap between sequence number assigned to consecutive > ACE entries"; > > } > > } > } > > > Thanks, > > - muthu > > > > From: "Alexander Clemm (alex)" > Date: Friday, August 31, 2012 4:03 PM > To: "netmod@ietf.org" > Subject: [netmod] YANG module for ACL configuration > > Dear All, > > > > we have just posted an Internet Draft of a YANG model for ACL configuration: > > http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt > > > > This document defines a YANG data model for Access Control Lists (ACLs) on a > device. An ACL is an ordered set of rules that is used to filter traffic on > a networking device. In the draft you will find details of how the model is > designed and the corresponding YANG modules. > > > > We are hoping that this model is of interest to this group. Please take a > look and let us know your thoughts and comments. > > > > Thanks, > > > > Alex & Lisa > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Thu Sep 27 08:42: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 E523621F8595 for ; Thu, 27 Sep 2012 08:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVuhuqvVW6Kg for ; Thu, 27 Sep 2012 08:42:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84121F855D for ; Thu, 27 Sep 2012 08:42:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4EE5254032B for ; Thu, 27 Sep 2012 17:42:11 +0200 (CEST) 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 Nmsy+B7dm9Wb for ; Thu, 27 Sep 2012 17:42:02 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 51C20540049 for ; Thu, 27 Sep 2012 17:41:58 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120927.091656.1385318774262851643.mbj@tail-f.com> References: <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> <20120927.091656.1385318774262851643.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 27 Sep 2012 17:41:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interface keying - call for preferences 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, 27 Sep 2012 15:42:17 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >> > >> > My concern with this approach is that you most probably get >> > information overlap. In order to configure an interface, you'll >> > need to do: >> > >> > name: acme >> > type: ethernetCsmacd >> > local-name: eth1 >> >> It is not always so. The Ethernet interface on my Mac carries the name >> "en0" and FreeBSD uses names like "em0" or "bge1". > > But these are the names of the drivers, for the specific types. Right, so in this case type and location is not sufficient for determining the local name. > >> Even on Linux we >> can have this: >> >> name: acme >> type: ethernetCsmacd >> local-name: foo > > We *can*, but it depends on the implementation. > >> > With the current proposal, there is overlap only if the device imposes >> > the name restrictions: >> > >> > name: fastethernet-1/0 >> > type: ethernetCsmacd >> > location: 1/0 >> > >> > If the device does not impose any restrictions, you can do: >> > >> > name: acme >> > type: ethernetCsmacd >> > location: 1/0 >> >> On devices that do not use the concept of location consistently this >> means that the configuration contains no reliable info about the local >> interface name. > > This is why a config false leaf 'local-name' would be useful. It depends. If we agree that the client should be able to assign an arbitrary key to an interface entry, then there has to be a way for linking the configuration that is in the "foobar" entry of the "interface" list to a particular physical interface. You propose to use "type" and "location" for this purpose, and then "local-name" can be config false. In contrast, I propose that "local-name" be used as the link, so it has to be config true, but type and location can now be config false. > >> We have to distinguish between two cases: >> >> 1. Local name of an interface can be changed to an arbitrary string at >> the system level. >> >> 2. The "name" key of the "interface" list is arbitrary. >> >> My point is that 2 should hold for any implementation of the >> interfaces module, independently of 1. >> >> The actual local name always has to be filled in the local-name leaf, >> no matter what the local name is - this realizes the link between >> NETCONF interface configuration and a physical interface. And the link >> can be easily updated in one place if the local name changes. > > This means that the user somehow must figure out the kernel-assigned > name for say the 4th ethernet port on the device. With a location > leaf, you move this task to the implementation (*), and let the user > just specify the location "4". This design at least makes it possible > to do a user-friendly product... OK, I see your point. It works fine on platforms with well-defined hardware organization but less so on messy platforms such as the generic PC. The advantage of "local-name" is that it exists on all platforms, whilst "location" is not universal. Lada > > (*) it would still be up to each implementation. An implementation > that wants to use the kernel-assigned name as hw-reference can still > do that. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Sep 27 09:04: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 5FCE421F855A for ; Thu, 27 Sep 2012 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsOtCt2zCGzn for ; Thu, 27 Sep 2012 09:04:35 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3705121F85B1 for ; Thu, 27 Sep 2012 09:04:34 -0700 (PDT) Received: by qabj40 with SMTP id j40so2266368qab.10 for ; Thu, 27 Sep 2012 09:04:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=c0lPZTL4G44xmPX+Dzl5quNVAjBoH7qehEeJtMxUwJs=; b=THfKTtPp4geivTaZ7yrSJy/WlI4hi4YrXglXDx6xMGCNWXmSfanXHTwwHZhOxn4G9Q 4QKeltVbJ2CDhZXOc65cxH1k/aoNo78Em326oWXIo0JKRFvHyP1LJxgsnVHpBhrezHmQ Xvrzsq0vCD0nn2msav+75d65yK7a55Vjlhjs2DT1DDbZqsL7oOu77yChvrr0ovrJSPbX OR6hoCcJG1LmJc9uaCOA6iRcg3D3pEwYrY3jQttWJlOe6pSsZqZcDdyXDOuSRpMP7gc0 0XHw8+wSvi8o5PDAly367E+MHJFxugLQGv4ICJQdZPwYHYRj+YmeeqWkoYosJNgsQg3x ZIJg== MIME-Version: 1.0 Received: by 10.229.137.6 with SMTP id u6mr2783973qct.24.1348761874228; Thu, 27 Sep 2012 09:04:34 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Thu, 27 Sep 2012 09:04:34 -0700 (PDT) In-Reply-To: <20120927.091656.1385318774262851643.mbj@tail-f.com> References: <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> <20120927.091656.1385318774262851643.mbj@tail-f.com> Date: Thu, 27 Sep 2012 09:04:34 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkW2moj882bIl/sflDV5NsIin7V5Sdy5L3kH9Z3kw35h8Xn4xHlv6IO104OPHoKkwlAaufl Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 27 Sep 2012 16:04:36 -0000 On Thu, Sep 27, 2012 at 12:16 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >> > >> > My concern with this approach is that you most probably get >> > information overlap. In order to configure an interface, you'll >> > need to do: >> > >> > name: acme >> > type: ethernetCsmacd >> > local-name: eth1 >> >> It is not always so. The Ethernet interface on my Mac carries the name >> "en0" and FreeBSD uses names like "em0" or "bge1". > > But these are the names of the drivers, for the specific types. > >> Even on Linux we >> can have this: >> >> name: acme >> type: ethernetCsmacd >> local-name: foo > > We *can*, but it depends on the implementation. > >> > With the current proposal, there is overlap only if the device imposes >> > the name restrictions: >> > >> > name: fastethernet-1/0 >> > type: ethernetCsmacd >> > location: 1/0 >> > >> > If the device does not impose any restrictions, you can do: >> > >> > name: acme >> > type: ethernetCsmacd >> > location: 1/0 >> >> On devices that do not use the concept of location consistently this >> means that the configuration contains no reliable info about the local >> interface name. > > This is why a config false leaf 'local-name' would be useful. > >> We have to distinguish between two cases: >> >> 1. Local name of an interface can be changed to an arbitrary string at >> the system level. >> >> 2. The "name" key of the "interface" list is arbitrary. >> >> My point is that 2 should hold for any implementation of the >> interfaces module, independently of 1. >> >> The actual local name always has to be filled in the local-name leaf, >> no matter what the local name is - this realizes the link between >> NETCONF interface configuration and a physical interface. And the link >> can be easily updated in one place if the local name changes. > > This means that the user somehow must figure out the kernel-assigned > name for say the 4th ethernet port on the device. We could easily define a data-model specific operation like so the client would not have to guess this kernel-assigned name. We do not need any new naming layers, and we cannot change the vendor-specific nature of interface naming. The current draft is good enough, and hopefully the problem of standardized interface naming can be solved later. I want the physical interfaces to have the system-assigned name as the key. I think kernel upgrade induced interface renumbering is too rare to change the simple design we have now. > With a location > leaf, you move this task to the implementation (*), and let the user > just specify the location "4". This design at least makes it possible > to do a user-friendly product... > > (*) it would still be up to each implementation. An implementation > that wants to use the kernel-assigned name as hw-reference can still > do that. > > > /martin Andy From jeffrey.K.lange@ge.com Thu Sep 27 09:29:47 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 DE1BA21F84D2 for ; Thu, 27 Sep 2012 09:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTmgfxnraFzm for ; Thu, 27 Sep 2012 09:29:47 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id D5A8D21F847A for ; Thu, 27 Sep 2012 09:29:46 -0700 (PDT) Received: from cinmlip11.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKUGR++rOfQAkMyGl+/ZyJEcBptNWmnXDb@postini.com; Thu, 27 Sep 2012 09:29:46 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip11.e2k.ad.ge.com with ESMTP; 27 Sep 2012 12:29:34 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Sep 2012 12:29:33 -0400 Received: from CINMBAPD03.e2k.ad.ge.com (3.159.212.69) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 27 Sep 2012 12:29:26 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.112]) by CINMBAPD03.e2k.ad.ge.com ([169.254.9.24]) with mapi id 14.02.0309.002; Thu, 27 Sep 2012 12:29:26 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] interface keying - call for preferences Thread-Index: AQHNmCYls0dy9avszUuB+Skgcj5YCZeZeqSAgAAPo4CAAATlAIAABVIAgAAb5oCAAT9PAIAAgzkAgAD+qwCAAAlWgIABiIKAgAAPeQCAAJNsAP//wHLw Date: Thu, 27 Sep 2012 16:29:26 +0000 Message-ID: References: <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> <20120927.091656.1385318774262851643.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2012 16:29:33.0633 (UTC) FILETIME=[46F56B10:01CD9CCD] Cc: "netmod@ietf.org" Subject: Re: [netmod] interface keying - call for preferences 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, 27 Sep 2012 16:29:48 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Andy Bierman > Sent: Thursday, September 27, 2012 12:05 PM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] interface keying - call for preferences >=20 > On Thu, Sep 27, 2012 at 12:16 AM, Martin Bjorklund wrote= : > > Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >> > > >> > My concern with this approach is that you most probably get > >> > information overlap. In order to configure an interface, you'll > >> > need to do: > >> > > >> > name: acme > >> > type: ethernetCsmacd > >> > local-name: eth1 > >> > >> It is not always so. The Ethernet interface on my Mac carries the > >> name "en0" and FreeBSD uses names like "em0" or "bge1". > > > > But these are the names of the drivers, for the specific types. > > > >> Even on Linux we > >> can have this: > >> > >> name: acme > >> type: ethernetCsmacd > >> local-name: foo > > > > We *can*, but it depends on the implementation. > > > >> > With the current proposal, there is overlap only if the device > >> > imposes the name restrictions: > >> > > >> > name: fastethernet-1/0 > >> > type: ethernetCsmacd > >> > location: 1/0 > >> > > >> > If the device does not impose any restrictions, you can do: > >> > > >> > name: acme > >> > type: ethernetCsmacd > >> > location: 1/0 > >> > >> On devices that do not use the concept of location consistently this > >> means that the configuration contains no reliable info about the > >> local interface name. > > > > This is why a config false leaf 'local-name' would be useful. > > > >> We have to distinguish between two cases: > >> > >> 1. Local name of an interface can be changed to an arbitrary string > >> at the system level. > >> > >> 2. The "name" key of the "interface" list is arbitrary. > >> > >> My point is that 2 should hold for any implementation of the > >> interfaces module, independently of 1. > >> > >> The actual local name always has to be filled in the local-name leaf, > >> no matter what the local name is - this realizes the link between > >> NETCONF interface configuration and a physical interface. And the > >> link can be easily updated in one place if the local name changes. > > > > This means that the user somehow must figure out the kernel-assigned > > name for say the 4th ethernet port on the device. >=20 > We could easily define a data-model specific operation like > so the client would not have to guess this kernel-assigned name. >=20 > We do not need any new naming layers, and we cannot change the vendor- > specific nature of interface naming. > The current draft is good enough, and hopefully the problem of standardiz= ed > interface naming can be solved later. >=20 > I want the physical interfaces to have the system-assigned name as the ke= y. I > think kernel upgrade induced interface renumbering is too rare to change = the > simple design we have now. >=20 This makes for a very un-user-friendly interface. On our products, the ext= ernal Ethernet ports are silk-screened as "LAN1" and "LAN2". However, unde= r the hood they are eth0 and eth1. Requiring the user to configure /interf= aces/interface{eth0} is not very obvious (or even worse /interfaces/interfa= ce{ppp0} for the case of a 3G cellular radio). In my opinion, a much clean= er approach would be to have it as /interfaces/interface{lan1} or interface= {cellular} and have the location / local-name (or whatever you want to call= it) contain the value "eth0". Whether this is config true or false doesn'= t matter much to us as these devices will be pre-populated at factory build= time, and no user will be able to delete/change them (other than IP etc...= ). We also need to support user-created virtual interfaces such as bridged dev= ices in this case, the user would create a new interface{my_bridge}. The u= ser shouldn't care what the underlying device name for this is, which is wh= ere a config-false location/local-name would be useful. I do agree that we shouldn't need to focus any attention on the kernel auto= renaming devices on boot.. if you have a system that does this you have mo= re general configuration issues you need to deal with at a system level! -Jeff >=20 >=20 > > With a location > > leaf, you move this task to the implementation (*), and let the user > > just specify the location "4". This design at least makes it possible > > to do a user-friendly product... > > > > (*) it would still be up to each implementation. An implementation > > that wants to use the kernel-assigned name as hw-reference can still > > do that. > > > > > > /martin >=20 >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From muthu@cisco.com Thu Sep 27 10:58: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 46E6121F84CE for ; Thu, 27 Sep 2012 10:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNg9TKUN7FXM for ; Thu, 27 Sep 2012 10:58:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A26DF21F849C for ; Thu, 27 Sep 2012 10:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3084; q=dns/txt; s=iport; t=1348768696; x=1349978296; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VJ1ovEjDcokdpHTRVmYv4lPZjwelhF/bOaQU+Den+vY=; b=R5tP3cc1CfnV4NJP7mkO64juh0ph2j8yWT6TIoVFlzyEsChsbmOGPFJw SQJtER7JJbQmY4XeBgMPzVnTh3qT+8vsEEfgX4auEsLVpBte126uxbwbU ugYJFin6P5RxuRAEv2TIgLYrQzWW+gjMsiIleqK0086tSZa7pZK8V7gWS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABWTZFCtJV2b/2dsb2JhbABFvgiBCIIgAQEBBBIBJz8SAQgOAwMBAgEeCTkUCQgBAQQOBQkZh2MLmHagCIsYhh0DlWmOQoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="126056774" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 27 Sep 2012 17:58:16 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8RHwGZK005061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 17:58:16 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.58]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Thu, 27 Sep 2012 12:58:15 -0500 From: "Muthumayan Madhayyan (muthu)" To: Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwUlCAGAABGvRYAACE2BgA== Date: Thu, 27 Sep 2012 17:58:14 +0000 Message-ID: In-Reply-To: <20120927.090027.1105304236918687664.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.83.162] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--50.049100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 27 Sep 2012 17:58:17 -0000 On 9/27/12 12:00 AM, "Martin Bjorklund" wrote: >"Muthumayan Madhayyan (muthu)" wrote: >> One other useful RPC for this ACL module would be a mechanism to >> re-sequence ACE sequence numbers. > >This is the reason why YANG has ordered-by user lists. With an >ordered-by user list you avoid the renumbering problem, and give the >user the ability to move entires without renaming/renumbering them. Sure.. That will work if the key for the ACE list is a string. In this case, the key is an integer. Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5. Now, we want to add an entry between 3 and 4. How can we use ordered-by-user in this situation ? > >Note that *if* such an RPC operation is introduced, it at least need >to take the configuration datastore as argument (candidate, running). Agree. > > >/martin > > > > > >>=20 >> Something like: >>=20 >>=20 >> rpc resequence-acl { >> description "This RPC is to re-number sequence numbers of ACE >>entries >>=20 >> in an ACL. The first ACE entry would use the 'start' number and >> subsequent >>=20 >> ACE entries would be assigned increasing sequence numbers >>'interval' >> apart. "; >>=20 >> input { >> leaf acl-name { >> type string; >> mandatory true; >> description "This name is the acl name."; >> } >> leaf start { >> type Sequence-Number; >> description >> "Starting sequence-num for the first ACE in an >>ACL."; >>=20 >> } >>=20 >> leaf interval { >>=20 >> type uint32; >> description >> "Gap between sequence number assigned to >>consecutive ACE >> entries"; >>=20 >> } >>=20 >> } } >>=20 >> Thanks, >>=20 >> - muthu >>=20 >>=20 >> From: "Alexander Clemm (alex)" > >> Date: Friday, August 31, 2012 4:03 PM >> To: "netmod@ietf.org" >> > >> Subject: [netmod] YANG module for ACL configuration >>=20 >>=20 >> Dear All, >>=20 >>=20 >>=20 >> we have just posted an Internet Draft of a YANG model for ACL >> configuration: >>=20 >> http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt >>=20 >>=20 >>=20 >> This document defines a YANG data model for Access Control Lists >> (ACLs) on a device. An ACL is an ordered set of rules that is used to >> filter traffic on a networking device. In the draft you will find >> details of how the model is designed and the corresponding YANG >> modules. >>=20 >>=20 >>=20 >> We are hoping that this model is of interest to this group. Please >> take a look and let us know your thoughts and comments. >>=20 >>=20 >>=20 >> Thanks, >>=20 >>=20 >>=20 >> Alex & Lisa >>=20 >>=20 >>=20 From mbj@tail-f.com Thu Sep 27 11:02: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 2E39821F8665 for ; Thu, 27 Sep 2012 11:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDYlECDVZCjo for ; Thu, 27 Sep 2012 11:02:14 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7483921F8658 for ; Thu, 27 Sep 2012 11:02:12 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DEB0A1200D5F; Thu, 27 Sep 2012 20:02:06 +0200 (CEST) Date: Thu, 27 Sep 2012 20:02:06 +0200 (CEST) Message-Id: <20120927.200206.508251790.mbj@tail-f.com> To: muthu@cisco.com From: Martin Bjorklund In-Reply-To: References: <20120927.090027.1105304236918687664.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] YANG module for ACL configuration 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, 27 Sep 2012 18:02:16 -0000 "Muthumayan Madhayyan (muthu)" wrote: > > > On 9/27/12 12:00 AM, "Martin Bjorklund" wrote: > > >"Muthumayan Madhayyan (muthu)" wrote: > >> One other useful RPC for this ACL module would be a mechanism to > >> re-sequence ACE sequence numbers. > > > >This is the reason why YANG has ordered-by user lists. With an > >ordered-by user list you avoid the renumbering problem, and give the > >user the ability to move entires without renaming/renumbering them. > > Sure.. That will work if the key for the ACE list is a string. In this > case, the key is an integer. > Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5. > Now, we want to add an entry between 3 and 4. > How can we use ordered-by-user in this situation ? Technically it works just fine. The keys don't mean anything - the order of an ordered-by user is the order the user defines. But it would be pretty confusing, so I agree that it is probably better to use a name as key. /martin From andy@yumaworks.com Thu Sep 27 11:21: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 427BC21F866B for ; Thu, 27 Sep 2012 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VbmbHEtrmdw for ; Thu, 27 Sep 2012 11:21:55 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDF121F8669 for ; Thu, 27 Sep 2012 11:21:50 -0700 (PDT) Received: by qcac10 with SMTP id c10so34634qca.31 for ; Thu, 27 Sep 2012 11:21:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0GvhiscQLtTdCz6rJkfz0P5pJO/crcRc4pRn0yM05rk=; b=KG9k944CjEzQ2x69B+PjaT+97anXw9xl1ngGPGKaMLk9vo8PUddOJRkWycI+n7LupH I7a0jdQTq9jdNHYnaeqHsvYVkSzIm/myOiI4JUEQuwakHutUB3TN2cgyXkjWukMTIY9x mny1rV9XOdSDyxkUs9yY/x7O44yWjHcbXZ9eOadeDMHyBAwkkHC3oppStwR5qD/Rx/i3 eQkL0tLadT5JrWdizOE1ar+Wl5WK9m8EAiDkED/Otqo1398OR7LI4FkExRVBMam3XnsR 5nadmZzqz6ikvuzrMwSoXje3mU8hpVZtp+oIb1V4fG92hdMXW5D6pd39gq6rS43BPSxW 9X7g== MIME-Version: 1.0 Received: by 10.224.193.69 with SMTP id dt5mr11487995qab.2.1348770108925; Thu, 27 Sep 2012 11:21:48 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Thu, 27 Sep 2012 11:21:48 -0700 (PDT) In-Reply-To: <20120927.200206.508251790.mbj@tail-f.com> References: <20120927.090027.1105304236918687664.mbj@tail-f.com> <20120927.200206.508251790.mbj@tail-f.com> Date: Thu, 27 Sep 2012 11:21:48 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=20cf3005150639e57b04cab303bc X-Gm-Message-State: ALoCoQlm/PU62qVm/orK/Sj9IdBxLcrFR5t+MaLyFbzZY8rYLZGXPuTpJBp6SG/B+OXUx7oyOPof Cc: netmod@ietf.org Subject: Re: [netmod] YANG module for ACL configuration 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, 27 Sep 2012 18:21:56 -0000 --20cf3005150639e57b04cab303bc Content-Type: text/plain; charset=UTF-8 On Thu, Sep 27, 2012 at 11:02 AM, Martin Bjorklund wrote: > "Muthumayan Madhayyan (muthu)" wrote: > > > > > > On 9/27/12 12:00 AM, "Martin Bjorklund" wrote: > > > > >"Muthumayan Madhayyan (muthu)" wrote: > > >> One other useful RPC for this ACL module would be a mechanism to > > >> re-sequence ACE sequence numbers. > > > > > >This is the reason why YANG has ordered-by user lists. With an > > >ordered-by user list you avoid the renumbering problem, and give the > > >user the ability to move entires without renaming/renumbering them. > > > > Sure.. That will work if the key for the ACE list is a string. In this > > case, the key is an integer. > > Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5. > > Now, we want to add an entry between 3 and 4. > > How can we use ordered-by-user in this situation ? > > Technically it works just fine. The keys don't mean anything - the > order of an ordered-by user is the order the user defines. But it > would be pretty confusing, so I agree that it is probably better to > use a name as key. > > Yes -- the key is just a unique identifier. It should not be an integer. The YANG insert operation determines the creation order, if it is not the default (last). > /martin > Andy --20cf3005150639e57b04cab303bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 27, 2012 at 11:02 AM, Martin= Bjorklund <mbj@tail-f.com> wrote:
"Muthumayan Madhayyan (muthu)" <muthu@cisco.com> wrote:
>
>
> On 9/27/12 12:00 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:
>
> >"Muthumayan Madhayyan (muthu)" <muthu@cisco.com> wrote:
> >> One other useful RPC for this ACL module would be a mechanism= to
> >> re-sequence ACE sequence numbers.
> >
> >This is the reason why YANG has ordered-by user lists. =C2=A0With = an
> >ordered-by user list you avoid the renumbering problem, and give t= he
> >user the ability to move entires without renaming/renumbering them= .
>
> Sure.. That will work if the key for the ACE list is a string. In this=
> case, the key is an integer.
> Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5.=
> Now, we want to add an entry between 3 and 4.
> How can we use ordered-by-user in this situation ?

Technically it works just fine. =C2=A0The keys don't mean anything - th= e
order of an ordered-by user is the order the user defines. =C2=A0But it
would be pretty confusing, so I agree that it is probably better to
use a name as key.


Yes -- the key is just a unique identifier.=C2=A0= It should
not be an integer.

The YANG insert operation determine= s the creation order,
if it is not the default (last).



/martin

Andy

--20cf3005150639e57b04cab303bc-- From j.schoenwaelder@jacobs-university.de Fri Sep 28 06:21:23 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 AA20621F84E4 for ; Fri, 28 Sep 2012 06:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+l9Qy7qUyQc for ; Fri, 28 Sep 2012 06:21:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF3721F84DF for ; Fri, 28 Sep 2012 06:21:18 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8E3D20BF1; Fri, 28 Sep 2012 15:21:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZFpKDmfajzDu; Fri, 28 Sep 2012 15:21:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD43B20BEA; Fri, 28 Sep 2012 15:21:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F9BF2209C71; Fri, 28 Sep 2012 15:21:08 +0200 (CEST) Date: Fri, 28 Sep 2012 15:21:08 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120928132108.GA63331@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20120925072208.GB52571@elstar.local> <20120925.171148.493408222.mbj@tail-f.com> <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120926.085643.852255271947498935.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interface keying - call for preferences 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, 28 Sep 2012 13:21:24 -0000 On Wed, Sep 26, 2012 at 08:56:43AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Sep 25, 2012 at 05:11:48PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > > and make it clear that the name leaf really carries an > > > > administratively assigned name. > > > > > > Hmm, does "administratively assigned name" imply "arbitrary"? If not, > > > what exactly does "administratively assigned" mean? > > > > Yes, it means an administrator assigns a name that he/she finds > > suitable, not necessarily a name the underlying system dictates. > > So going back to your original poll in this thread, it seems you > prefer alternative (b), right? I see value in enabling the separation. And I see value in figuring out how to implement stuff on generic boxes where the notion of an interface location does not exist (e.g., what would be the location of a wireless stick plugged via a hub into a usb port?). The OSes I am most familiar of assign names (more or less dynamically) and it might be sensible to use that OS name of an interface as its 'location' identifier. Sure, if you build a well controlled product, you can rename stuff such that interfaces carry meaningful location information. > > > > The concept of a location is not > > > > really well developed anyway > > > > > > I still think that you always can pick something relevant to use as a > > > location. It seems most router vendors have been able to do this for > > > some time now... > > > > > > I don't think we can find something more precise, that will be useful > > > across vendors / OSes. > > > > Some router vendors encode module/port numbers in interface names, but > > the result is really an encoding of location information into a name > > not just location information. The current text does not seem to imply > > that en5 or eth5 would be suitable 'location' values. > > I think the current text allows this. It says: > > The device-specific location of the interface of a > particular type. The format of the location string > depends on the interface type and the device. > > Doesn't that imply that a device can pick any format it likes? Perhaps this was intended to be included, but in that case I would prefer to make that explicit. What about being explicit and adding something to the following paragraph? "Yes another example, if a device natively identifies interfaces via devices names, the location can be of the form 'en1' or 'eth2'. > > I believe what > > we really store in the leaf is the system's local name of an > > interface, which might or might not include location information. > > My concern with this approach is that you most probably get > information overlap. In order to configure an interface, you'll > need to do: > > name: acme > type: ethernetCsmacd > local-name: eth1 No overlap I can spot here. > With the current proposal, there is overlap only if the device imposes > the name restrictions: > > name: fastethernet-1/0 > type: ethernetCsmacd > location: 1/0 > > If the device does not impose any restrictions, you can do: > > name: acme > type: ethernetCsmacd > location: 1/0 What matters is that I can correlate information I receive from different management interfaces. If syslog tells me "device eth1 entered promiscuous mode", I love to find eth1 somewhere in the config. If I have to ping a link-local address from the router, I love to be able to look into the config to lear that I can write ping6 fe80::2e0:fe47:81ff:c935%eth1. I think you assume the system level name is the name stored in interface/name. But then that leaf's description starts with "An arbitrary name for the interface." This, of course, makes moving the config from one system level interface to another somewhat complicated. This is where Lada started. I am meanwhile more concerned that we leave it open where the OS level interface name shows up and I am worried that if implementations do this very differently, management applications will have to maintain several variations of code to configure interfaces and they will have to dynamically discover what works. I think that is bad. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Fri Sep 28 08:23:48 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 2B6BC21F85A2 for ; Fri, 28 Sep 2012 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbne+StXbmnK for ; Fri, 28 Sep 2012 08:23:47 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7A21F859A for ; Fri, 28 Sep 2012 08:23:47 -0700 (PDT) Received: by qadb10 with SMTP id b10so1720809qad.10 for ; Fri, 28 Sep 2012 08:23:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=e6MHFYHgl3EdSSWzdhMnH8Awd/GuHBqJZlFCmuuwEaM=; b=KQnhWsvezRUp5soxpYr7Ko0+xjwhE/U77fk8aciJcvSp53YSKynDt+5Avgf622cnLs 8GjdIIAYwROP6FREsUMM8rgqpDxxZvGFDePCaW3zYIHL4Vzb1XTzB1T14juPnQhEgzNy B+VTz+nZMdPncTUfA7BBzL18pIAVKPqJyUDpKuU/dLHt8fTVXNTDbYDPrF7LcUhUv+q5 rztqMziEmue01UQDKCVkOUIenY9Tm4JOa6ia9DMkplmj6KENOe4A2s7hGLFjGAe65u8y GSi2evNlwCITxheSh2Z5f+JUXi+SY4NZT/hVqOhw+rReGfAn3L+wjf9OC8SA1A34JAdB Ovqg== MIME-Version: 1.0 Received: by 10.224.76.204 with SMTP id d12mr6173889qak.85.1348845826772; Fri, 28 Sep 2012 08:23:46 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Fri, 28 Sep 2012 08:23:46 -0700 (PDT) In-Reply-To: References: <20120926062318.GB58005@elstar.local> <20120926.085643.852255271947498935.mbj@tail-f.com> <20120927.091656.1385318774262851643.mbj@tail-f.com> Date: Fri, 28 Sep 2012 08:23:46 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: multipart/alternative; boundary=20cf3074b5dc5c8fa104cac4a453 X-Gm-Message-State: ALoCoQluEcWyYAzRPe+8Ve97Cv4jmxWWSVSKzl5ER+RJXRO1lMzynINO7W4JTCzp4mlCo+S2te6h Cc: "netmod@ietf.org" Subject: Re: [netmod] interface keying - call for preferences 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, 28 Sep 2012 15:23:48 -0000 --20cf3074b5dc5c8fa104cac4a453 Content-Type: text/plain; charset=UTF-8 .... > > I want the physical interfaces to have the system-assigned name as the > key. I > > think kernel upgrade induced interface renumbering is too rare to change > the > > simple design we have now. > > > > This makes for a very un-user-friendly interface. On our products, the > external Ethernet ports are silk-screened as "LAN1" and "LAN2". However, > under the hood they are eth0 and eth1. Requiring the user to configure > /interfaces/interface{eth0} is not very obvious (or even worse > /interfaces/interface{ppp0} for the case of a 3G cellular radio). In my > opinion, a much cleaner approach would be to have it as > /interfaces/interface{lan1} or interface{cellular} and have the location / > local-name (or whatever you want to call it) contain the value "eth0". > Whether this is config true or false doesn't matter much to us as these > devices will be pre-populated at factory build time, and no user will be > able to delete/change them (other than IP etc...). > > It is your implementation choice to label something LAN1 and call it eth0 in CLI/NETCONF/SYSLOG output. I guess I meant "system selected name", not literally the "kernel selected name". If the system will only accept LAN1 or LAN2 as the name leaf values, then the system should present all info using those names. > We also need to support user-created virtual interfaces such as bridged > devices in this case, the user would create a new interface{my_bridge}. > The user shouldn't care what the underlying device name for this is, which > is where a config-false location/local-name would be useful. > > So don't restrict the name values that are accepted. That is the issue here. BTW, I said PHY interfaces, not virtual interfaces. I don't have any objections to a config=false local-name. I'm not sure each implementer would know what to put there. I do agree that we shouldn't need to focus any attention on the kernel auto > renaming devices on boot.. if you have a system that does this you have > more general configuration issues you need to deal with at a system level! > > -Jeff > > Andy --20cf3074b5dc5c8fa104cac4a453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ....
> I want the physical interfaces to have the system-assigned name as the= key. =C2=A0I
> think kernel upgrade induced interface renumbering is too rare to chan= ge the
> simple design we have now.
>

This makes for a very un-user-friendly interface. =C2=A0On our products, th= e external Ethernet ports are silk-screened as "LAN1" and "L= AN2". =C2=A0However, under the hood they are eth0 and eth1. =C2=A0Requ= iring the user to configure /interfaces/interface{eth0} is not very obvious= (or even worse /interfaces/interface{ppp0} for the case of a 3G cellular r= adio). =C2=A0In my opinion, a much cleaner approach would be to have it as = /interfaces/interface{lan1} or interface{cellular} and have the location / = local-name (or whatever you want to call it) contain the value "eth0&q= uot;. =C2=A0Whether this is config true or false doesn't matter much to= us as these devices will be pre-populated at factory build time, and no us= er will be able to delete/change them (other than IP etc...).



It is your implementation choice to label som= ething LAN1
and call it eth0 in CLI/NETCONF/SYSLOG output.

I gues= s I meant "system selected name", not literally
the "kern= el selected name".=C2=A0 If the system will only accept
LAN1 or LAN2 as the name leaf values, then the system should
present all= info using those names.
=C2=A0
We also need to support user-created virtual interfaces such as bridged dev= ices in this case, the user would create a new interface{my_bridge}. =C2=A0= The user shouldn't care what the underlying device name for this is, wh= ich is where a config-false location/local-name would be useful.


So don't restrict the name values that are ac= cepted.
That is the issue here.=C2=A0 BTW, I said PHY interfaces,
not= virtual interfaces.

I don't have any objections to a config=3Df= alse local-name.
I'm not sure each implementer would know what to put there.


=
I do agree that we shouldn't need to focus any attention on the kernel = auto renaming devices on boot.. if you have a system that does this you hav= e more general configuration issues you need to deal with at a system level= !

-Jeff




Andy

--20cf3074b5dc5c8fa104cac4a453-- From muthu@cisco.com Fri Sep 28 14:01: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 6474B21F8606 for ; Fri, 28 Sep 2012 14:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcQbTTdD-9AR for ; Fri, 28 Sep 2012 14:01:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 73CFF21F85DA for ; Fri, 28 Sep 2012 14:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1589; q=dns/txt; s=iport; t=1348866109; x=1350075709; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5zvLlK5qx1KgCXkyD3vfj6FP/l8oEzxQyK+Mkt1ReF4=; b=CiWBDhsmyYoLg5ft9xY2KboY7Y8dRHcnXbiBzB2uPTNKUieH+4fXScwC l6AOMZMv/lZ2/+wYLsdZOVhoIgD3QkEUh+2RsdagZ/mpg9VO+8SmD12l2 vS78b1m8z63w47tToiHs+YdeiXZiwNGDyOnNMdlYSVckpxDI2Eikp1VeW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGAPZlCtJXG//2dsb2JhbABFviGBCIIgAQEBBBIBJz8SAQgOCh5CJQEBBA4FIodjmDmgLpE/A5I4gzGOQoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,504,1344211200"; d="scan'208";a="126520360" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 28 Sep 2012 21:01:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8SL1mpE030940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 21:01:48 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.58]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 16:01:48 -0500 From: "Muthumayan Madhayyan (muthu)" To: Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwUlCAGAABGvRYAACE2BgAAOzhwAACnltYA= Date: Fri, 28 Sep 2012 21:01:47 +0000 Message-ID: In-Reply-To: <20120927.200206.508251790.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.64.150] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--38.817400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5D7A0C3C1E6B564DB72F8409AB875525@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 28 Sep 2012 21:01:50 -0000 Yes, we can avoid the need for a re-sequencing RPC, if the ACE list is made ordered-by-user in which case the key should be a name (i.e. A string) instead of an integer (sequence-number). The sequence number is a CLI construct that imposes implicit ordering. But then, if an agent is to support both CLI and Netconf, then we have to resort to a common denominator and that happens to be the sequence number. - muthu On 9/27/12 11:02 AM, "Martin Bjorklund" wrote: >"Muthumayan Madhayyan (muthu)" wrote: >>=20 >>=20 >> On 9/27/12 12:00 AM, "Martin Bjorklund" wrote: >>=20 >> >"Muthumayan Madhayyan (muthu)" wrote: >> >> One other useful RPC for this ACL module would be a mechanism to >> >> re-sequence ACE sequence numbers. >> > >> >This is the reason why YANG has ordered-by user lists. With an >> >ordered-by user list you avoid the renumbering problem, and give the >> >user the ability to move entires without renaming/renumbering them. >>=20 >> Sure.. That will work if the key for the ACE list is a string. In this >> case, the key is an integer. >> Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5. >> Now, we want to add an entry between 3 and 4. >> How can we use ordered-by-user in this situation ? > >Technically it works just fine. The keys don't mean anything - the >order of an ordered-by user is the order the user defines. But it >would be pretty confusing, so I agree that it is probably better to >use a name as key. > > >/martin From yihuan@cisco.com Fri Sep 28 14:15: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 DD74621F84F6 for ; Fri, 28 Sep 2012 14:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzEQtvwh5s8T for ; Fri, 28 Sep 2012 14:15:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BA8D221F84F2 for ; Fri, 28 Sep 2012 14:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15432; q=dns/txt; s=iport; t=1348866902; x=1350076502; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=QlY7r1ErXdc2LO0rjMIdnIAOm3h7c1JiA5zWLeRL3Ik=; b=mLwDiqkbehsrPykaJlqhdzi7TTM//IDGpBdueVrNeOLoKCMr537R64Wy v8rQvgxmMOD52G4llQzR412o/MjgbMsV8s8xbF9mUgJVocoada61H1FwJ 6WTV0U52mwxQl4K1y1vrm3WJlraAq8Lg3dLtKzjHqHX0V9uRZAQV3l8UF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHMSZlCtJV2a/2dsb2JhbABFgku7VoEIgiABAQEEEgFmEgEIEQMBAgEnORQJCAIEAQ0FFA6HY5g6oCyLGIYnA5I4gzGOQoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,504,1344211200"; d="scan'208,217";a="126515573" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 28 Sep 2012 21:15:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8SLF0sQ013793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 21:15:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 16:15:00 -0500 From: "Lisa Huang (yihuan)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] YANG module for ACL configuration Thread-Index: Ac2HzNG15MFBXELZRDOOZ0+1FVOGjwUlCAGAABGvRYAACE2BgAAOzhwAAACwIgAAKaxWAA== Date: Fri, 28 Sep 2012 21:15:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--39.371500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC8B5C222626Fyihuanciscocom_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 28 Sep 2012 21:15:03 -0000 --_000_CC8B5C222626Fyihuanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There is a different of changing the sequence or changing the key value. Th= e ACL resequence is really changing the value of the key instead of change = order. For example: The original acl instance 1 =85. 2 =85. 3 =85. After resequence with start=3D10 interval=3D10, it will change to: 10 =85. 20 =85. 30 =85. The sequence is not changed but the key value is changed. The name of RPC r= esequence-acl brings confusion of reordering. My question is: what is a rec= ommended way in YANG community to change the key value without delete the i= nstance and recreate the instance again? I see there was some discussion go= ing for interface keying which is a little bit different from rekey in acl. Thanks, Lisa From: Andy Bierman > Date: Thursday, September 27, 2012 11:21 AM To: Martin Bjorklund > Cc: "netmod@ietf.org" > Subject: Re: [netmod] YANG module for ACL configuration On Thu, Sep 27, 2012 at 11:02 AM, Martin Bjorklund > wrote: "Muthumayan Madhayyan (muthu)" > wr= ote: > > > On 9/27/12 12:00 AM, "Martin Bjorklund" > wrote: > > >"Muthumayan Madhayyan (muthu)" >= wrote: > >> One other useful RPC for this ACL module would be a mechanism to > >> re-sequence ACE sequence numbers. > > > >This is the reason why YANG has ordered-by user lists. With an > >ordered-by user list you avoid the renumbering problem, and give the > >user the ability to move entires without renaming/renumbering them. > > Sure.. That will work if the key for the ACE list is a string. In this > case, the key is an integer. > Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5. > Now, we want to add an entry between 3 and 4. > How can we use ordered-by-user in this situation ? Technically it works just fine. The keys don't mean anything - the order of an ordered-by user is the order the user defines. But it would be pretty confusing, so I agree that it is probably better to use a name as key. Yes -- the key is just a unique identifier. It should not be an integer. The YANG insert operation determines the creation order, if it is not the default (last). /martin Andy --_000_CC8B5C222626Fyihuanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
There is= a different of changing the sequence or changing the key value. The ACL re= sequence is really changing the value of the key instead of change order. F= or example:

The orig= inal acl instance

<ipv4= -ace>
<sequence= -num>1</sequence-num>
  &nb= sp;=85.
<ipv4-ace>
<ipv4= -ace>
<sequ= ence-num>2</sequence-num>
   =85.
<ip= v4-ace&g= t;
<ipv4= -ace>
<sequ= ence-num>3</sequence-num>
   =85.
<ip= v4-ace&g= t;

After resequence with start=3D10 = interval=3D10, it will change to:

<ipv4= -ace>
<sequ= ence-num>10</sequence-num>
   =85.
<ip= v4-ace&g= t;
<ipv4= -ace>
<sequ= ence-num>20</sequence-num>
   =85.
<ip= v4-ace&g= t;
<ipv4= -ace>
<sequ= ence-num>30</sequence-num>
   =85.
<ip= v4-ace&g= t;


The sequence is not changed but t= he key value is changed. The name of RPC resequence-acl brings confusion of= reordering. My question is: what is a recommended way in YANG community to change the key value without delete the instance = and recreate the instance again? I see there was some discussion going for = interface keying which is a little bit different from rekey in acl. 

Thanks,

Lisa


From: Andy Bierman <andy@yumaworks.com>
Date: Thursday, September 27, 2012 = 11:21 AM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] YANG module f= or ACL configuration



On Thu, Sep 27, 2012 at 11:02 AM, Martin Bjorklu= nd <mbj@tail-f.com&= gt; wrote:
"Muthumayan Madhayyan (muthu)" <muthu@cisco.com> wrote:
>
>
> On 9/27/12 12:00 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:
>
> >"Muthumayan Madhayyan (muthu)" <muthu@cisco.com> wrote:
> >> One other useful RPC for this ACL module would be a mechanism= to
> >> re-sequence ACE sequence numbers.
> >
> >This is the reason why YANG has ordered-by user lists.  With = an
> >ordered-by user list you avoid the renumbering problem, and give t= he
> >user the ability to move entires without renaming/renumbering them= .
>
> Sure.. That will work if the key for the ACE list is a string. In this=
> case, the key is an integer.
> Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5.=
> Now, we want to add an entry between 3 and 4.
> How can we use ordered-by-user in this situation ?

Technically it works just fine.  The keys don't mean anything - the order of an ordered-by user is the order the user defines.  But it
would be pretty confusing, so I agree that it is probably better to
use a name as key.


Yes -- the key is just a unique identifier.  It should
not be an integer.

The YANG insert operation determines the creation order,
if it is not the default (last).



/martin

Andy

--_000_CC8B5C222626Fyihuanciscocom_-- From andy@yumaworks.com Fri Sep 28 14:21:29 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 E468921F84F6 for ; Fri, 28 Sep 2012 14:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS2TzHyK+Ky7 for ; Fri, 28 Sep 2012 14:21:29 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C235C21F8476 for ; Fri, 28 Sep 2012 14:21:28 -0700 (PDT) Received: by qcac10 with SMTP id c10so1230367qca.31 for ; Fri, 28 Sep 2012 14:21:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7MkKZXyiIPiMH/mR2oLVv2YKLpR2prDgvGlmTz4u7As=; b=R60dCTjt8B/BXtgGcA6lv0dtkrc0/lMiUesaP2IR+9FJABcZHi7YvPn+N7YGuO/EfI dIrYWMHS4GfwDRUQ36xazAk19Qi3gROLOo0d8qLJIPKEifbPtSJrjlfgjt6+3z/mQSxb eJPfzZtnpju9R0Cy+jqZoU4HFosfIeb0g9o7VRqWyKAdEwszCPOD2bMWc7yKGxbahi1K gLa8yY2nrdN+zw4ArFSwEaTiKMeVSjKn0wK4ZcjUkMCEcb4LlXW0oZWCp3cqkQ7B01XI aWJu7qBGE9ym7DIt1u9fXB/4QZnENf0UiiS5J41GNcR+/ZICdbowJOWC69PvGjKE30B9 NwfQ== MIME-Version: 1.0 Received: by 10.224.76.209 with SMTP id d17mr19886669qak.76.1348867288205; Fri, 28 Sep 2012 14:21:28 -0700 (PDT) Received: by 10.49.108.231 with HTTP; Fri, 28 Sep 2012 14:21:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Sep 2012 14:21:28 -0700 Message-ID: From: Andy Bierman To: "Lisa Huang (yihuan)" Content-Type: multipart/alternative; boundary=20cf3074b720900af704cac9a391 X-Gm-Message-State: ALoCoQnrknTHeq/8TAoh+DLaDMe5aNB87QJDIGzZTGu/UrU3W2pslYMIzhmj8N6N47/OCrZHAuv3 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG module for ACL configuration 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, 28 Sep 2012 21:21:30 -0000 --20cf3074b720900af704cac9a391 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But this is kind of like line numbers in BASIC. It might have been OK for the 80s but not now. The relative order of the sibling nodes captures the ordering. The sequence names can be meaningful or arbitrary (even 10, 20, 30). They just have to be unique keys. Andy On Fri, Sep 28, 2012 at 2:15 PM, Lisa Huang (yihuan) wrot= e: > There is a different of changing the sequence or changing the key value. > The ACL resequence is really changing the value of the key instead of > change order. For example: > > The original acl instance > > > 1 > =E2=80=A6. > > > 2 > =E2=80=A6. > > > 3 > =E2=80=A6. > > > After resequence with start=3D10 interval=3D10, it will change to: > > > 10 > =E2=80=A6. > > > 20 > =E2=80=A6. > > > 30 > =E2=80=A6. > > > > The sequence is not changed but the key value is changed. The name of > RPC resequence-acl brings confusion of reordering. My question is: what i= s > a recommended way in YANG community to change the key value without delet= e > the instance and recreate the instance again? I see there was some > discussion going for interface keying which is a little bit different fro= m > rekey in acl. > > Thanks, > > Lisa > > > From: Andy Bierman > Date: Thursday, September 27, 2012 11:21 AM > To: Martin Bjorklund > Cc: "netmod@ietf.org" > Subject: Re: [netmod] YANG module for ACL configuration > > > > On Thu, Sep 27, 2012 at 11:02 AM, Martin Bjorklund wrote= : > >> "Muthumayan Madhayyan (muthu)" wrote: >> > >> > >> > On 9/27/12 12:00 AM, "Martin Bjorklund" wrote: >> > >> > >"Muthumayan Madhayyan (muthu)" wrote: >> > >> One other useful RPC for this ACL module would be a mechanism to >> > >> re-sequence ACE sequence numbers. >> > > >> > >This is the reason why YANG has ordered-by user lists. With an >> > >ordered-by user list you avoid the renumbering problem, and give the >> > >user the ability to move entires without renaming/renumbering them. >> > >> > Sure.. That will work if the key for the ACE list is a string. In this >> > case, the key is an integer. >> > Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5. >> > Now, we want to add an entry between 3 and 4. >> > How can we use ordered-by-user in this situation ? >> >> Technically it works just fine. The keys don't mean anything - the >> order of an ordered-by user is the order the user defines. But it >> would be pretty confusing, so I agree that it is probably better to >> use a name as key. >> >> > Yes -- the key is just a unique identifier. It should > not be an integer. > > The YANG insert operation determines the creation order, > if it is not the default (last). > > > >> /martin >> > > Andy > > --20cf3074b720900af704cac9a391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But this is kind of like line numbers in BASIC.
It might have been OK fo= r the 80s but not now.

The relative order of the sibling nodes captu= res the ordering.
The sequence names can be meaningful or arbitrary (eve= n 10, 20, 30).
They just have to be unique keys.


Andy


On Fri, Sep 28, 2012 at 2:15 PM, Lisa Huang (yihuan) <yihuan@c= isco.com> wrote:
There is a dif= ferent of changing the sequence or changing the key value. The ACL resequen= ce is really changing the value of the key instead of change order. For exa= mple:

The original a= cl instance

<ipv4-ace&g= t;
<sequence-num>1</sequence-num>
=C2=A0 =C2=A0=E2=80=A6.
<ipv4-ace>
<ipv4-ace&g= t;
<sequence-num>2</sequence-num>
= =C2=A0 =C2=A0=E2=80=A6.
&= lt;ipv= 4-ace>
<ipv4-ace&g= t;
<sequence-num>3</sequence-num>
= =C2=A0 =C2=A0=E2=80=A6.
&= lt;ipv= 4-ace>
<= br>
A= fter resequence with start=3D10 interval=3D10, it will change to:
<= br>
<ipv4-ace&g= t;
<sequence-num>10</sequence-num>
= =C2=A0 =C2=A0=E2=80=A6.
&= lt;ipv= 4-ace>
<ipv4-ace&g= t;
<sequence-num>20</sequence-num>
= =C2=A0 =C2=A0=E2=80=A6.
&= lt;ipv= 4-ace>
<ipv4-ace&g= t;
<sequence-num>30</sequence-num>
= =C2=A0 =C2=A0=E2=80=A6.
&= lt;ipv= 4-ace>
<= br>
<= br>
T= he sequence is not changed but the key value is changed. The name of RPC re= sequence-acl brings confusion of reordering. My question is: what is a reco= mmended way in YANG community to change the key value without delete the instance = and recreate the instance again? I see there was some discussion going for = interface keying which is a little bit different from rekey in acl.=C2=A0
<= br>
T= hanks,
<= br>
L= isa
<= br>
<= br>
From: Andy Bierman <andy@yumaworks.com>
Date: Thursday, September 27, 2012 = 11:21 AM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG module f= or ACL configuration



On Thu, Sep 27, 2012 at 11:02 AM, Martin Bjorklu= nd <mbj@tail-f.com&= gt; wrote:
"Muthumayan Madhayyan (muthu)" <muthu@cisco.com> wrote:
>
>
> On 9/27/12 12:00 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:
>
> >"Muthumayan Madhayyan (muthu)" <muthu@cisco.com> wrote:
> >> One other useful RPC for this ACL module would be a mechanism= to
> >> re-sequence ACE sequence numbers.
> >
> >This is the reason why YANG has ordered-by user lists. =C2=A0With = an
> >ordered-by user list you avoid the renumbering problem, and give t= he
> >user the ability to move entires without renaming/renumbering them= .
>
> Sure.. That will work if the key for the ACE list is a string. In this=
> case, the key is an integer.
> Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5.=
> Now, we want to add an entry between 3 and 4.
> How can we use ordered-by-user in this situation ?

Technically it works just fine. =C2=A0The keys don't mean anything - th= e
order of an ordered-by user is the order the user defines. =C2=A0But it
would be pretty confusing, so I agree that it is probably better to
use a name as key.


Yes -- the key is just a unique identifier.=C2=A0 It should
not be an integer.

The YANG insert operation determines the creation order,
if it is not the default (last).



/martin

Andy


--20cf3074b720900af704cac9a391--