From xiangli@seguesoft.com Fri Jan 11 08:19:51 2013 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 C5E7921F882E for ; Fri, 11 Jan 2013 08:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvDtWn+jy9Vo for ; Fri, 11 Jan 2013 08:19:51 -0800 (PST) Received: from m1plsmtpa01-06.prod.mesa1.secureserver.net (m1plsmtpa01-06.prod.mesa1.secureserver.net [64.202.165.34]) by ietfa.amsl.com (Postfix) with ESMTP id E356F21F8470 for ; Fri, 11 Jan 2013 08:19:50 -0800 (PST) Received: from [192.168.2.16] ([98.212.151.151]) by m1plsmtpa01-06.prod.mesa1.secureserver.net with id mgKo1k00Z3GEayi01gKpBT; Fri, 11 Jan 2013 09:19:49 -0700 Message-ID: <50F03BA8.3000203@seguesoft.com> Date: Fri, 11 Jan 2013 10:19:52 -0600 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> In-Reply-To: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.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, 11 Jan 2013 16:19:51 -0000 Hi Looks good...I just have have a simple editorial comment. This draft still does not contain a simple explanation on what these "?", "*", etc. means in the various data module structure diagram: For example: The data model for system identification has the following structure: +--rw system +--rw contact? string +--rw name? string +--rw location? string +--ro platform ... I noticed that the recent ietf-interface and ietf-routing all contain some texts clarifying these symbols. I think ietf-system-module should add such texts too. For example, in ietf-interface yang: 3. Interfaces Data Model The data model in the module "ietf-interfaces" has the following structure, where square brackets are used to enclose a list's keys, "?" means that the leaf is optional, and "*" denotes a leaf-list: +--rw interfaces +--rw interface [name] +--rw name string --Xiang Li On 12/26/2012 2:45 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > Title : YANG Data Model for System Management > Author(s) : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netmod-system-mgmt-04.txt > Pages : 31 > Date : 2012-12-26 > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 Cell 1 (217) 819-0942 From lhotka@nic.cz Sun Jan 13 09:38:37 2013 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 AF2A921F8834 for ; Sun, 13 Jan 2013 09:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 F5cA8QabY+ib for ; Sun, 13 Jan 2013 09:38:37 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2A421F8831 for ; Sun, 13 Jan 2013 09:38:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D847E540868; Sun, 13 Jan 2013 18:38:28 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM-Lj2vIMwzT; Sun, 13 Jan 2013 18:38:13 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 61601540042; Sun, 13 Jan 2013 18:38:02 +0100 (CET) From: Ladislav Lhotka To: "Muthumayan Madhayyan \(muthu\)" In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84262FED@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D84262FED@xmb-rcd-x13.cisco.com> User-Agent: Notmuch/0.14+243~g18d79d1 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Muthumayan Madhayyan \(muthu\)" , netmod@ietf.org Date: Sun, 13 Jan 2013 18:37:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-06 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, 13 Jan 2013 17:38:37 -0000 Hi Muthu, thank you for reviewing the draft, please see my responses inline. I am also sending it to the NETMOD mailing list so that other people can comment the issues. "Muthumayan Madhayyan (muthu)" writes: > Hello Lada, > > I am reviewing this draft with an intent to see if this can be augmented for specific routing protocols and such. That would indeed be an important work! > > However, the terminology: > > main-routing-table, connected-routing-table, additional-routing-table and routing-table is confusing. What we learnt in the process about terminology was that some terms, such as FIB, RIB, routing table a forwarding table, are used by different vendors in different ways, and IETF standards sometimes use the same terms with yet another meaning. See for example this thread: http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html It seems that using terms that look familiar but aren't understood in the same way makes the confusion even worse, so I tried to use other terms that don't bear such connotations. In any case, additional routing table is not a technical term, it is just used in Figure 2 to illustrate the fact that there may be multiple routing tables. > > Correct me if my understanding is off base here: > > * To start with all tables are scoped to a specific afi/safi. Yes. > * Connected-routing-table is really protocol-routes-table (meaning it is populated by individual routing protocols). There is a connected-routing-table per AFI/SAFI per protocol per router instance. Yes, but multiple protocols may be connected to the same table, so the term protocol-routes-table would be misleading, in my opinion. Structures that are specific to a particular protocol instance, such as the link-state database, should be addressed by the (future) routing protocol module. > * Main-routing-table is the final routing table per router instance that consolidates input from all connected-routing-table and creates routes based on some filters and other metrics. What distiguishes main routing tables from the other routing tables is that the main routing tables always receive the direct routes. Other than that, it is up to an implementation to define the role of each routing table. A simple implementation will have just one routing table (per address family) which will be the main routing table and also all protocol instances will be connected to it. > * Routing-table-list is simply a listing of all connected-routing-tables and main-routing-tables across ALL router instances. A flexible routing system may allow for user-defined routing tables that are (by definition) not main routing tables and no protocol is connected to them. Such routing tables may still receive routes from some routing tables and provide routes to others, subject to filters. > * Additional-routing-table is used in the figure, but is not reference anywhere else. The draft clearly states that the figure is only an example. As I said above, "additional routing table" has no special meaning, it just shows that tere can be more than one routing table. > > Can the connected-routing-table be simply called protocol-routes-table ? There is a concept of connected routes which is equivalent to 'direct' routes in your draft. So, at first connected-routing-table was a bit confusing to me. I think the term "connected route" is not correct because such a route is not connected to anything - it is a route to a directly connected network. Also, protocol-routes-table doesn't seem appropriate because the fact that a routing table is connected to a protocol instance doesn't mean that it is reserved for that protocol instance. As I said, the same routing table can be connected to multiple protocol instances. > > Also if the figure can be changed to show the protocol-routes-table and remove references to the 'additional-routing-table' that would be clearer. > > There are two 'filters' defined here: > > * One pair between the connected-routing-table and the routing-protocol > * One pair between source and recipient routing tables. > > Currently both of them refer to the same reference - route-filter-ref. Wouldn't it help to keep them as two different identities ? > Each node of the route-filter-ref type can refer to a different entry in the route-filter list, so I think it is general enough. > > One final question: > > All routing-tables are 'global' meaning it should be possible for a routing table in one router instance to designate the main-routing-table of a different router instance as the recipient routing table. Is that assumption correct ? In principle, yes, but the draft says in sec. 4.3 that implementations may specify additional business rules, and one that is specifically mentioned there is that router instances may not be allowed to share routing tables. Thanks, Lada > > > Thanks, > - muthu > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sun Jan 13 10:08:21 2013 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 22DF521F857D for ; Sun, 13 Jan 2013 10:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 CnWf+Ry5U9Zv for ; Sun, 13 Jan 2013 10:08:20 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7DE21F8578 for ; Sun, 13 Jan 2013 10:08:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B50C9540868 for ; Sun, 13 Jan 2013 19:08:14 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPrvK0tVr2jc for ; Sun, 13 Jan 2013 19:08:02 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 69013540042 for ; Sun, 13 Jan 2013 19:08:02 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.14+243~g18d79d1 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Sun, 13 Jan 2013 19:08:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] [Ladislav Lhotka] Re: draft-ietf-netmod-routing-cfg-06 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, 13 Jan 2013 18:08:21 -0000 "Muthumayan Madhayyan (muthu)" writes: > Another comment I had is that both the main-routing-table and the connected-routing-table are marked implicitly as 'config true' meaning these are provisioned by the netconf client. This is not typical. The routing tables themselves are automagically created when the specific routing protocol is enabled. > Right, this has to do with the issue of operational state versus configuration, and also restrictions of the "leafref" type in YANG. The problem is caused by the fact that the main routing table will typically be, as you say, automagically created and cannot be deleted (i.e. it is operational state) , while other tables may be defined by the client, i.e. they are configuration. But we need to be able to access both in the same way. And this would be impossible if we don't keep *all* routing tables as entries of the same list. Lada > Any thoughts on that ? > > Thanks, > = muthu > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From muthu@cisco.com Sun Jan 13 22:06:02 2013 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 5848721F8800 for ; Sun, 13 Jan 2013 22:06:02 -0800 (PST) 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 sr5KGYnZNno7 for ; Sun, 13 Jan 2013 22:06:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 29ABC21F84B9 for ; Sun, 13 Jan 2013 22:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5706; q=dns/txt; s=iport; t=1358143561; x=1359353161; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=R3BL/E1osEFXrj8r4BY50QJ3T3Aszicn6Th52QMVIOc=; b=iYi19DLyY9QZw4wK6Bwno5s+bdh4QjUwMEkYiZDS2xrPDJ4ZQpYKdRkV oWRR2T1LQ5OiDS+qyIaHPQStwA3nVVnQxZXkCLaASrCOLbor/fBmJ7rKY n9fSwcAzCLPZ8HJBC4XHOTE3dutXzi0JLHQFOtN5saVio9ZEu+Ih4z1SN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAACg81CtJXG8/2dsb2JhbABEvgYWc4IgAQQ6NAsSAQgiFEIlAgQOBQgBiBAMs3eNBoNHYQOmVIJ1gW81 X-IronPort-AV: E=Sophos;i="4.84,465,1355097600"; d="scan'208";a="161805321" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jan 2013 06:06:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0E660Pe015958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 06:06:00 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.125]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 00:06:00 -0600 From: "Muthumayan Madhayyan (muthu)" To: Ladislav Lhotka Thread-Topic: draft-ietf-netmod-routing-cfg-06 Thread-Index: AQHN8ECVRyg5sxqbvUiIFDV+8ipMgJhH7X+AgABK5oA= Date: Mon, 14 Jan 2013 06:05:59 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D84263897@xmb-rcd-x13.cisco.com> 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.5.121010 x-originating-ip: [10.21.115.112] 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] draft-ietf-netmod-routing-cfg-06 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, 14 Jan 2013 06:06:02 -0000 Any ideas on how to achieve route export between VRF and global route tables ? I was hoping to model VRF as a router instance - have multiple protocols and connected-routing-tables and main-routing-table defined under that router instance. =20 With the restrictions of 4.3, seems like that is not permitted. Any other alternatives ? Thanks, - muthu On 1/13/13 9:37 AM, "Ladislav Lhotka" wrote: >Hi Muthu, > >thank you for reviewing the draft, please see my responses inline. I am >also sending it to the NETMOD mailing list so that other people can >comment the issues. > >"Muthumayan Madhayyan (muthu)" writes: > >> Hello Lada, >> >> I am reviewing this draft with an intent to see if this can be >>augmented for specific routing protocols and such. > >That would indeed be an important work! > >> >> However, the terminology: >> >> main-routing-table, connected-routing-table, additional-routing-table >>and routing-table is confusing. > >What we learnt in the process about terminology was that some terms, such >as FIB, RIB, routing table a forwarding table, are used by different >vendors in different ways, and IETF standards sometimes use the same >terms with yet another meaning. See for example this thread: > >http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > >It seems that using terms that look familiar but aren't understood in the >same way makes the confusion even worse, so I tried to use other terms >that don't bear such connotations. > >In any case, additional routing table is not a technical term, it is just >used in Figure 2 to illustrate the fact that there may be multiple >routing tables. >=20 >> >> Correct me if my understanding is off base here: >> >> * To start with all tables are scoped to a specific afi/safi. > >Yes. > >> * Connected-routing-table is really protocol-routes-table (meaning >>it is populated by individual routing protocols). There is a >>connected-routing-table per AFI/SAFI per protocol per router instance. > >Yes, but multiple protocols may be connected to the same table, so the >term protocol-routes-table would be misleading, in my opinion. Structures >that are specific to a particular protocol instance, such as the >link-state database, should be addressed by the (future) routing protocol >module. > >> * Main-routing-table is the final routing table per router >>instance that consolidates input from all connected-routing-table and >>creates routes based on some filters and other metrics. > >What distiguishes main routing tables from the other routing tables is >that the main routing tables always receive the direct routes. Other than >that, it is up to an implementation to define the role of each routing >table. A simple implementation will have just one routing table (per >address family) which will be the main routing table and also all >protocol instances will be connected to it. > >> * Routing-table-list is simply a listing of all >>connected-routing-tables and main-routing-tables across ALL router >>instances. > >A flexible routing system may allow for user-defined routing tables that >are (by definition) not main routing tables and no protocol is connected >to them. Such routing tables may still receive routes from some routing >tables and provide routes to others, subject to filters. > >> * Additional-routing-table is used in the figure, but is not >>reference anywhere else. > >The draft clearly states that the figure is only an example. As I said >above, "additional routing table" has no special meaning, it just shows >that tere can be more than one routing table. > >> >> Can the connected-routing-table be simply called protocol-routes-table >>? There is a concept of connected routes which is equivalent to >>'direct' routes in your draft. So, at first connected-routing-table was >>a bit confusing to me. > >I think the term "connected route" is not correct because such a route is >not connected to anything - it is a route to a directly connected >network. Also, protocol-routes-table doesn't seem appropriate because the >fact that a routing table is connected to a protocol instance doesn't >mean that it is reserved for that protocol instance. As I said, the same >routing table can be connected to multiple protocol instances. > >> >> Also if the figure can be changed to show the protocol-routes-table and >>remove references to the 'additional-routing-table' that would be >>clearer. >> >> There are two 'filters' defined here: >> >> * One pair between the connected-routing-table and the >>routing-protocol >> * One pair between source and recipient routing tables. >> >> Currently both of them refer to the same reference - route-filter-ref. >>Wouldn't it help to keep them as two different identities ? >> > >Each node of the route-filter-ref type can refer to a different entry in >the route-filter list, so I think it is general enough. >=20 >> >> One final question: >> >> All routing-tables are 'global' meaning it should be possible for a >>routing table in one router instance to designate the main-routing-table >>of a different router instance as the recipient routing table. Is that >>assumption correct ? > >In principle, yes, but the draft says in sec. 4.3 that implementations >may specify additional business rules, and one that is specifically >mentioned there is that router instances may not be allowed to share >routing tables. > >Thanks, Lada > >> >> >> Thanks, >> - muthu >> > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Jan 14 00:25:03 2013 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 255FD21F888E for ; Mon, 14 Jan 2013 00:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.452, 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 ltyr6cK1vw96 for ; Mon, 14 Jan 2013 00:25:02 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DCE6321F884C for ; Mon, 14 Jan 2013 00:25:01 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 044C313F786; Mon, 14 Jan 2013 09:25:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1358151900; bh=8a9iSA2KJEXTVk0mMM4Vcq0p7WjojlWQLRR04kBhBCQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G3DtMH2wkm2gRFEKoSUKP1Y/B/5BN/1gHPb8HPWh/TrAy721+GvYLFSWsnwFfckep JyY6mnOPGgLSOwagT7qlwTNw7w2s0C4PsztgBQ88jM0DQCDpq+x+8KhheCtCSDcvqD V/xM/xkZ+Q9ecp+cFmBdPgM5FLjegeU68ZyK96yI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84263897@xmb-rcd-x13.cisco.com> Date: Mon, 14 Jan 2013 09:24:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A949C32AF740C4798AEECF2568F0D84263897@xmb-rcd-x13.cisco.com> To: "Muthumayan Madhayyan (muthu)" X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-06 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, 14 Jan 2013 08:25:03 -0000 On Jan 14, 2013, at 7:05 AM, "Muthumayan Madhayyan (muthu)" = wrote: >=20 > Any ideas on how to achieve route export between VRF and global route > tables ? >=20 > I was hoping to model VRF as a router instance - have multiple = protocols > and connected-routing-tables and main-routing-table defined under that > router instance. This should be possible. In fact, in earlier revisions of the draft each = router instance had its private set of routing tables, and we changed = this so that VRFs can exchange routes with the master instance on a PE = router. > =20 >=20 > With the restrictions of 4.3, seems like that is not permitted. Any = other > alternatives ? Oh, this is a misunderstanding. Sec. 4.3 says: "Some implementations MAY = pose restrictions =85" and examples of typical restrictions are given. = This means that by default router instances may arbitrarily share = routing tables and it is up to an implementation to specify the exact = rules. In the case of MPLS/BGP VPNs, for example, the rules would state = constraints for the exchange of routes between different VRFs and = between each VRF and the master instance. In another implementation, router instances may represent independent = logical routers, and then each routing table will be private to a single = router instance. Lada >=20 > Thanks, > - muthu >=20 > On 1/13/13 9:37 AM, "Ladislav Lhotka" wrote: >=20 >> Hi Muthu, >>=20 >> thank you for reviewing the draft, please see my responses inline. I = am >> also sending it to the NETMOD mailing list so that other people can >> comment the issues. >>=20 >> "Muthumayan Madhayyan (muthu)" writes: >>=20 >>> Hello Lada, >>>=20 >>> I am reviewing this draft with an intent to see if this can be >>> augmented for specific routing protocols and such. >>=20 >> That would indeed be an important work! >>=20 >>>=20 >>> However, the terminology: >>>=20 >>> main-routing-table, connected-routing-table, = additional-routing-table >>> and routing-table is confusing. >>=20 >> What we learnt in the process about terminology was that some terms, = such >> as FIB, RIB, routing table a forwarding table, are used by different >> vendors in different ways, and IETF standards sometimes use the same >> terms with yet another meaning. See for example this thread: >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html >>=20 >> It seems that using terms that look familiar but aren't understood in = the >> same way makes the confusion even worse, so I tried to use other = terms >> that don't bear such connotations. >>=20 >> In any case, additional routing table is not a technical term, it is = just >> used in Figure 2 to illustrate the fact that there may be multiple >> routing tables. >>=20 >>>=20 >>> Correct me if my understanding is off base here: >>>=20 >>> * To start with all tables are scoped to a specific afi/safi. >>=20 >> Yes. >>=20 >>> * Connected-routing-table is really protocol-routes-table = (meaning >>> it is populated by individual routing protocols). There is a >>> connected-routing-table per AFI/SAFI per protocol per router = instance. >>=20 >> Yes, but multiple protocols may be connected to the same table, so = the >> term protocol-routes-table would be misleading, in my opinion. = Structures >> that are specific to a particular protocol instance, such as the >> link-state database, should be addressed by the (future) routing = protocol >> module. >>=20 >>> * Main-routing-table is the final routing table per router >>> instance that consolidates input from all connected-routing-table = and >>> creates routes based on some filters and other metrics. >>=20 >> What distiguishes main routing tables from the other routing tables = is >> that the main routing tables always receive the direct routes. Other = than >> that, it is up to an implementation to define the role of each = routing >> table. A simple implementation will have just one routing table (per >> address family) which will be the main routing table and also all >> protocol instances will be connected to it. >>=20 >>> * Routing-table-list is simply a listing of all >>> connected-routing-tables and main-routing-tables across ALL router >>> instances. >>=20 >> A flexible routing system may allow for user-defined routing tables = that >> are (by definition) not main routing tables and no protocol is = connected >> to them. Such routing tables may still receive routes from some = routing >> tables and provide routes to others, subject to filters. >>=20 >>> * Additional-routing-table is used in the figure, but is not >>> reference anywhere else. >>=20 >> The draft clearly states that the figure is only an example. As I = said >> above, "additional routing table" has no special meaning, it just = shows >> that tere can be more than one routing table. >>=20 >>>=20 >>> Can the connected-routing-table be simply called = protocol-routes-table >>> ? There is a concept of connected routes which is equivalent to >>> 'direct' routes in your draft. So, at first connected-routing-table = was >>> a bit confusing to me. >>=20 >> I think the term "connected route" is not correct because such a = route is >> not connected to anything - it is a route to a directly connected >> network. Also, protocol-routes-table doesn't seem appropriate because = the >> fact that a routing table is connected to a protocol instance doesn't >> mean that it is reserved for that protocol instance. As I said, the = same >> routing table can be connected to multiple protocol instances. >>=20 >>>=20 >>> Also if the figure can be changed to show the protocol-routes-table = and >>> remove references to the 'additional-routing-table' that would be >>> clearer. >>>=20 >>> There are two 'filters' defined here: >>>=20 >>> * One pair between the connected-routing-table and the >>> routing-protocol >>> * One pair between source and recipient routing tables. >>>=20 >>> Currently both of them refer to the same reference - = route-filter-ref. >>> Wouldn't it help to keep them as two different identities ? >>>=20 >>=20 >> Each node of the route-filter-ref type can refer to a different entry = in >> the route-filter list, so I think it is general enough. >>=20 >>>=20 >>> One final question: >>>=20 >>> All routing-tables are 'global' meaning it should be possible for a >>> routing table in one router instance to designate the = main-routing-table >>> of a different router instance as the recipient routing table. Is = that >>> assumption correct ? >>=20 >> In principle, yes, but the draft says in sec. 4.3 that = implementations >> may specify additional business rules, and one that is specifically >> mentioned there is that router instances may not be allowed to share >> routing tables. >>=20 >> Thanks, Lada >>=20 >>>=20 >>>=20 >>> Thanks, >>> - muthu >>>=20 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Jan 14 00:38:33 2013 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 52D4421F86DC for ; Mon, 14 Jan 2013 00:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 WlhWhQxKHSc0 for ; Mon, 14 Jan 2013 00:38:32 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C021F86CB for ; Mon, 14 Jan 2013 00:38:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D2DB95407A9; Mon, 14 Jan 2013 09:38:19 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6LDr48vjpqJ; Mon, 14 Jan 2013 09:38:05 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C89A45406B8; Mon, 14 Jan 2013 09:37:58 +0100 (CET) From: Ladislav Lhotka To: "Muthumayan Madhayyan \(muthu\)" In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84262FED@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D84262FED@xmb-rcd-x13.cisco.com> User-Agent: Notmuch/0.14+243~g18d79d1 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Muthumayan Madhayyan \(muthu\)" , netmod@ietf.org Date: Mon, 14 Jan 2013 09:37:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-06 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, 14 Jan 2013 08:38:33 -0000 "Muthumayan Madhayyan (muthu)" writes: > * Connected-routing-table is really protocol-routes-table (meaning it is populated by individual routing protocols). There is a connected-routing-table per AFI/SAFI per protocol per router instance. If an implementation requires a separate routing table for each protocol instance, it is also easy to do: The main routing table will only receive direct routes, and each protocol instance will be connected to its own routing table. Then, "route pipes" between pairs of these protocol routing tables can be established via the recipient-routing-table configuration. IMO, this is how the Cisco IOS notion of redistributing routes between routing protocols can be implemented. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From muthu@cisco.com Mon Jan 14 08:43:21 2013 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 EFB3321F8904 for ; Mon, 14 Jan 2013 08:43:21 -0800 (PST) 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 VnEp19AvWXkM for ; Mon, 14 Jan 2013 08:43:21 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2921F87A6 for ; Mon, 14 Jan 2013 08:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=778; q=dns/txt; s=iport; t=1358181798; x=1359391398; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1zhimmhekHEq1llvyOaA1j+YxCniX3GE+k0Nzz2eT4s=; b=ggVHTIwphEj79B5LdDKJ7x59u8mImAuCktCslETyU0Uj1o0/30V8Ebrf Elvohs1ODLEUF4c262B7SCQMXs1U4EMPM/O5KKWeZ8nq78M5qWNQLf5Vs DaxMDuSeTuu7vSuASkwo0U8zXrjyZbk1DSw/p0zs0bRcwT5Z5zWOBRWte k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAPg09FCtJV2d/2dsb2JhbABEhXO0TYMzFnOCIAEEeRIBCCJWJQIEDgUIiBG0ZZBNYQOmVIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162204031" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 14 Jan 2013 16:43:18 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0EGhHBW013416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 16:43:18 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.125]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 10:43:17 -0600 From: "Muthumayan Madhayyan (muthu)" To: Ladislav Lhotka Thread-Topic: draft-ietf-netmod-routing-cfg-06 Thread-Index: AQHN8ECVRyg5sxqbvUiIFDV+8ipMgJhH7X+AgABK5oCAAKzvAIAABSCA Date: Mon, 14 Jan 2013 16:43:17 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D842639F5@xmb-rcd-x13.cisco.com> 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.5.121010 x-originating-ip: [10.21.66.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7D11485222B8A84E9FF9D9FC9A0A6DAD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-06 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, 14 Jan 2013 16:43:22 -0000 On 1/14/13 12:24 AM, "Ladislav Lhotka" wrote: >Oh, this is a misunderstanding. Sec. 4.3 says: "Some implementations MAY >pose restrictions =8A" and examples of typical restrictions are given. Thi= s >means that by default router instances may arbitrarily share routing >tables and it is up to an implementation to specify the exact rules. In >the case of MPLS/BGP VPNs, for example, the rules would state constraints >for the exchange of routes between different VRFs and between each VRF >and the master instance. > >In another implementation, router instances may represent independent >logical routers, and then each routing table will be private to a single >router instance. OK. Thanks for the clarification. THis keeps it flexible. From muthu@cisco.com Mon Jan 14 10:54:51 2013 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 A5F8921F8A11 for ; Mon, 14 Jan 2013 10:54:51 -0800 (PST) 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 SDv7Ae8kF0rB for ; Mon, 14 Jan 2013 10:54:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6921F855A for ; Mon, 14 Jan 2013 10:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1583; q=dns/txt; s=iport; t=1358189691; x=1359399291; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=f+mmD4pT1Z4iDGUif2WbdDmpEKM7QeXh1kgsLi594Kw=; b=kbirnZ8mNuwOYOCJMgKXUHentIKcmpbDzDVOCl1FZo8B92gvHBiBTXr2 Li92Tjum5cyaOPr6sypOBSUz3L0KZpYdHkMGx2J1srvjS5SI1wxyP51Dx yQVEafny0egbEO9XUyK+cCD8QN359BPyg/He+g6KS9Ccn51hP/3Z6NziV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANBT9FCtJV2b/2dsb2JhbABEukSDNRZzgh4BAQEDAQEBATc0EA0BCCIUNwslAgQBEgiICwYMtGcEkE1hA6ZUgnWCJA X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="159263493" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jan 2013 18:54:39 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0EIsd51015377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 18:54:39 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.125]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 12:54:39 -0600 From: "Muthumayan Madhayyan (muthu)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] [Ladislav Lhotka] Re: draft-ietf-netmod-routing-cfg-06 Thread-Index: AQHN8bj7eoeUzroBjkmMOSQGahoyQJhJDDWA Date: Mon, 14 Jan 2013 18:54:38 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D84263AD9@xmb-rcd-x13.cisco.com> 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.5.121010 x-originating-ip: [10.155.32.225] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] [Ladislav Lhotka] Re: draft-ietf-netmod-routing-cfg-06 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, 14 Jan 2013 18:54:51 -0000 On 1/13/13 10:08 AM, "Ladislav Lhotka" wrote: >"Muthumayan Madhayyan (muthu)" writes: > >> Another comment I had is that both the main-routing-table and the >>connected-routing-table are marked implicitly as 'config true' meaning >>these are provisioned by the netconf client. This is not typical. The >>routing tables themselves are automagically created when the specific >>routing protocol is enabled. >> > >Right, this has to do with the issue of operational state versus >configuration, and also restrictions of the "leafref" type in YANG. The >problem is caused by the fact that the main routing table will typically >be, as you say, automagically created and cannot be deleted (i.e. it is >operational state) , while other tables may be defined by the client, >i.e. they are configuration. The conceptual tables may be created by configuration, but not necessarily a 'routing-table' configuration. They could be created because a certain protocol was configured ON or some feature (like VRF) was configured. So, it would help if all these tables were read-only tables. > But we need to be able to access both in the same way. >And this would be impossible if we don't keep *all* routing tables as >entries of the same list. > >Lada=20 > > >> Any thoughts on that ? >> >> Thanks, >> =3D muthu >> > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From david.kessens@nsn.com Fri Jan 18 17:16:45 2013 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 851AB21F86FD for ; Fri, 18 Jan 2013 17:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3u5-7zP4E+H for ; Fri, 18 Jan 2013 17:16:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 99CE321F86A9 for ; Fri, 18 Jan 2013 17:16:44 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0J1GhOv004493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 19 Jan 2013 02:16:43 +0100 Received: from localhost.localdomain ([10.138.48.18]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0J1GfaK021164 for ; Sat, 19 Jan 2013 02:16:42 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id r0J1GfaW031298 for ; Fri, 18 Jan 2013 17:16:41 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id r0J1Gfwa031297 for netmod@ietf.org; Fri, 18 Jan 2013 17:16:41 -0800 Date: Fri, 18 Jan 2013 17:16:41 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20130119011641.GK11206@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 608 X-purgate-ID: 151667::1358558203-00003C02-4DAA4933/0-0/0-0 Subject: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 19 Jan 2013 01:16:45 -0000 Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 This document is needed in order to move: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08 http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07 http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06 towards the IESG and publication. Please indicate your support by February 4, 2012. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved. Thanks! David Kessens co-chair netmod wg --- From dromasca@avaya.com Sun Jan 20 01:55:27 2013 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 08D3521F8507 for ; Sun, 20 Jan 2013 01:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.404 X-Spam-Level: X-Spam-Status: No, score=-103.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 U23PMqA-hjwm for ; Sun, 20 Jan 2013 01:55:26 -0800 (PST) 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 E807B21F8505 for ; Sun, 20 Jan 2013 01:55:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAkE71DGmAcF/2dsb2JhbABEgmu7ABZzgh4BAQEBAwEBAQ8LHTQXBAIBCA0EBAEBCxQJBycLFAkIAgQBEggah3cBC5o8mX6MXINiYQOSWYRPhHGKPIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,446,1355115600"; d="scan'208";a="340388722" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Jan 2013 04:46:37 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Jan 2013 04:50:19 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 04:55:31 -0500 From: "Romascanu, Dan (Dan)" To: David Kessens , "netmod@ietf.org" Thread-Topic: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) Thread-Index: AQHN9eK63kC9rQQ/v0+e6huo0y4CHJhR/Azw Date: Sun, 20 Jan 2013 09:55:29 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> References: <20130119011641.GK11206@nsn.com> In-Reply-To: <20130119011641.GK11206@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 20 Jan 2013 09:55:27 -0000 Hi, Does this document obsolete RFC6021? The header says nothing about this.=20 Is this an official WG document? If so, why is it not named draft-ietf-netm= od-rfc6021bisp... or something similar?=20 Thanks and Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of David Kessens > Sent: Saturday, January 19, 2013 3:17 AM > To: netmod@ietf.org > Subject: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 > (20130204) >=20 >=20 > Hi, >=20 > I would hereby like to start a Last Call for: >=20 > http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 >=20 > This document is needed in order to move: >=20 > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08 > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07 > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06 >=20 > towards the IESG and publication. >=20 > Please indicate your support by February 4, 2012. Or alternatively, let > us know in the same timeframe whether there are still issues that need > to be resolved. >=20 > Thanks! >=20 > David Kessens > co-chair netmod wg > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Sun Jan 20 02:40:44 2013 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 13DEE21F84F2 for ; Sun, 20 Jan 2013 02:40:44 -0800 (PST) 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 TosRuq0WH7YJ for ; Sun, 20 Jan 2013 02:40:43 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7FE21F84E7 for ; Sun, 20 Jan 2013 02:40:43 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F18A20BEA; Sun, 20 Jan 2013 11:40:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kloqnoTEdHzP; Sun, 20 Jan 2013 11:40:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D131320BE9; Sun, 20 Jan 2013 11:40:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E19B3240DDFA; Sun, 20 Jan 2013 11:40:44 +0100 (CET) Date: Sun, 20 Jan 2013 11:40:44 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130120104044.GA38007@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Kessens , "netmod@ietf.org" References: <20130119011641.GK11206@nsn.com> <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 20 Jan 2013 10:40:44 -0000 On Sun, Jan 20, 2013 at 09:55:29AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > Does this document obsolete RFC6021? The header says nothing about this. This is the idea. I have added a sentence to the abstract and the obsoletes header line. > Is this an official WG document? If so, why is it not named draft-ietf-netmod-rfc6021bisp... or something similar? > I guess we will know after the WG last call whether the WG has agreement to put the definitions needed by the other WG documents into this document. But this is really for David to explain if more explanation is needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Jan 20 23:36:33 2013 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 6858621F8689 for ; Sun, 20 Jan 2013 23:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpkjGZy2tXv1 for ; Sun, 20 Jan 2013 23:36:33 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09321F85DA for ; Sun, 20 Jan 2013 23:36:28 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A3E9A1200CB0 for ; Mon, 21 Jan 2013 08:36:25 +0100 (CET) Date: Mon, 21 Jan 2013 08:36:25 +0100 (CET) Message-Id: <20130121.083625.409305784.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20130119011641.GK11206@nsn.com> References: <20130119011641.GK11206@nsn.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 07:36:33 -0000 Hi, David Kessens wrote: > > Hi, > > I would hereby like to start a Last Call for: > > http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 I have reviewed this document, and I support it moving forward. Some comments though: The pattern for hex-string is: pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; it should be: pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*'; The pattern for uuid is: pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}' + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; it should be: pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-' + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; /martin From j.schoenwaelder@jacobs-university.de Mon Jan 21 00:13:55 2013 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 2A54621F8860 for ; Mon, 21 Jan 2013 00:13:55 -0800 (PST) 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 aiOLBnWkFYFY for ; Mon, 21 Jan 2013 00:13:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D268821F884C for ; Mon, 21 Jan 2013 00:13:47 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9236420BDA; Mon, 21 Jan 2013 09:13:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wLR2WwPRlAC0; Mon, 21 Jan 2013 09:13:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D694208C6; Mon, 21 Jan 2013 09:13:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F85D240EAB0; Mon, 21 Jan 2013 09:13:49 +0100 (CET) Date: Mon, 21 Jan 2013 09:13:49 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130121081349.GA39454@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130119011641.GK11206@nsn.com> <20130121.083625.409305784.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130121.083625.409305784.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 08:13:55 -0000 On Mon, Jan 21, 2013 at 08:36:25AM +0100, Martin Bjorklund wrote: > Hi, > > David Kessens wrote: > > > > Hi, > > > > I would hereby like to start a Last Call for: > > > > http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 > > I have reviewed this document, and I support it moving forward. > > Some comments though: > > The pattern for hex-string is: > > pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; > > it should be: > > pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*'; Fixed. > The pattern for uuid is: > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}' > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > it should be: > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-' > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; Yes, indeed. Fixed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Jan 21 00:35:45 2013 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 DB1DB21F842C for ; Mon, 21 Jan 2013 00:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYevCN+zoOEV for ; Mon, 21 Jan 2013 00:35:45 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75F21F842A for ; Mon, 21 Jan 2013 00:35:45 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7DD0B1200045; Mon, 21 Jan 2013 09:35:43 +0100 (CET) Date: Mon, 21 Jan 2013 09:35:43 +0100 (CET) Message-Id: <20130121.093543.155016110.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130121081349.GA39454@elstar.local> References: <20130119011641.GK11206@nsn.com> <20130121.083625.409305784.mbj@tail-f.com> <20130121081349.GA39454@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 08:35:46 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 21, 2013 at 08:36:25AM +0100, Martin Bjorklund wrote: > > The pattern for uuid is: > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}' > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > it should be: > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-' > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > Yes, indeed. Fixed. Actually, a collegue of mine just pointed out that it should be: pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; /martin From j.schoenwaelder@jacobs-university.de Mon Jan 21 00:41:59 2013 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 D05F521F8443 for ; Mon, 21 Jan 2013 00:41:59 -0800 (PST) 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 zA8iXVerFJWl for ; Mon, 21 Jan 2013 00:41:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7432021F8440 for ; Mon, 21 Jan 2013 00:41:58 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3AC620BDA; Mon, 21 Jan 2013 09:41:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RNBUIHKWi7rH; Mon, 21 Jan 2013 09:41:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B2C020BD5; Mon, 21 Jan 2013 09:41:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 01EC8240F2A3; Mon, 21 Jan 2013 09:41:59 +0100 (CET) Date: Mon, 21 Jan 2013 09:41:59 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130121084159.GA39668@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130119011641.GK11206@nsn.com> <20130121.083625.409305784.mbj@tail-f.com> <20130121081349.GA39454@elstar.local> <20130121.093543.155016110.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130121.093543.155016110.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 08:42:00 -0000 On Mon, Jan 21, 2013 at 09:35:43AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jan 21, 2013 at 08:36:25AM +0100, Martin Bjorklund wrote: > > > The pattern for uuid is: > > > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}' > > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > > > it should be: > > > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-' > > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > Yes, indeed. Fixed. > > Actually, a collegue of mine just pointed out that it should be: > > pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' > + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; Why? I am trying to follow RFC 4122 section 3. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Jan 21 00:47:52 2013 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 8D59521F85EE for ; Mon, 21 Jan 2013 00:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrKXFgCOLxb2 for ; Mon, 21 Jan 2013 00:47:52 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92B21F85C3 for ; Mon, 21 Jan 2013 00:47:52 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 503241200045; Mon, 21 Jan 2013 09:47:51 +0100 (CET) Date: Mon, 21 Jan 2013 09:47:50 +0100 (CET) Message-Id: <20130121.094750.471028874.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130121084159.GA39668@elstar.local> References: <20130121081349.GA39454@elstar.local> <20130121.093543.155016110.mbj@tail-f.com> <20130121084159.GA39668@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 08:47:52 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 21, 2013 at 09:35:43AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Mon, Jan 21, 2013 at 08:36:25AM +0100, Martin Bjorklund wrote: > > > > The pattern for uuid is: > > > > > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}' > > > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > > > > > it should be: > > > > > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-' > > > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > > > Yes, indeed. Fixed. > > > > Actually, a collegue of mine just pointed out that it should be: > > > > pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' > > + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; > > Why? I am trying to follow RFC 4122 section 3. Yes. It says e.g. time-low = 4hexOctet but an hexOctet is defined as: hexOctet = hexDigit hexDigit so time-low consists of 8 hex digits. /martin From j.schoenwaelder@jacobs-university.de Mon Jan 21 00:58:02 2013 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 872A321F85C3 for ; Mon, 21 Jan 2013 00:58:02 -0800 (PST) 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 OdualxNbneHO for ; Mon, 21 Jan 2013 00:58:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1871421F8640 for ; Mon, 21 Jan 2013 00:57:59 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6977C20BD5; Mon, 21 Jan 2013 09:57:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qw4xJp2BaijH; Mon, 21 Jan 2013 09:57:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05B682095C; Mon, 21 Jan 2013 09:57:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5870D240F35F; Mon, 21 Jan 2013 09:58:01 +0100 (CET) Date: Mon, 21 Jan 2013 09:58:01 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130121085801.GB39668@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130121081349.GA39454@elstar.local> <20130121.093543.155016110.mbj@tail-f.com> <20130121084159.GA39668@elstar.local> <20130121.094750.471028874.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130121.094750.471028874.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 08:58:02 -0000 On Mon, Jan 21, 2013 at 09:47:50AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jan 21, 2013 at 09:35:43AM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Mon, Jan 21, 2013 at 08:36:25AM +0100, Martin Bjorklund wrote: > > > > > The pattern for uuid is: > > > > > > > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}' > > > > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > > > > > > > it should be: > > > > > > > > > > pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-' > > > > > + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}'; > > > > > > > > Yes, indeed. Fixed. > > > > > > Actually, a collegue of mine just pointed out that it should be: > > > > > > pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' > > > + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; > > > > Why? I am trying to follow RFC 4122 section 3. > > Yes. It says e.g. > > time-low = 4hexOctet > > but an hexOctet is defined as: > > hexOctet = hexDigit hexDigit > > so time-low consists of 8 hex digits. Thanks, now I got it. Fixed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Jan 21 05:29:09 2013 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 5338021F8749 for ; Mon, 21 Jan 2013 05:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HOST_EQ_CZ=0.904, 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 QZUoMLjQVHxQ for ; Mon, 21 Jan 2013 05:29:08 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A748221F8742 for ; Mon, 21 Jan 2013 05:29:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8E35D540706 for ; Mon, 21 Jan 2013 14:29:01 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apSvvbB+b+22 for ; Mon, 21 Jan 2013 14:28:49 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9B237540071 for ; Mon, 21 Jan 2013 14:28:44 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130119011641.GK11206@nsn.com> References: <20130119011641.GK11206@nsn.com> User-Agent: Notmuch/0.14+243~g18d79d1 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 21 Jan 2013 14:28:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 13:29:09 -0000 Hi, I support moving this document forward, with two comments: 1. The second pattern for "yang-identifier" type can be slightly optimized: OLD pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; NEW pattern '..?|[^xX].*|.[^mM].*|..[^lL].*'; 2. It would be safer to have types 'ipv[46]-address' (meaning no zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I suspect that many implementers will not bother to look up the definition when seeing a type like 'ipv4-address' and assume a plain IPv4 address in that place. Such a mistake can easily create a security hole. The name 'ipv[46]-address-with-zone' makes the optional presence of a zone index explicit and eliminates this potential trap. Besides, it would also better fit the naming scheme of corresponding textual conventions in RFC 4001. Lada David Kessens writes: > Hi, > > I would hereby like to start a Last Call for: > > http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Jan 21 05:39:54 2013 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 B4DE421F84F1 for ; Mon, 21 Jan 2013 05:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=0.252, 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 CTRyBoQDX9hh for ; Mon, 21 Jan 2013 05:39:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A58E21F8506 for ; Mon, 21 Jan 2013 05:39:50 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B985720A6D; Mon, 21 Jan 2013 14:39:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DeybN3ttOJBx; Mon, 21 Jan 2013 14:39:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A2F320A1F; Mon, 21 Jan 2013 14:39:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C76BF2417588; Mon, 21 Jan 2013 14:39:52 +0100 (CET) Date: Mon, 21 Jan 2013 14:39:52 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130121133952.GA40864@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20130119011641.GK11206@nsn.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] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 13:39:54 -0000 On Mon, Jan 21, 2013 at 02:28:43PM +0100, Ladislav Lhotka wrote: > Hi, > > I support moving this document forward, with two comments: > > 1. The second pattern for "yang-identifier" type can be slightly optimized: > > OLD > > pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; > > NEW > > pattern '..?|[^xX].*|.[^mM].*|..[^lL].*'; Not sure what the metric is that is optimized here or how to choose between the two. > 2. It would be safer to have types 'ipv[46]-address' (meaning no zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I suspect that many implementers will not bother to look up the definition when seeing a type like 'ipv4-address' and assume a plain IPv4 address in that place. Such a mistake can easily create a security hole. The name 'ipv[46]-address-with-zone' makes the optional presence of a zone index explicit and eliminates this potential trap. Besides, it would also better fit the naming scheme of corresponding textual conventions in RFC 4001. It is still an incompatible change. We can't change 'ipv[46]-address'. We can deprecate it and provide a replacement. Personally, I do not think this is needed or desirable. The IPv6 WG just reached concensus to allow zone indexes in URIs and there was no a concern that this creates a security hole as far as I understand. What might happen is that people forget to implement support for addresses including a zoneid. That said, for stuff sitting above the IP layer, having zones included 'by default' is in my view a feature and not a bug. /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 Jan 21 06:51:10 2013 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 DDA0E21F8561 for ; Mon, 21 Jan 2013 06:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=1.381, 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 Nlfe1SByWkYa for ; Mon, 21 Jan 2013 06:51:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E865821F8475 for ; Mon, 21 Jan 2013 06:51:09 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B52CE13FC96; Mon, 21 Jan 2013 15:51:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1358779868; bh=L3/C8JM6ApcTsq4BRTPLvNu1DDE5yH/v/SR/CuZOVqc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CEYE8ztzf57qc9//WHOoKqY5Qn/XDtW9Whf/X1TiD7pI4paH+LX7PfvzM5IN4b/6N mYLego7DEqPjPw/bFn+9jql0QJpoZUHwt7PjmEIeOQOT6TKQt5LxZ9vL7ZGPIL7ZV8 QqIqhXnfu7FMObP3r4w3sNbEVE+nnHMkk/un0ILU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130121133952.GA40864@elstar.local> Date: Mon, 21 Jan 2013 15:51:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CE6FBBB-5019-4647-BC5F-58E6A6AE5CF5@nic.cz> References: <20130119011641.GK11206@nsn.com> <20130121133952.GA40864@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 14:51:11 -0000 On Jan 21, 2013, at 2:39 PM, Juergen Schoenwaelder = wrote: > On Mon, Jan 21, 2013 at 02:28:43PM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> I support moving this document forward, with two comments: >>=20 >> 1. The second pattern for "yang-identifier" type can be slightly = optimized: >>=20 >> OLD >>=20 >> pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; >>=20 >> NEW >>=20 >> pattern '..?|[^xX].*|.[^mM].*|..[^lL].*'; >=20 > Not sure what the metric is that is optimized here or how to choose > between the two. The metric is string length and the number of alternatives. >=20 >> 2. It would be safer to have types 'ipv[46]-address' (meaning no = zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and = 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I = suspect that many implementers will not bother to look up the definition = when seeing a type like 'ipv4-address' and assume a plain IPv4 address = in that place. Such a mistake can easily create a security hole. The = name 'ipv[46]-address-with-zone' makes the optional presence of a zone = index explicit and eliminates this potential trap. Besides, it would = also better fit the naming scheme of corresponding textual conventions = in RFC 4001. >=20 > It is still an incompatible change. We can't change 'ipv[46]-address'. > We can deprecate it and provide a replacement. This is not an option in this case - we can't deprecate a typedef such = as "ipv4-address" and introduce a new one with the same name.=20 >=20 > Personally, I do not think this is needed or desirable. The IPv6 WG > just reached concensus to allow zone indexes in URIs and there was no > a concern that this creates a security hole as far as I understand. In URIs, IP addresses (with or without zone indices) are enclosed in = brackets. In our case, the zone index is an arbitrarily long suffix = without any delimiters. > What might happen is that people forget to implement support for > addresses including a zoneid. That said, for stuff sitting above the > IP layer, having zones included 'by default' is in my view a feature > and not a bug. OK, let me just mention that both I and Martin already fell into that = trap, and so did the authors of the dnsccm module, I think: = http://dnsccm.org/projects/dnsccm/repository/entry/trunk/dnsccm/modules/dn= sccm/dnsccm.in.yang 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 Jan 21 07:29:07 2013 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 2AB6421F8581 for ; Mon, 21 Jan 2013 07:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.048 X-Spam-Level: X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=0.201, 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 reqOawoDqU0V for ; Mon, 21 Jan 2013 07:29:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 24A3E21F854C for ; Mon, 21 Jan 2013 07:29:06 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DBBE20BD5; Mon, 21 Jan 2013 16:29:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r1FPfFLx6Nb6; Mon, 21 Jan 2013 16:29:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB86420733; Mon, 21 Jan 2013 16:29:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 665BC2417CBA; Mon, 21 Jan 2013 16:29:07 +0100 (CET) Date: Mon, 21 Jan 2013 16:29:06 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130121152906.GA41189@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20130119011641.GK11206@nsn.com> <20130121133952.GA40864@elstar.local> <0CE6FBBB-5019-4647-BC5F-58E6A6AE5CF5@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0CE6FBBB-5019-4647-BC5F-58E6A6AE5CF5@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 15:29:07 -0000 On Mon, Jan 21, 2013 at 03:51:06PM +0100, Ladislav Lhotka wrote: > > On Jan 21, 2013, at 2:39 PM, Juergen Schoenwaelder wrote: > > > On Mon, Jan 21, 2013 at 02:28:43PM +0100, Ladislav Lhotka wrote: > >> Hi, > >> > >> I support moving this document forward, with two comments: > >> > >> 1. The second pattern for "yang-identifier" type can be slightly optimized: > >> > >> OLD > >> > >> pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; > >> > >> NEW > >> > >> pattern '..?|[^xX].*|.[^mM].*|..[^lL].*'; > > > > Not sure what the metric is that is optimized here or how to choose > > between the two. > > The metric is string length and the number of alternatives. Well... > > > >> 2. It would be safer to have types 'ipv[46]-address' (meaning no zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I suspect that many implementers will not bother to look up the definition when seeing a type like 'ipv4-address' and assume a plain IPv4 address in that place. Such a mistake can easily create a security hole. The name 'ipv[46]-address-with-zone' makes the optional presence of a zone index explicit and eliminates this potential trap. Besides, it would also better fit the naming scheme of corresponding textual conventions in RFC 4001. > > > > It is still an incompatible change. We can't change 'ipv[46]-address'. > > We can deprecate it and provide a replacement. > > This is not an option in this case - we can't deprecate a typedef such as "ipv4-address" and introduce a new one with the same name. I did not say same name... > > > > Personally, I do not think this is needed or desirable. The IPv6 WG > > just reached concensus to allow zone indexes in URIs and there was no > > a concern that this creates a security hole as far as I understand. > > In URIs, IP addresses (with or without zone indices) are enclosed in brackets. In our case, the zone index is an arbitrarily long suffix without any delimiters. How is that different? > > What might happen is that people forget to implement support for > > addresses including a zoneid. That said, for stuff sitting above the > > IP layer, having zones included 'by default' is in my view a feature > > and not a bug. > > OK, let me just mention that both I and Martin already fell into that trap, and so did the authors of the dnsccm module, I think: > > http://dnsccm.org/projects/dnsccm/repository/entry/trunk/dnsccm/modules/dnsccm/dnsccm.in.yang > I can't judge where they did fall into a trap. Perhaps they got things right - I really can't judge. Anyway, please make an actionable concrete proposal if you want. I do not think we are going to break YANG update rules for this. Hence your initial proposal does not seem actionable. /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 Jan 21 07:40:48 2013 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 303A921F8735 for ; Mon, 21 Jan 2013 07:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=0.691, 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 6n+aYETlnU0T for ; Mon, 21 Jan 2013 07:40:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 19FEC21F8726 for ; Mon, 21 Jan 2013 07:40:47 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 61D0F13FC96; Mon, 21 Jan 2013 16:40:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1358782846; bh=TUMYwoNZIuJ5FbufrPTsOC0uJQFtNwSidk2x57FLD1w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KcylnptAzRRdJDt61T8PvYlrHyGPU4JG1pnPxljeOBuoTt+62EuDuOxlCrKfVX+Re I8r22C1MwNZG2n/ZzhKU1TdbtL+q93UMYTWZDBw7jImmNxIX6VvraiUyzNmg491GSB MuhXzzHuNwBZRAC5ltoKmcGctIXIatV7LKtV5SgE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130121152906.GA41189@elstar.local> Date: Mon, 21 Jan 2013 16:40:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55915B4B-DD86-4DB8-899B-362CA52CE0CD@nic.cz> References: <20130119011641.GK11206@nsn.com> <20130121133952.GA40864@elstar.local> <0CE6FBBB-5019-4647-BC5F-58E6A6AE5CF5@nic.cz> <20130121152906.GA41189@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 15:40:48 -0000 On Jan 21, 2013, at 4:29 PM, Juergen Schoenwaelder = wrote: > On Mon, Jan 21, 2013 at 03:51:06PM +0100, Ladislav Lhotka wrote: >>=20 >> On Jan 21, 2013, at 2:39 PM, Juergen Schoenwaelder = wrote: >>=20 >>> On Mon, Jan 21, 2013 at 02:28:43PM +0100, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> I support moving this document forward, with two comments: >>>>=20 >>>> 1. The second pattern for "yang-identifier" type can be slightly = optimized: >>>>=20 >>>> OLD >>>>=20 >>>> pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; >>>>=20 >>>> NEW >>>>=20 >>>> pattern '..?|[^xX].*|.[^mM].*|..[^lL].*'; >>>=20 >>> Not sure what the metric is that is optimized here or how to choose >>> between the two. >>=20 >> The metric is string length and the number of alternatives. >=20 > Well... >=20 >>>=20 >>>> 2. It would be safer to have types 'ipv[46]-address' (meaning no = zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and = 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I = suspect that many implementers will not bother to look up the definition = when seeing a type like 'ipv4-address' and assume a plain IPv4 address = in that place. Such a mistake can easily create a security hole. The = name 'ipv[46]-address-with-zone' makes the optional presence of a zone = index explicit and eliminates this potential trap. Besides, it would = also better fit the naming scheme of corresponding textual conventions = in RFC 4001. >>>=20 >>> It is still an incompatible change. We can't change = 'ipv[46]-address'. >>> We can deprecate it and provide a replacement. >>=20 >> This is not an option in this case - we can't deprecate a typedef = such as "ipv4-address" and introduce a new one with the same name.=20 >=20 > I did not say same name... >=20 >>>=20 >>> Personally, I do not think this is needed or desirable. The IPv6 WG >>> just reached concensus to allow zone indexes in URIs and there was = no >>> a concern that this creates a security hole as far as I understand. >>=20 >> In URIs, IP addresses (with or without zone indices) are enclosed in = brackets. In our case, the zone index is an arbitrarily long suffix = without any delimiters. >=20 > How is that different? >=20 >>> What might happen is that people forget to implement support for >>> addresses including a zoneid. That said, for stuff sitting above the >>> IP layer, having zones included 'by default' is in my view a feature >>> and not a bug. >>=20 >> OK, let me just mention that both I and Martin already fell into that = trap, and so did the authors of the dnsccm module, I think: >>=20 >> = http://dnsccm.org/projects/dnsccm/repository/entry/trunk/dnsccm/modules/dn= sccm/dnsccm.in.yang >>=20 >=20 > I can't judge where they did fall into a trap. Perhaps they got things > right - I really can't judge. >=20 > Anyway, please make an actionable concrete proposal if you want. I do > not think we are going to break YANG update rules for this. Hence your > initial proposal does not seem actionable. If there is nobody else who thinks it might be a problem, let's keep the = current typedefs. 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 phil@juniper.net Mon Jan 21 08:50:34 2013 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 970CE21F87F7 for ; Mon, 21 Jan 2013 08:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 kwSENR26Xojq for ; Mon, 21 Jan 2013 08:50:34 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id E9EE221F856D for ; Mon, 21 Jan 2013 08:50:31 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUP1x1+SfW63GmlXn2lkjb0dJoIujDi9B@postini.com; Mon, 21 Jan 2013 08:50:33 PST 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; Mon, 21 Jan 2013 08:49:47 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r0LGnk364242; Mon, 21 Jan 2013 08:49:47 -0800 (PST) (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 r0LGmtcC082217; Mon, 21 Jan 2013 11:49:16 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201301211649.r0LGmtcC082217@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20130121.083625.409305784.mbj@tail-f.com> Date: Mon, 21 Jan 2013 11:48:55 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 16:50:34 -0000 Martin Bjorklund writes: >The pattern for hex-string ..... > pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*'; Why not support "f:0:4:3:3:1" (single digits)? Do we canonicalize to upper or lower case? Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Jan 21 09:08:07 2013 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 3D43321F87F3 for ; Mon, 21 Jan 2013 09:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.081 X-Spam-Level: X-Spam-Status: No, score=-103.081 tagged_above=-999 required=5 tests=[AWL=0.168, 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 IZfZjI74SjLt for ; Mon, 21 Jan 2013 09:08:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B94921F87C8 for ; Mon, 21 Jan 2013 09:08:06 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2AE620BD8; Mon, 21 Jan 2013 18:08:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zUl-GLIuDwj9; Mon, 21 Jan 2013 18:08:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F4FE20BD5; Mon, 21 Jan 2013 18:08:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 384CA2417FA3; Mon, 21 Jan 2013 18:08:08 +0100 (CET) Date: Mon, 21 Jan 2013 18:08:08 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20130121170808.GA41335@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20130121.083625.409305784.mbj@tail-f.com> <201301211649.r0LGmtcC082217@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301211649.r0LGmtcC082217@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 21 Jan 2013 17:08:07 -0000 On Mon, Jan 21, 2013 at 11:48:55AM -0500, Phil Shafer wrote: > Martin Bjorklund writes: > >The pattern for hex-string ..... > > pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*'; > > Why not support "f:0:4:3:3:1" (single digits)? Never seen that before. > Do we canonicalize to upper or lower case? The full definition reads like this: typedef hex-string { type string { pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*'; } description "A hexadecimal string with octets represented as hex digits separated by colons. The canonical representation uses lowercase characters."; } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.kessens@nsn.com Tue Jan 22 20:53:05 2013 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 9DB1B21F859A for ; Tue, 22 Jan 2013 20:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4wc9LdSINNCw for ; Tue, 22 Jan 2013 20:53:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9721F84DE for ; Tue, 22 Jan 2013 20:53:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0N4r0Xc023148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jan 2013 05:53:00 +0100 Received: from localhost.localdomain ([10.138.53.23]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0N4qwUT009889; Wed, 23 Jan 2013 05:52:59 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id r0N4qvdj009898; Tue, 22 Jan 2013 20:52:57 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id r0N4qvHO009897; Tue, 22 Jan 2013 20:52:57 -0800 Date: Tue, 22 Jan 2013 20:52:57 -0800 From: David Kessens To: "Romascanu, Dan (Dan)" Message-ID: <20130123045257.GP11206@nsn.com> References: <20130119011641.GK11206@nsn.com> <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 932 X-purgate-ID: 151667::1358916780-00003C02-1D60221D/0-0/0-0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 23 Jan 2013 04:53:05 -0000 Dan, On Sun, Jan 20, 2013 at 09:55:29AM +0000, Romascanu, Dan (Dan) wrote: > > Does this document obsolete RFC6021? The header says nothing about this. for completeness sake: yes > Is this an official WG document? If so, why is it not named draft-ietf-netmod-rfc6021bisp... or something similar? We are jumping the gun a bit here: it is not really about a new document, but putting the already agreed upon content it in a new version of another already published document. So yes, the Last Call is about getting it published and making it a wg document at the same time. The last was implicit but I should have called that out. Having said this, it seems a new version will be necessary anyways and I will be able to correct all this with better wording in a new Last Call of a new and improved version. I hope this helps, and let me know if you have any remaining concerns, David Kessens --- From bertietf@bwijnen.net Wed Jan 23 00:20:44 2013 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 9C62921F8933 for ; Wed, 23 Jan 2013 00:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 sFBknqeeJtcm for ; Wed, 23 Jan 2013 00:20:43 -0800 (PST) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id A253A21F85DC for ; Wed, 23 Jan 2013 00:20:42 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.80) (envelope-from ) id 1TxvZU-0007Ft-M0; Wed, 23 Jan 2013 09:20:36 +0100 Message-ID: <262632340D0B403EAADA6245BA3570FF@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "David Kessens" , "Romascanu, Dan \(Dan\)" References: <20130119011641.GK11206@nsn.com><9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> <20130123045257.GP11206@nsn.com> In-Reply-To: <20130123045257.GP11206@nsn.com> Date: Wed, 23 Jan 2013 09:13:39 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 23 Jan 2013 08:20:44 -0000 IF you do a new revision and a new WGLC, then you might as well rename the document to a wg document name (draft-ietf-netmod...) at the same time. Bert ----- Original Message ----- From: "David Kessens" To: "Romascanu, Dan (Dan)" Cc: Sent: Wednesday, January 23, 2013 5:52 AM Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) > > Dan, > > On Sun, Jan 20, 2013 at 09:55:29AM +0000, Romascanu, Dan (Dan) wrote: >> >> Does this document obsolete RFC6021? The header says nothing about this. > > for completeness sake: yes > >> Is this an official WG document? If so, why is it not named >> draft-ietf-netmod-rfc6021bisp... or something similar? > > We are jumping the gun a bit here: it is not really about a new document, > but putting the already agreed upon content it in a new version of another > already published document. > > So yes, the Last Call is about getting it published and making it a wg > document at the same time. The last was implicit but I should have called > that out. > > Having said this, it seems a new version will be necessary anyways and I > will be able to correct all this with better wording in a new Last Call of > a new and improved version. > > I hope this helps, and let me know if you have any remaining concerns, > > David Kessens > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From dromasca@avaya.com Wed Jan 23 00:29:12 2013 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 60C8321F8573 for ; Wed, 23 Jan 2013 00:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 PX0dG2Exy+c3 for ; Wed, 23 Jan 2013 00:29:12 -0800 (PST) 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 A7FE121F8546 for ; Wed, 23 Jan 2013 00:29:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAkE71DGmAcF/2dsb2JhbABEgmu7ABZzgh4BAQEBAxIoPwwEAgEIDQQEAQEBChQJBzIUCQgCBA4FCBqHdwGaR5l+kD5hA5wZijyCdYIk X-IronPort-AV: E=Sophos;i="4.84,446,1355115600"; d="scan'208";a="340744791" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jan 2013 03:20:17 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jan 2013 03:24:01 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 03:29:23 -0500 From: "Romascanu, Dan (Dan)" To: David Kessens Thread-Topic: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) Thread-Index: AQHN+SWQTPWrtoeiy0WHrtGLuJQcUZhWk3MA Date: Wed, 23 Jan 2013 08:29:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA068B1A@AZ-FFEXMB04.global.avaya.com> References: <20130119011641.GK11206@nsn.com> <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> <20130123045257.GP11206@nsn.com> In-Reply-To: <20130123045257.GP11206@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 23 Jan 2013 08:29:12 -0000 Hi David, If the next version is renamed according to the naming convention for a WG = document and the header reflects the obsolescence of RFC 6021 - no concern! Thanks and Regards, Dan > -----Original Message----- > From: David Kessens [mailto:david.kessens@nsn.com] > Sent: Wednesday, January 23, 2013 6:53 AM > To: Romascanu, Dan (Dan) > Cc: netmod@ietf.org > Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 > (20130204) >=20 >=20 > Dan, >=20 > On Sun, Jan 20, 2013 at 09:55:29AM +0000, Romascanu, Dan (Dan) wrote: > > > > Does this document obsolete RFC6021? The header says nothing about > this. >=20 > for completeness sake: yes >=20 > > Is this an official WG document? If so, why is it not named draft- > ietf-netmod-rfc6021bisp... or something similar? >=20 > We are jumping the gun a bit here: it is not really about a new > document, but putting the already agreed upon content it in a new > version of another already published document. >=20 > So yes, the Last Call is about getting it published and making it a wg > document at the same time. The last was implicit but I should have > called that out. >=20 > Having said this, it seems a new version will be necessary anyways and I > will be able to correct all this with better wording in a new Last Call > of a new and improved version. >=20 > I hope this helps, and let me know if you have any remaining concerns, >=20 > David Kessens > --- From david.kessens@nsn.com Wed Jan 23 11:11:59 2013 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 E5FE421F87B6 for ; Wed, 23 Jan 2013 11:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rSWCnbPl8Tyz for ; Wed, 23 Jan 2013 11:11:59 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A121F871C for ; Wed, 23 Jan 2013 11:11:58 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0NJBrYc019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jan 2013 20:11:53 +0100 Received: from localhost.localdomain ([10.138.50.176]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0NJBnpS011784; Wed, 23 Jan 2013 20:11:50 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id r0NJBnRN012444; Wed, 23 Jan 2013 11:11:49 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id r0NJBlIa012441; Wed, 23 Jan 2013 11:11:47 -0800 Date: Wed, 23 Jan 2013 11:11:47 -0800 From: David Kessens To: "Romascanu, Dan (Dan)" Message-ID: <20130123191147.GR11206@nsn.com> References: <20130119011641.GK11206@nsn.com> <9904FB1B0159DA42B0B887B7FA8119CA0650AC@AZ-FFEXMB04.global.avaya.com> <20130123045257.GP11206@nsn.com> <9904FB1B0159DA42B0B887B7FA8119CA068B1A@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA068B1A@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1896 X-purgate-ID: 151667::1358968313-00003C02-38013410/0-0/0-0 Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204) 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, 23 Jan 2013 19:12:00 -0000 Dan, Bert, On Wed, Jan 23, 2013 at 08:29:23AM +0000, Romascanu, Dan (Dan) wrote: > > If the next version is renamed according to the naming convention for a WG document and the header reflects the obsolescence of RFC 6021 - no concern! & On Wed, Jan 23, 2013 at 09:13:39AM +0100, Bert Wijnen (IETF) wrote: > IF you do a new revision and a new WGLC, then you might as well > rename the document to a wg document name (draft-ietf-netmod...) at > the same time. That is indeed part of the plan! David Kessens --- > > -----Original Message----- > > From: David Kessens [mailto:david.kessens@nsn.com] > > Sent: Wednesday, January 23, 2013 6:53 AM > > To: Romascanu, Dan (Dan) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 > > (20130204) > > > > > > Dan, > > > > On Sun, Jan 20, 2013 at 09:55:29AM +0000, Romascanu, Dan (Dan) wrote: > > > > > > Does this document obsolete RFC6021? The header says nothing about > > this. > > > > for completeness sake: yes > > > > > Is this an official WG document? If so, why is it not named draft- > > ietf-netmod-rfc6021bisp... or something similar? > > > > We are jumping the gun a bit here: it is not really about a new > > document, but putting the already agreed upon content it in a new > > version of another already published document. > > > > So yes, the Last Call is about getting it published and making it a wg > > document at the same time. The last was implicit but I should have > > called that out. > > > > Having said this, it seems a new version will be necessary anyways and I > > will be able to correct all this with better wording in a new Last Call > > of a new and improved version. > > > > I hope this helps, and let me know if you have any remaining concerns, > > > > David Kessens > > --- David Kessens --- From wwwrun@rfc-editor.org Thu Jan 24 04:59:41 2013 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 BB43A21F8A0C for ; Thu, 24 Jan 2013 04:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.271, 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 8l1SCxEW30nE for ; Thu, 24 Jan 2013 04:59:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 54E4B21F89EE for ; Thu, 24 Jan 2013 04:59:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 608EAB1E004; Thu, 24 Jan 2013 04:48:24 -0800 (PST) To: mbj@tail-f.com, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20130124124824.608EAB1E004@rfc-editor.org> Date: Thu, 24 Jan 2013 04:48:24 -0800 (PST) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3470) 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, 24 Jan 2013 12:59:41 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3470 -------------------------------------- Type: Technical Reported by: Ladislav Lhotka Section: 7.16.2 Original Text ------------- An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities. Corrected Text -------------- The derivation of identities has the following properties: o It is irreflexive, which means that an identity is not derived from itself. o It is transitive, which means that if identity B is derived from A and C is derived from B, then C is also derived from A. Notes ----- The desired properties of identity derivation are not clearly stated. The discussion in the NETMOD mailing led to a general agreement that identity derivation is supposed to be irreflexive and transitive. These two properties together also eliminate the possibility of a circular derivation. 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. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From andy@yumaworks.com Thu Jan 31 08:43:53 2013 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 5403321F84D7 for ; Thu, 31 Jan 2013 08:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 5PvcIUCqxa4T for ; Thu, 31 Jan 2013 08:43:52 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3064E21F8428 for ; Thu, 31 Jan 2013 08:43:52 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so1851294vbb.37 for ; Thu, 31 Jan 2013 08:43:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=/IJSbNPEOINgQ5rUHvfhkgBh5qK3ttCPEum6T3bdlW0=; b=gyktzXdKK1WbWIriuprRz6rcqbli7sMLQI3jAL+ex7T3KELOSliJtokmlghsfLU8Nw c6Bj69ly/QARXgtloJ6eyKn0eumKP5hkrPcemjrFgH9UrsnV9TWMtY4UPhQ6kFFrpc5R luKZ5cXvMjzU/6lydxPafEuQ9X3kbmYqDhrrgkDjYUvGR8UeKagk4Tc5MCLY3D7Pa3+o PfQpTMA6VAnR5stTK9uZ/lvNPMj4Mise0r5zmhJMn5AvyQIP8P5X/8/47DpLntVFj78m LICfvW2RC90MUKQyFk31HgVOIxTWUjfKr+xP43btjoI2iajrVlJmxD+UirItTGD+Kj1k TtTA== MIME-Version: 1.0 X-Received: by 10.220.239.73 with SMTP id kv9mr8596923vcb.50.1359650631501; Thu, 31 Jan 2013 08:43:51 -0800 (PST) Received: by 10.58.33.67 with HTTP; Thu, 31 Jan 2013 08:43:51 -0800 (PST) In-Reply-To: <50F03BA8.3000203@seguesoft.com> References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> Date: Thu, 31 Jan 2013 08:43:51 -0800 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: multipart/alternative; boundary=14dae9d25234e8c8ce04d498546a X-Gm-Message-State: ALoCoQlXDFmF0Orr4JdjAabB/qikH+/q9cBriJVI9TEQAtUlhTLuxLFaebDP5nogvYcdSGJnhana Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:43:53 -0000 --14dae9d25234e8c8ce04d498546a Content-Type: text/plain; charset=UTF-8 Hi, IMO, the best solution would be if the tool authors would write a short RFC defining the syntax and showing a few examples. Then all the RFCs with YANG tree diagrams can just add an informative reference instead of cut-and-pasting a couple sentences. Those of use who have used the libsmi tool for MIB tree diagrams may be used to all the symbols but there are many details that cannot be inferred from examination of 1 or 2 examples. E.g., some might see foo, foo? and wonder if foo* is also in the syntax, and if they mean the same thing as RelaxNG. Or see r/w, and wonder what are the other choices? r/c, r/o like SNMP? Now that I2RS WG appears to want to use YANG tree diagrams as well, it would help the standards process if there was actually a definition of a YANG tree diagram in an Informational RFC. Andy On Fri, Jan 11, 2013 at 8:19 AM, Xiang Li wrote: > Hi > > Looks good...I just have have a simple editorial comment. > This draft still does not contain a simple explanation on what these > "?", "*", etc. means in the various data module structure diagram: > > For example: > The data model for system identification has the following structure: > > +--rw system > +--rw contact? string > +--rw name? string > +--rw location? string > +--ro platform > ... > > I noticed that the recent ietf-interface and ietf-routing all contain some > texts clarifying > these symbols. I think ietf-system-module should add such texts too. > > For example, in ietf-interface yang: > > 3. Interfaces Data Model > > The data model in the module "ietf-interfaces" has the following > structure, where square brackets are used to enclose a list's keys, > "?" means that the leaf is optional, and "*" denotes a leaf-list: > > +--rw interfaces > +--rw interface [name] > +--rw name string > > > --Xiang Li > > > > > On 12/26/2012 2:45 PM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the NETCONF Data Modeling Language Working >> Group of the IETF. >> >> Title : YANG Data Model for System Management >> Author(s) : Andy Bierman >> Martin Bjorklund >> Filename : draft-ietf-netmod-system-mgmt-**04.txt >> Pages : 31 >> Date : 2012-12-26 >> >> 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-**04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?**url2=draft-ietf-netmod-system-**mgmt-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-**drafts/ >> >> ______________________________**_________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/**listinfo/netmod >> > > -- > -- > Xiang Li > Web: www.seguesoft.com > Voice: 1 (872) 216-2610 Cell 1 (217) 819-0942 > > ______________________________**_________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/**listinfo/netmod > --14dae9d25234e8c8ce04d498546a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

IMO, the best solution would be if the tool authors = would write
a short RFC defining the syntax and showing a few exa= mples.
Then all the RFCs with YANG tree diagrams can just add an<= /div>
informative reference instead of cut-and-pasting a couple sentences.

Those of use who have used the libsmi tool for MIB = tree diagrams
may be used to all the symbols but there are many d= etails that
cannot be inferred from examination of 1 or 2 examples.

=
E.g., some might see foo, foo? and wonder if foo* is also in the= syntax,
and if they mean the same thing as RelaxNG. Or see r/w, = and wonder what
are the other choices? r/c, r/o like SNMP?

No= w that I2RS WG appears to want to use YANG tree diagrams as well,
it would help the standards process if there was actually a definition
of a YANG tree diagram in an Informational RFC.


Andy


On Fri,= Jan 11, 2013 at 8:19 AM, Xiang Li <xiangli@seguesoft.com> wrote:
Hi

Looks good...I just have have a simple editorial comment.
This draft still does not contain a simple explanation on what these
=C2=A0"?", "*", etc. means in the various data module s= tructure diagram:

For example:
The data model for system identification has the following structure:

=C2=A0 =C2=A0 =C2=A0 +--rw system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw contact? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name? =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw location? =C2=A0 =C2=A0 =C2=A0 =C2= =A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro platform
...

I noticed that the recent ietf-interface and ietf-routing all contain some = texts clarifying
these symbols. I think =C2=A0ietf-system-module =C2=A0should add such texts= too.

For example, in ietf-interface yang:

3. =C2=A0Interfaces Data Model

=C2=A0 =C2=A0The data model in the module "ietf-interfaces" has t= he following
=C2=A0 =C2=A0structure, where square brackets are used to enclose a list= 9;s keys,
=C2=A0 =C2=A0"?" means that the leaf is optional, and "*&quo= t; denotes a leaf-list:

=C2=A0 =C2=A0 =C2=A0 +--rw interfaces
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw interface [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string


--Xiang Li




On 12/26/2012 2:45 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0 This draft is a work item of the NETCONF Data Modeling Language Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : YANG= Data Model for System Management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Andy Bierman =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Martin Bjorklund
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-netmod-system-mgmt-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 31 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2012-12-26

Abstract:
=C2=A0 =C2=A0 This document defines a YANG data model for the configuration= and
=C2=A0 =C2=A0 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-m= gmt-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -netmod-system-mgmt-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--
--
Xiang Li
Web: www.seguesoft.c= om
Voice: =C2=A0 1 (872) 216-2610 Cell 1 (217) 819-0942

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

--14dae9d25234e8c8ce04d498546a-- From mbj@tail-f.com Thu Jan 31 11:37:37 2013 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 E7FAB21F84D7 for ; Thu, 31 Jan 2013 11:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzmf3Bwf3hKV for ; Thu, 31 Jan 2013 11:37:37 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69121F84C9 for ; Thu, 31 Jan 2013 11:37:37 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C6641200CB0; Thu, 31 Jan 2013 20:37:34 +0100 (CET) Date: Thu, 31 Jan 2013 20:37:34 +0100 (CET) Message-Id: <20130131.203734.312880471.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:37:38 -0000 Hi, Andy Bierman wrote: > Hi, > > IMO, the best solution would be if the tool authors would write > a short RFC defining the syntax and showing a few examples. Since we don't want to wait for that document at this point, I suggest we do as the rest of the current documents, and include something like this: 1.2. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). /martin