From lhotka@cesnet.cz Thu Mar 3 10:05:28 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0115628C0FB for ; Thu, 3 Mar 2011 10:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjsbS-1Ctr05 for ; Thu, 3 Mar 2011 10:05:25 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id F39BF28C0EF for ; Thu, 3 Mar 2011 10:05:24 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 31F192CDE05D for ; Thu, 3 Mar 2011 19:06:31 +0100 (CET) From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 19:06:30 +0100 References: <20110303175652.1C84C3A6860@core3.amsl.com> To: netmod@ietf.org Message-Id: <2D5A14C0-9BE8-445A-B270-BFC895BB7865@cesnet.cz> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:05:28 -0000 Hi, this is an initial version of the core routing module: http://tools.ietf.org/html/draft-lhotka-netmod-routing-cfg-00 Please send comments to this mailing list. Lada Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 3, 2011 6:56:52 PM GMT+01:00 > To: lhotka@cesnet.cz > Subject: New Version Notification for = draft-lhotka-netmod-routing-cfg-00=20 >=20 >=20 > A new version of I-D, draft-lhotka-netmod-routing-cfg-00.txt has been = successfully submitted by Ladislav Lhotka and posted to the IETF = repository. >=20 > Filename: draft-lhotka-netmod-routing-cfg > Revision: 00 > Title: A YANG Data Model for Routing Configuration > Creation_date: 2011-03-03 > WG ID: Independent Submission > Number_of_pages: 31 >=20 > Abstract: > This document contains a specification of a core YANG data model for > IP routing configuration. It is expected that this module will serve > as a basis for further development of data models for individual > routing protocols and other related functions. The present data > model defines the building blocks for such configurations - routes > and routing tables, routing protocol instances, route filters and > route pipes. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Mon Mar 7 16:12:55 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A583A67A5 for ; Mon, 7 Mar 2011 16:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iudL4ZApil8e for ; Mon, 7 Mar 2011 16:12:52 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id 51EEC3A67A3 for ; Mon, 7 Mar 2011 16:12:52 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p280Brfn025285 for ; Mon, 7 Mar 2011 16:14:06 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id uw7qx83n8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 07 Mar 2011 16:14:05 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 7 Mar 2011 16:22:01 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 7 Mar 2011 16:14:04 -0800 From: Andy Bierman To: "netmod@ietf.org" Date: Mon, 7 Mar 2011 16:14:02 -0800 Thread-Topic: YANG ABNF bug Thread-Index: AcvdJbrJtk7ymHWOS++2pKMYgoN4Bg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B11AB91666F22D498EEC66410EB3D3C4F416D3DC6AHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-07_07:2011-03-08, 2011-03-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=6 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1103070139 Subject: [netmod] YANG ABNF bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 00:12:55 -0000 --_000_B11AB91666F22D498EEC66410EB3D3C4F416D3DC6AHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I found a bug in RFC 6020 ABNF... RFC 6020, sec. 9.12, para 3: A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref". Sec 12, ABNF Grammar , page 149: union-specification =3D 1*(type-stmt stmtsep) This ABNF allows all types, which is wrong: type-stmt =3D type-keyword sep identifier-ref-arg-str optsep (";" / "{" stmtsep type-body-stmts "}") type-body-stmts =3D numerical-restrictions / decimal64-specification / string-restrictions / enum-specification / leafref-specification / identityref-specification / instance-identifier-specification / bits-specification / union-specification I do not know how to express "builtin-type of identifier-ref-arg-str must resolve to a string other than 'leafref' or 'empty' and the leafref-specification is not allowed if the type-stmt is declared within a= union type-stmt. Andy --_000_B11AB91666F22D498EEC66410EB3D3C4F416D3DC6AHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I found a = bug in RFC 6020 ABNF…

 <= /o:p>

RFC 6020, se= c. 9.12, para 3:

 

   A member type can be of any built-in o= r derived type, except it MUST

   NOT be one of the built-in type= s "empty" or "leafref".

 

<= p class=3DMsoNormal>Sec 12, ABNF Grammar ,= page 149:

 

<= pre>   union-specification =3D 1*(type-stmt stmtsep)
 

This ABNF allows all t= ypes, which is wrong:

 <= /p>

    type-stmt      &nb=
sp;    =3D type-keyword sep identifier-ref-arg-str optsep
         &n=
bsp;            =
;   (";" /
    =
;            &n=
bsp;         "{" stmtsep<=
o:p>
         =
             &n=
bsp;       type-body-stmts
           &=
nbsp;           &nbs=
p;  "}")
 
&n=
bsp;  type-body-stmts     =3D numerical-restrictio=
ns /
        &=
nbsp;           &nbs=
p;    decimal64-specification /
 &=
nbsp;           &nbs=
p;           string-restr=
ictions /
       &n=
bsp;            =
;     enum-specification /
 &=
nbsp;            &nb=
sp;          leafref-spec=
ification /
       =
            &nb=
sp;     identityref-specification /
            &=
nbsp;            ins=
tance-identifier-specification /
   &nb=
sp;            =
         bits-specification /<=
/o:p>
          =
;            &n=
bsp;  union-specification
 
=

 

I do not kno= w how to express “builtin-type of identifier-ref-arg-str <= /p>

must resolve to a string other than ‘leafref&= #8217; or ‘empty’ and the

le= afref-specification is not allowed  if the type-stmt is declared withi= n a union type-stmt.

 

 

 = ;

Andy

 

= --_000_B11AB91666F22D498EEC66410EB3D3C4F416D3DC6AHQ1EXCH01corp_-- From mbj@tail-f.com Mon Mar 7 23:18:34 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511873A68F9 for ; Mon, 7 Mar 2011 23:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-IM5uwrsqDh for ; Mon, 7 Mar 2011 23:18:33 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 5BDB93A6832 for ; Mon, 7 Mar 2011 23:18:33 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2AAFE76C32E; Tue, 8 Mar 2011 08:19:46 +0100 (CET) Date: Tue, 08 Mar 2011 08:19:44 +0100 (CET) Message-Id: <20110308.081944.96076579472369458.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG ABNF bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:18:34 -0000 Hi, Andy Bierman wrote: > Hi, > > I found a bug in RFC 6020 ABNF... I don't agree that this a bug. There are many constructs that the ABNF allows that are not valid YANG. If a module passes the grammar check it is syntactically correct. This does not mean it is valid YANG. /martin From lhotka@cesnet.cz Tue Mar 8 00:42:18 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBF43A6904 for ; Tue, 8 Mar 2011 00:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4scaI7JrDqqO for ; Tue, 8 Mar 2011 00:42:17 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 138863A6922 for ; Tue, 8 Mar 2011 00:42:16 -0800 (PST) Received: from [IPv6:2001:718:1:6:215:60ff:fead:16dc] (unknown [IPv6:2001:718:1:6:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id DAFE52CDE05C for ; Tue, 8 Mar 2011 09:43:29 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20110308.081944.96076579472369458.mbj@tail-f.com> References: <20110308.081944.96076579472369458.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 08 Mar 2011 09:43:29 +0100 Message-ID: <1299573809.2203.8.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] YANG ABNF bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 08:42:18 -0000 On Út, 2011-03-08 at 08:19 +0100, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > Hi, > > > > I found a bug in RFC 6020 ABNF... > > I don't agree that this a bug. There are many constructs that the > ABNF allows that are not valid YANG. If a module passes the grammar > check it is syntactically correct. This does not mean it is valid > YANG. > This case could be corrected simply by defining the union type without using the generic productions, right? I would be in favor of making this change in 6020bis. Lada > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Mar 8 01:00:27 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8173A67B2 for ; Tue, 8 Mar 2011 01:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgwzzvbZF3mU for ; Tue, 8 Mar 2011 01:00:27 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 221103A67A7 for ; Tue, 8 Mar 2011 01:00:26 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1AD5E76C330; Tue, 8 Mar 2011 10:01:40 +0100 (CET) Date: Tue, 08 Mar 2011 10:01:38 +0100 (CET) Message-Id: <20110308.100138.677213307493018632.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1299573809.2203.8.camel@missotis> References: <20110308.081944.96076579472369458.mbj@tail-f.com> <1299573809.2203.8.camel@missotis> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] YANG ABNF bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:00:28 -0000 Ladislav Lhotka wrote: > On =DAt, 2011-03-08 at 08:19 +0100, Martin Bjorklund wrote: > > Hi, > > = > > Andy Bierman wrote: > > > Hi, > > > = > > > I found a bug in RFC 6020 ABNF... > > = > > I don't agree that this a bug. There are many constructs that the > > ABNF allows that are not valid YANG. If a module passes the gramma= r > > check it is syntactically correct. This does not mean it is valid > > YANG. > > = > = > This case could be corrected simply by defining the union type withou= t > using the generic productions, right? I don't think it is that easy. Here's an example of a valid snippet: type union { type 'int' + "32"; type 'str' + /* foo */ 'ing'; } and an invalid: type union { type int32 { length "10"; } type 'emp' + "ty"; } /martin From lhotka@cesnet.cz Tue Mar 8 09:22:02 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664A33A68F5 for ; Tue, 8 Mar 2011 09:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVIRAhNKEZcm for ; Tue, 8 Mar 2011 09:22:00 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 495A63A68C5 for ; Tue, 8 Mar 2011 09:21:59 -0800 (PST) Received: from [IPv6:2001:718:1:6:215:60ff:fead:16dc] (unknown [IPv6:2001:718:1:6:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id EC05F2CDE05E; Tue, 8 Mar 2011 18:23:13 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20110308.100138.677213307493018632.mbj@tail-f.com> References: <20110308.081944.96076579472369458.mbj@tail-f.com> <1299573809.2203.8.camel@missotis> <20110308.100138.677213307493018632.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 08 Mar 2011 18:23:12 +0100 Message-ID: <1299604992.2203.60.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG ABNF bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:22:02 -0000 On Út, 2011-03-08 at 10:01 +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > On Út, 2011-03-08 at 08:19 +0100, Martin Bjorklund wrote: > > > Hi, > > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > I found a bug in RFC 6020 ABNF... > > > > > > I don't agree that this a bug. There are many constructs that the > > > ABNF allows that are not valid YANG. If a module passes the grammar > > > check it is syntactically correct. This does not mean it is valid > > > YANG. > > > > > > > This case could be corrected simply by defining the union type without > > using the generic productions, right? > > I don't think it is that easy. Here's an example of a valid snippet: > > type union { > type 'int' + "32"; > type 'str' + /* foo */ 'ing'; > } > > and an invalid: > > type union { > type int32 { > length "10"; > } > type 'emp' + "ty"; > } > This is only a matter of interpretation of identifier-ref-arg-str, but I think the problem has to do with derived types: I first thought that "union-specification" could be changed like this: union-specification = 1*(type-stmt-union stmtsep) and then have the "type-stmt-union" production without "empty" and "leafref" types. But I guess the problem is more with the following example which cannot be easily excluded in the grammar: type union { type foo; ... } typedef foo { type empty; } This should be also forbidden, although the sentence that Andy cited doesn't seem to exclude this case because the member type is neither "empty" nor "leafref". So the text should probably be changed: OLD A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref". NEW A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref", or any type (transitively) derived from these two built-in types. Lada > > /martin > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Mar 14 15:06:55 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436163A6F61 for ; Mon, 14 Mar 2011 15:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjNjGdXZ8WdQ for ; Mon, 14 Mar 2011 15:06:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 159D23A6F5D for ; Mon, 14 Mar 2011 15:06:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B50FC0034 for ; Mon, 14 Mar 2011 23:08:17 +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 ua-LYQieok0z; Mon, 14 Mar 2011 23:08:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C16E1C0006; Mon, 14 Mar 2011 23:08:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9D32D16F4F60; Mon, 14 Mar 2011 23:08:04 +0100 (CET) Date: Mon, 14 Mar 2011 23:08:04 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110314220804.GA26712@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:06:55 -0000 Hi, here is an update of the SMIv2 to YANG translation document. Comments are more than welcome. /js ----- Forwarded message from IETF I-D Submission Tool ----- Date: Mon, 14 Mar 2011 14:59:09 -0700 From: IETF I-D Submission Tool To: j.schoenwaelder@jacobs-university.de Subject: New Version Notification for draft-schoenw-netmod-smi-yang-02 Message-ID: <20110314215909.699883A6BC2@core3.amsl.com> A new version of I-D, draft-schoenw-netmod-smi-yang-02.txt has been successfully submitted by Juergen Schoenwaelder and posted to the IETF repository. Filename: draft-schoenw-netmod-smi-yang Revision: 02 Title: Translation of SMIv2 MIB Modules to YANG Modules Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 31 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. The IETF Secretariat. ----- End forwarded message ----- -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Mar 16 00:14:15 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36A3A681A for ; Wed, 16 Mar 2011 00:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTho4O5XbFYm for ; Wed, 16 Mar 2011 00:14:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 785723A6818 for ; Wed, 16 Mar 2011 00:14:13 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DDF2C0020; Wed, 16 Mar 2011 08:15:39 +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 GwR4oca8XpFf; Wed, 16 Mar 2011 08:15:38 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA83C001E; Wed, 16 Mar 2011 08:15:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 16B8316FBE43; Wed, 16 Mar 2011 08:15:25 +0100 (CET) Date: Wed, 16 Mar 2011 08:15:25 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110316071525.GA2589@elstar.local> Mail-Followup-To: netmod@ietf.org, David Kessens MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] draft prague wg meeting agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 07:14:15 -0000 Hi, I have posted a first draft of the WG meeting agenda: http://www.ietf.org/proceedings/80/agenda/netmod.txt Please let us know of any additions or corrections. /js PS: If you check the official agenda, you will find that we have a one hour slot (Tuesday 17:10-18:10) while the agenda plans for 70 minutes. The reason is that we asked for a two hour slot but for some reason the secretariat only gave us a one hour slot but told us that we can overrun the session. Due to the social event on Tuesday evening (start at 19:00), we like to make sure we are done by 18:30. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From B.Hedstrom@CableLabs.com Mon Mar 21 10:13:50 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C273A68B3 for ; Mon, 21 Mar 2011 10:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLsQoVpOuhHM for ; Mon, 21 Mar 2011 10:13:49 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 764333A68AD for ; Mon, 21 Mar 2011 10:13:49 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p2LHFLlh021903 for ; Mon, 21 Mar 2011 11:15:22 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 21 Mar 2011 11:15:21 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 21 Mar 2011 11:15:21 -0600 From: Brian Hedstrom To: "netmod@ietf.org" Date: Mon, 21 Mar 2011 11:15:19 -0600 Thread-Topic: Comments on draft-bjorklund-netmod-interfaces-cfg-00 Thread-Index: AQHL5+gyF3izOi1ssEimk2HQ+xF4cw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D2E98D030@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D2E98D030srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:13:50 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D2E98D030srvxchg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Netmod Working Group: I have some review comments on the draft: http://www.ietf.org/id/draft-bjorklund-netmod-interfaces-cfg-00.txt 1. ifLinkUpDownTrapEnable should be added into the config module. 2. ifAlias should be added into the config module, but perhaps not made man= datory 3. Is there any value in adding ifPromiscuousMode as an optional leaf for s= ome implementations? 4. The Security Considerations section should be populated or listed as no = security impacts. 5. For Appendix A could you also include an example YANG Data Tree instance= showing the NETCONF YANG payload? 6. Should this module have any mapping into the ENTITY-MIB (entPhysicalInde= x)? 7. Can implementations still use the IANI ifTypes with this Module for the = type leaf? 8. Could this Module be used to make run time Control (actionable) changes?= If so, what about admin-status supporting the "testing" enumeration? Thanks, Brian Hedstrom CableLabs --_000_76AC5FEF83F1E64491446437EA81A61F7D2E98D030srvxchg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Netmod = Working Group:
I have some review commen= ts on the draft:
 
1. ifLinkUpDownTrapEnable s= hould be added into the config module.
2. ifAlias should be added = into the config module, but perhaps not made mandatory
3. Is there any value in ad= ding ifPromiscuousMode as an optional leaf for some implementations?=
4. The Security Considerati= ons section should be populated or listed as no security impacts.
5. For Appendix A could you= also include an example YANG Data Tree instance showing the NETCONF YANG p= ayload?
6. Should this module have = any mapping into the ENTITY-MIB (entPhysicalIndex)?
7. Can implementations stil= l use the IANI ifTypes with this Module for the type leaf?
8. Could this Module be use= d to make run time Control (actionable) changes?  If so, what abo= ut admin-status
supporting the "testin= g" enumeration?
 
 
Thanks,
Brian Hedstrom
CableLabs
 
--_000_76AC5FEF83F1E64491446437EA81A61F7D2E98D030srvxchg_-- From mbj@tail-f.com Fri Mar 25 04:20:12 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521383A6804 for ; Fri, 25 Mar 2011 04:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp6OwcmKtagX for ; Fri, 25 Mar 2011 04:20:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 28A6F3A67ED for ; Fri, 25 Mar 2011 04:20:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 804F6616002; Fri, 25 Mar 2011 12:21:44 +0100 (CET) Date: Fri, 25 Mar 2011 12:21:44 +0100 (CET) Message-Id: <20110325.122144.1104483338340981664.mbj@tail-f.com> To: B.Hedstrom@CableLabs.com From: Martin Bjorklund In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D2E98D030@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F7D2E98D030@srvxchg> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 11:20:12 -0000 Hi Brian, Thank you for your comments. See answers inline. Brian Hedstrom wrote: > Netmod Working Group: > I have some review comments on the draft: > http://www.ietf.org/id/draft-bjorklund-netmod-interfaces-cfg-00.txt > > 1. ifLinkUpDownTrapEnable should be added into the config module. Yes, this is probably a good idea. > 2. ifAlias should be added into the config module, but perhaps not > made mandatory Why do you think this object is needed? Why isn't the name enough? It seems some vendors map this object to a "description" field in their CLI. But that isn't really the intention of this object. > 3. Is there any value in adding ifPromiscuousMode as an optional > leaf for some implementations? I'm not sure if this object is intended to be config, i.e. if the value of this object is stored in non-volatile memory. > 4. The Security Considerations section should be populated or listed > as no security impacts. Yes, this section will be written, if the WG adopts this document. > 5. For Appendix A could you also include an example YANG Data Tree > instance showing the NETCONF YANG payload? Ok. > 6. Should this module have any mapping into the ENTITY-MIB > (entPhysicalIndex)? I don't think so. In the ENTITY-MIB, you can have pointer to interfaces. I think that is sufficient for now. (Maybe we will see a YANG module for entities in the future). > 7. Can implementations still use the IANI ifTypes with this Module > for the type leaf? No. This module does not use a centrally administered enumeration for type identification. Instead, it uses YANG identities. It is expected that interface type specific modules define their own identities. Maybe there is a need for identities that don't have an associated type specific module? Maybe we could define an 'other' identity, and also add a leaf 'iana-if-type' for such interfaces. > 8. Could this Module be used to make run time Control (actionable) > changes? If so, what about admin-status > supporting the "testing" enumeration? This is currently not in scope, but it is up to the WG to decide. Do you think that this would be useful? Are you seeing that the ifAdminStatus value 'testing' is being used? /martin From reid@snmp.com Fri Mar 25 14:09:21 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D1828C0CE for ; Fri, 25 Mar 2011 14:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ySZwevOpbPp for ; Fri, 25 Mar 2011 14:09:20 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 14E0A3A679C for ; Fri, 25 Mar 2011 14:09:19 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA21788 for ; Fri, 25 Mar 2011 17:10:50 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA05270 for ; Fri, 25 Mar 2011 17:10:46 -0400 (EDT) Message-Id: <201103252110.RAA05270@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Mon, 14 Mar 2011 23:08:04 +0100. <20110314220804.GA26712@elstar.local> Date: Fri, 25 Mar 2011 17:10:41 -0400 Sender: reid@snmp.com Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 21:09:21 -0000 > here is an update of the SMIv2 to YANG translation document. Comments > are more than welcome. > > /js I have a few comments and questions on the three TODO: items and a few other items. Overall, I think this is a good draft which the working group should standardize. We plan to implement it (We have a partial implementation from a long time ago that we will update to match the draft). Section 6.1 DISPLAY-HINTS TODO item: I think the current text is sufficient. I would also be OK with just not translating it at all. If someone wants to define a more complete translation algorithm, I would have no objection. But I don't really think it is worth the effort. I would like to see an additional sentence saying that the display-hint extension from ietf-yang-smiv2 should be used. In fact, I would like to see that sentence in the other places where it makes sense to use extensions from that module. Section 7.1 TODO: Can someone explain the issue here. I didn't understand the problem. Section 9.2 TODO, identities: I think the OBJECT-IDENTITY macro should be mapped to a yang identity rather than a container (and generate the appropriate base). Section 2: Using DISPLAY-HINT to determine whether the yang type is string or binary is problematic because SMIv2 revision rules allow DISPLAY-HINT to be added, but that would change the yang type, which is not a legal revision. I hate to always use binary since most OCTET STRINGS in MIBs are text strings, so I hope we can come up with a better solution. Section 4 states "Since SMIv2 module names are unique...", but SMIv2 module names are not guaranteed to be unique. Maybe it's OK to make this assumption, otherwise, I don't know how we'll get unique namespaces. Section 6.2: pattern "\p{IsBasicLatin}{0,255}". Should this be "\\p{IsBasicLatin}{0,255}"? In notifications, why are the non-index objects not of type leafref? -David Reid From spakes@snmp.com Fri Mar 25 17:26:06 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6823A6847 for ; Fri, 25 Mar 2011 17:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3FHo-9x-EUn for ; Fri, 25 Mar 2011 17:26:05 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id C3A5C3A67DA for ; Fri, 25 Mar 2011 17:26:04 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id UAA02565; Fri, 25 Mar 2011 20:27:34 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id UAA07598; Fri, 25 Mar 2011 20:27:33 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 25 Mar 2011 20:27:32 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110314220804.GA26712@elstar.local> Message-ID: References: <20110314220804.GA26712@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 00:26:07 -0000 Juergen, I have a few comments on the SMIv2 to YANG translation document. Good job, by the way! [1] On page 6, I was confused by the statement: "on average, much shorter prefxies are generated." Are you planning to grow the list in Table 2 with all of the pulished RFCs containing MIB modules? [2] In Table 3 on page 7, SNMPv2-TC is supposed to be an ignored IMPORTS, but your example in section 4.1 on page 8 does not ignore it. [3] Typo in section 4.1 on page 8: "(consisting of two token and this no further abbrevation)." .........................s [4] Typo in section 8.1 on page 14: "Embedded clauses are generates as described in Section 2." ..............................d [5] Regarding the mapping of SMIv2 types to YANG types, I have a suggestion for OCTET STRING. According to RFC 2579, page 24, "(4) A DISPLAY-HINTS clause may be added or updated." In practice, I believe there are a lot of OCTET STRING objects that are intended to contain only printable strings, but the MIB document does not [yet] provide a DISPLAY-HINT. For example, RFC 1213 defines a DisplayString on page 12 as: DisplayString ::= OCTET STRING Then, sysDescr is defined with SYNTAX DisplayString on page 13: sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory Later, RFC 3418 (SNMPv2-MIB) added the DISPLAY-HINTS to sysDescr by importing the definition of DisplayString from SNMPv2-TC (RFC 2579). I propose that an OCTET STRING object that does not have a DISPLAY-HINT should convert to a union of string and binary so a NETCONF server has some flexibility on how these are handled. Perhaps in this situation, a smart NETCONF server should able to discriminate the enclosed value by adding a double-quote character to the beginning and end; e.g., typedef OctetString { type union { type string { pattern "\".*\"" } type binary; } } [6] Similar to OCTET STRING, I have a concern about the conversion of an enumerated INTEGER to a YANG enumeration. A leaf of type enumeration can not be extended, but new enumerations are sometimes added to MIBs. The most recognizable example is ifType: http://www.iana.org/assignments/ianaiftype-mib As the mapping is stated today, the definition of ifType in RFC 1213 would be converted to this: leaf ifType { type enumeration { enum other { value 1; } enum regular1822 { value 2; } enum hdh1822 { value 3; } enum ddn-x25 { value 4; } enum rfc877-x25 { value 5; } enum ethernet-csmacd { value 6; } enum iso88023-csmacd { value 7; } enum iso88024-tokenBus { value 8; } enum iso88025-tokenRing { value 9; } enum iso88026-man { value 10; } enum starLan { value 11; } enum proteon-10Mbit { value 12; } enum proteon-80Mbit { value 13; } enum hyperchannel { value 14; } enum fddi { value 15; } enum lapb { value 16; } enum sdlc { value 17; } enum ds1 { value 18; } enum e1 { value 19; } enum basicISDN { value 20; } enum primaryISDN { value 21; } enum propPointToPointSerial { value 22; } enum ppp { value 23; } enum softwareLoopback { value 24; } enum eon { value 25; } enum ethernet-3Mbit { value 26; } enum nsip { value 27; } enum slip { value 28; } enum ultra { value 29; } enum ds3 { value 30; } enum sip { value 31; } enum frame-relay { value 32; } } config false; description "The type of interface, distinguished according to the physical/link protocol(s) immediately `below' the network layer in the protocol stack."; } It would not be legal to add more enumerations; e.g., rs232(33). The page http://www.yang-central.org/twiki/bin/view/Main/YangFAQ#whenempty suggests a technique of using a choice of type empty instead of enumeration, and then it is possible to use an augment to add enumerations. But I don't really like this approach. I would rather see the enumerations remain enumerations. If ifType were instead converted to a union of enumeration and int32, then it would be possible to convey any new enumerated values as their numeric equivalents. leaf ifType { type union { type enumeration { enum other { value 1; } enum regular1822 { value 2; } enum hdh1822 { value 3; } enum ddn-x25 { value 4; } enum rfc877-x25 { value 5; } enum ethernet-csmacd { value 6; } enum iso88023-csmacd { value 7; } enum iso88024-tokenBus { value 8; } enum iso88025-tokenRing { value 9; } enum iso88026-man { value 10; } enum starLan { value 11; } enum proteon-10Mbit { value 12; } enum proteon-80Mbit { value 13; } enum hyperchannel { value 14; } enum fddi { value 15; } enum lapb { value 16; } enum sdlc { value 17; } enum ds1 { value 18; } enum e1 { value 19; } enum basicISDN { value 20; } enum primaryISDN { value 21; } enum propPointToPointSerial { value 22; } enum ppp { value 23; } enum softwareLoopback { value 24; } enum eon { value 25; } enum ethernet-3Mbit { value 26; } enum nsip { value 27; } enum slip { value 28; } enum ultra { value 29; } enum ds3 { value 30; } enum sip { value 31; } enum frame-relay { value 32; } } config false; description "The type of interface, distinguished according to the physical/link protocol(s) immediately `below' the network layer in the protocol stack."; } type int32; } So, the encoding for any of the original enumerations would be as ethernet-csmacd and for any new enumerations it would be as: 33 MIB documents that never extend their enumerations would not be affected by the switch to a union conversion. [7] I have concerns about YANG-centric applications that will inevitably be created in the future that need to access SNMP agents in deployed devicess as a source of raw data. My main concern is that YANG documents converted from MIB documents won't necessarily have all of the necessary information. It disturbs me that a lot of information from the original MIB document is lost when it is converted to YANG; e.g., in several places: "The SMIv2 ... clause is ignored." The YANG Language Extension Definition provides the means for information that would otherwise be lost during the conversion to be preserved in the resulting YANG document. I suggest that more extensions should be added to section 11 to preserve even more of the MIB information; e.g., UNITS, the original SYNTAX of an object (so the application can know if a string was converted from a DisplayString or UTF8String, for example), etc. Section 11 counts for nothing, though, if the use of extensions is optional. I would like to propose that every occurrance of "The SMIv2 ... clause is ignored" in this draft should be changed in the next draft to "The SMIv2 ... clause MUST be converted to extension ... as described in Section 11." This requirement to generate the extensions in the resulting YANG document in no way impacts YANG compilers that care nothing about SNMP, since "unknown-statement MAY be ignored by the compiler." (RFC 6020, page 38) -dss On Mon, 14 Mar 2011, Juergen Schoenwaelder wrote: > Hi, > > here is an update of the SMIv2 to YANG translation document. Comments > are more than welcome. > > /js > > ----- Forwarded message from IETF I-D Submission Tool ----- > > Date: Mon, 14 Mar 2011 14:59:09 -0700 > From: IETF I-D Submission Tool > To: j.schoenwaelder@jacobs-university.de > Subject: New Version Notification for draft-schoenw-netmod-smi-yang-02 > Message-ID: <20110314215909.699883A6BC2@core3.amsl.com> > > > A new version of I-D, draft-schoenw-netmod-smi-yang-02.txt has been successfully submitted by Juergen Schoenwaelder and posted to the IETF repository. > > Filename: draft-schoenw-netmod-smi-yang > Revision: 02 > Title: Translation of SMIv2 MIB Modules to YANG Modules > Creation_date: 2011-03-14 > WG ID: Independent Submission > Number_of_pages: 31 > > Abstract: > YANG is a data modeling language used to model configuration and > state data manipulated by the NETCONF protocol, NETCONF remote > procedure calls, and NETCONF notifications. The Structure of > Management Information (SMIv2) defines fundamental data types, an > object model, and the rules for writing and revising MIB modules for > use with the SNMP protocol. This document defines a translation of > SMIv2 MIB modules into YANG modules, enabling read-only access to > data objects defined in SMIv2 MIB modules via NETCONF. > > > The IETF Secretariat. > > > > ----- End forwarded message ----- > > -- > 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 > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Mon Mar 28 03:26:45 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1903A68D2 for ; Mon, 28 Mar 2011 03:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fikuh1qEaugh for ; Mon, 28 Mar 2011 03:26:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 350633A69CA for ; Mon, 28 Mar 2011 03:26:43 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45C82C0014; Mon, 28 Mar 2011 12:28:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r7u53YXLn3Kd; Mon, 28 Mar 2011 12:28:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6660DC0002; Mon, 28 Mar 2011 12:28:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB6061749A22; Mon, 28 Mar 2011 12:28:13 +0200 (CEST) Date: Mon, 28 Mar 2011 12:28:13 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110328102812.GA24256@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20110314220804.GA26712@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:26:45 -0000 On Fri, Mar 25, 2011 at 08:27:32PM -0400, David Spakes wrote: > Juergen, > > I have a few comments on the SMIv2 to YANG translation document. > Good job, by the way! Thanks for the review, this is highly appreciated. > [1] On page 6, I was confused by the statement: "on average, much shorter > prefxies are generated." Are you planning to grow the list in Table 2 > with all of the pulished RFCs containing MIB modules? No, table 2 is supposed to be a fixed list of well known special prefixes. It is built statically into my implementation. > [2] In Table 3 on page 7, SNMPv2-TC is supposed to be an ignored IMPORTS, > but your example in section 4.1 on page 8 does not ignore it. Table 3 says that the import of 'TEXTUAL-CONVENTION' from the 'SNMPv2-TC' is ignored. It does that say anything about say RowStatus. > [3] Typo in section 4.1 on page 8: > "(consisting of two token and this no further abbrevation)." > .........................s fixed > [4] Typo in section 8.1 on page 14: > "Embedded clauses are generates as described in Section 2." > ..............................d fixed > [5] Regarding the mapping of SMIv2 types to YANG types, I have a suggestion > for OCTET STRING. According to RFC 2579, page 24, "(4) A DISPLAY-HINTS > clause may be added or updated." In practice, I believe there are a lot > of OCTET STRING objects that are intended to contain only printable > strings, but the MIB document does not [yet] provide a DISPLAY-HINT. > For example, RFC 1213 defines a DisplayString on page 12 as: > > DisplayString ::= > OCTET STRING > > Then, sysDescr is defined with SYNTAX DisplayString on page 13: > > sysDescr OBJECT-TYPE > SYNTAX DisplayString (SIZE (0..255)) > ACCESS read-only > STATUS mandatory > > Later, RFC 3418 (SNMPv2-MIB) added the DISPLAY-HINTS to sysDescr by > importing the definition of DisplayString from SNMPv2-TC (RFC 2579). > > I propose that an OCTET STRING object that does not have a DISPLAY-HINT > should convert to a union of string and binary so a NETCONF server has > some flexibility on how these are handled. Perhaps in this situation, > a smart NETCONF server should able to discriminate the enclosed value > by adding a double-quote character to the beginning and end; e.g., > > typedef OctetString { > type union { > type string { > pattern "\".*\"" > } > type binary; > } > } How we distinguish textual strings from binary strings is now an open issue. The union approach, though a nice idea, can cause ambiguities unless we introduce something that reliably distinguishes string values from binary values (represented in base64 encoding). The quotes serve that purpose, but they likely also get into the way since we start to mess around with the value contained in an XML element. This requires more discussion I think. > [6] Similar to OCTET STRING, I have a concern about the conversion of > an enumerated INTEGER to a YANG enumeration. A leaf of type enumeration > can not be extended, but new enumerations are sometimes added to MIBs. What makes you believe enums can not be extended in YANG? RFC 6020 says: o An "enumeration" type may have new enums added, provided the old enums's values do not change. That said, SMIv2 allows to change the label associated with an enumerated INTEGER: (1) A SYNTAX clause containing an enumerated INTEGER may have new enumerations added or existing labels changed. Similarly, named bits may be added or existing labels changed for the BITS construct. YANG does not seem to allow such changes. > The most recognizable example is ifType: > > http://www.iana.org/assignments/ianaiftype-mib > > As the mapping is stated today, the definition of ifType in RFC 1213 would > be converted to this: > > leaf ifType { > type enumeration { > enum other { value 1; } > enum regular1822 { value 2; } > enum hdh1822 { value 3; } > enum ddn-x25 { value 4; } > enum rfc877-x25 { value 5; } > enum ethernet-csmacd { value 6; } > enum iso88023-csmacd { value 7; } > enum iso88024-tokenBus { value 8; } > enum iso88025-tokenRing { value 9; } > enum iso88026-man { value 10; } > enum starLan { value 11; } > enum proteon-10Mbit { value 12; } > enum proteon-80Mbit { value 13; } > enum hyperchannel { value 14; } > enum fddi { value 15; } > enum lapb { value 16; } > enum sdlc { value 17; } > enum ds1 { value 18; } > enum e1 { value 19; } > enum basicISDN { value 20; } > enum primaryISDN { value 21; } > enum propPointToPointSerial { value 22; } > enum ppp { value 23; } > enum softwareLoopback { value 24; } > enum eon { value 25; } > enum ethernet-3Mbit { value 26; } > enum nsip { value 27; } > enum slip { value 28; } > enum ultra { value 29; } > enum ds3 { value 30; } > enum sip { value 31; } > enum frame-relay { value 32; } > } > config false; > description > "The type of interface, distinguished according to > the physical/link protocol(s) immediately `below' > the network layer in the protocol stack."; > } > > It would not be legal to add more enumerations; e.g., rs232(33). > > The page http://www.yang-central.org/twiki/bin/view/Main/YangFAQ#whenempty > suggests a technique of using a choice of type empty instead of enumeration, > and then it is possible to use an augment to add enumerations. But I don't > really like this approach. I would rather see the enumerations remain > enumerations. > > If ifType were instead converted to a union of enumeration and int32, > then it would be possible to convey any new enumerated values as their > numeric equivalents. > > leaf ifType { > type union { > type enumeration { > enum other { value 1; } > enum regular1822 { value 2; } > enum hdh1822 { value 3; } > enum ddn-x25 { value 4; } > enum rfc877-x25 { value 5; } > enum ethernet-csmacd { value 6; } > enum iso88023-csmacd { value 7; } > enum iso88024-tokenBus { value 8; } > enum iso88025-tokenRing { value 9; } > enum iso88026-man { value 10; } > enum starLan { value 11; } > enum proteon-10Mbit { value 12; } > enum proteon-80Mbit { value 13; } > enum hyperchannel { value 14; } > enum fddi { value 15; } > enum lapb { value 16; } > enum sdlc { value 17; } > enum ds1 { value 18; } > enum e1 { value 19; } > enum basicISDN { value 20; } > enum primaryISDN { value 21; } > enum propPointToPointSerial { value 22; } > enum ppp { value 23; } > enum softwareLoopback { value 24; } > enum eon { value 25; } > enum ethernet-3Mbit { value 26; } > enum nsip { value 27; } > enum slip { value 28; } > enum ultra { value 29; } > enum ds3 { value 30; } > enum sip { value 31; } > enum frame-relay { value 32; } > } > config false; > description > "The type of interface, distinguished according to > the physical/link protocol(s) immediately `below' > the network layer in the protocol stack."; > } > type int32; > } > > So, the encoding for any of the original enumerations would be as > > ethernet-csmacd > > and for any new enumerations it would be as: > > 33 > > MIB documents that never extend their enumerations would not be affected > by the switch to a union conversion. See above, I think adding enumerations is not a problem. The problem I see is that SMIv2 allows to change labels. > [7] I have concerns about YANG-centric applications that will inevitably > be created in the future that need to access SNMP agents in deployed > devicess as a source of raw data. My main concern is that YANG > documents converted from MIB documents won't necessarily have all of > the necessary information. It disturbs me that a lot of information > from the original MIB document is lost when it is converted to YANG; > e.g., in several places: > > "The SMIv2 ... clause is ignored." > > The YANG Language Extension Definition provides the means for information > that would otherwise be lost during the conversion to be preserved in > the resulting YANG document. I suggest that more extensions should be > added to section 11 to preserve even more of the MIB information; > e.g., UNITS, the original SYNTAX of an object (so the application can > know if a string was converted from a DisplayString or UTF8String, for > example), etc. The UNITS clauses are translated to YANG units statements (perhaps I am missing that somewhere) so there is nothing lost. A DisplayString SYNTAX is translated into a type statement using snmpv2-tc:DisplayString so nothing is lost here either. > Section 11 counts for nothing, though, if the use of extensions is optional. > I would like to propose that every occurrance of > > "The SMIv2 ... clause is ignored" > > in this draft should be changed in the next draft to > > "The SMIv2 ... clause MUST be converted to extension ... as described > in Section 11." > > This requirement to generate the extensions in the resulting YANG document > in no way impacts YANG compilers that care nothing about SNMP, since > "unknown-statement MAY be ignored by the compiler." (RFC 6020, page 38) Whether the generation of these extensions statements is a MUST generate or a SHOULD generate needs to be discussed. I can go either way. In any case, I agree that the "is ignored" text needs to be rewritten. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 28 03:26:55 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0133A68D5 for ; Mon, 28 Mar 2011 03:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+J8a-VTbA8T for ; Mon, 28 Mar 2011 03:26:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3D8CA3A6838 for ; Mon, 28 Mar 2011 03:26:50 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D31CC0015; Mon, 28 Mar 2011 12:28:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gaeUs642x2RR; Mon, 28 Mar 2011 12:28:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE9CEC0002; Mon, 28 Mar 2011 12:28:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 26C1B1749A46; Mon, 28 Mar 2011 12:28:22 +0200 (CEST) Date: Mon, 28 Mar 2011 12:28:22 +0200 From: Juergen Schoenwaelder To: David Reid Message-ID: <20110328102822.GB24256@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20110314220804.GA26712@elstar.local> <201103252110.RAA05270@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103252110.RAA05270@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:26:55 -0000 On Fri, Mar 25, 2011 at 05:10:41PM -0400, David Reid wrote: > > here is an update of the SMIv2 to YANG translation document. Comments > > are more than welcome. > > > > /js > > I have a few comments and questions on the three TODO: items and a few other > items. Overall, I think this is a good draft which the working group should > standardize. We plan to implement it (We have a partial implementation from a > long time ago that we will update to match the draft). Thanks David for the review. > Section 6.1 DISPLAY-HINTS TODO item: I think the current text is > sufficient. I would also be OK with just not translating it at all. > If someone wants to define a more complete translation algorithm, I > would have no objection. But I don't really think it is worth the effort. > I would like to see an additional sentence saying that the display-hint > extension from ietf-yang-smiv2 should be used. In fact, I would like to > see that sentence in the other places where it makes sense to use > extensions from that module. OK > Section 7.1 TODO: Can someone explain the issue here. I didn't understand > the problem. In SMIv2, this is perfectly legal: foo OBJECT IDENTIFIER ::= { some 1 } bar OBJECT IDENTIFIER ::= { some 1 } In other words, you can have multiple descriptors for a single OID. If you generate a nested container structure in YANG, which of the multiple descriptors do you choose? Note that additional descriptors can be added and the order of appearance can change as well when a module is revised. > Section 9.2 TODO, identities: I think the OBJECT-IDENTITY macro should be > mapped to a yang identity rather than a container (and generate the > appropriate base). Even though wired, you can do foo OBJECT-IDENTITY STATUS current DESCRIPTION "" ::= { some 1 } bar OBJECT-TYPE -- stuff removed ::= { foo 1 } and hence the container may be needed if we want to recreate the hierarchical structure in YANG (but see above). > Section 2: Using DISPLAY-HINT to determine whether the yang type is string > or binary is problematic because SMIv2 revision rules allow DISPLAY-HINT to > be added, but that would change the yang type, which is not a legal revision. > I hate to always use binary since most OCTET STRINGS in MIBs are text strings, > so I hope we can come up with a better solution. Good catch, bad news. I agree that relying on DISPLAY-HINT is broken, not sure what a better solution could be. > Section 4 states "Since SMIv2 module names are unique...", but SMIv2 module > names are not guaranteed to be unique. Maybe it's OK to make this assumption, > otherwise, I don't know how we'll get unique namespaces. RFC 2478 says: The names of all standard information modules must be unique (but different versions of the same information module should have the same name). Developers of enterprise information modules are encouraged to choose names for their information modules that will have a low probability of colliding with standard or other enterprise information modules. My understanding here is that modules names really must be unique because SMIv2 imports simply do not work if module names are not unique. However, there is no registry to enforce that module names are unique and hence this encouraging text to choose module names with low collision probability. In other words, an SMIv2 parser (at least the once I have seen) already makes the assumption that module names are unique. > Section 6.2: pattern "\p{IsBasicLatin}{0,255}". Should this be > "\\p{IsBasicLatin}{0,255}"? What makes you believe there should be two slashes? > In notifications, why are the non-index objects not of type leafref? I have to look at this. Perhaps this is simply dating back from the times where leafref was a keyref... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Mon Mar 28 05:30:46 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC3F3A67FB for ; Mon, 28 Mar 2011 05:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A0c90QkYAu5 for ; Mon, 28 Mar 2011 05:30:44 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by core3.amsl.com (Postfix) with ESMTP id E4FBE3A680B for ; Mon, 28 Mar 2011 05:30:42 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2SCWJfN022839 for ; Mon, 28 Mar 2011 08:32:19 -0400 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.71.147] ([130.129.71.147:56536] helo=[130.129.71.147]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 68/5B-25639-3DF709D4; Mon, 28 Mar 2011 08:32:19 -0400 Message-ID: <4D907FD2.2060602@andybierman.com> Date: Mon, 28 Mar 2011 05:32:18 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: netmod@ietf.org References: <20110314220804.GA26712@elstar.local> <201103252110.RAA05270@adminfs.snmp.com> <20110328102822.GB24256@elstar.local> In-Reply-To: <20110328102822.GB24256@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:30:46 -0000 On 03/28/2011 03:28 AM, Juergen Schoenwaelder wrote: > On Fri, Mar 25, 2011 at 05:10:41PM -0400, David Reid wrote: ... >> In notifications, why are the non-index objects not of type leafref? > > I have to look at this. Perhaps this is simply dating back from the > times where leafref was a keyref... > If the notification varbind identifies an OBJECT-TYPE macro that is MAX-ACCESS accessible-for-notify, then the YANG leaf will be inline within the notification. What if the varbind is MAX-ACCESS not-accessible (INDEX clause)? Then is a leafref used or inline? My guess: leafref since keys are accessible in YANG. sec. 9, bullet 1: typo: The name of this container is the name of the notification and the name of the current concatenated by a hyphen. name of the current object, concatenated ... comment: What if the OBJECTS clause contains objects that have the same descriptor but from different modules (FOO-MIB.x and BAR-MIB.x)? Then you have container notif-x and container notif-x as siblings which is illegal in YANG. > /js > Andy From david.kessens@nsn.com Mon Mar 28 06:24:35 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A870F3A68BC for ; Mon, 28 Mar 2011 06:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTAkv-qU-Nml for ; Mon, 28 Mar 2011 06:24:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8F2FF3A67E4 for ; Mon, 28 Mar 2011 06:24:34 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2SDQAhl015905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Mar 2011 15:26:10 +0200 Received: from localhost.localdomain ([10.138.48.158]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2SDQ9Tv014312 for ; Mon, 28 Mar 2011 15:26:10 +0200 Received: from localhost.localdomain (X1 [127.0.0.1]) by localhost.localdomain (8.14.4/8.14.4) with ESMTP id p2SDQ8e9014178 for ; Mon, 28 Mar 2011 06:26:08 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.4/8.14.4/Submit) id p2SDQ7JF014176 for netmod@ietf.org; Mon, 28 Mar 2011 06:26:07 -0700 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Mon, 28 Mar 2011 06:26:07 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20110328132607.GE11935@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) Subject: [netmod] Scribes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:24:35 -0000 As mentioned earlier, we will have a rather short meeting slot this IETF. In order to spend the minimum of time on administrative matters, we would like to already ask for scribes and jabber scribes during our meeting. David Kessens --- From reid@snmp.com Mon Mar 28 06:32:08 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BD23A6910 for ; Mon, 28 Mar 2011 06:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqw2FXhNLbzA for ; Mon, 28 Mar 2011 06:32:08 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id C2D5F3A68A2 for ; Mon, 28 Mar 2011 06:32:07 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA03350; Mon, 28 Mar 2011 09:33:44 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA17382; Mon, 28 Mar 2011 09:33:44 -0400 (EDT) Message-Id: <201103281333.JAA17382@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Mon, 28 Mar 2011 12:28:22 +0200. <20110328102822.GB24256@elstar.local> Date: Mon, 28 Mar 2011 09:33:44 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:32:08 -0000 > > Section 6.2: pattern "\p{IsBasicLatin}{0,255}". Should this be > > "\\p{IsBasicLatin}{0,255}"? > > What makes you believe there should be two slashes? I thought double-quoted strings in yang required a backslash to be represented as \\. -David Reid From mehmet.ersue@nsn.com Mon Mar 28 06:37:35 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF723A693A for ; Mon, 28 Mar 2011 06:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZLQX2E6E5I7 for ; Mon, 28 Mar 2011 06:37:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id DD2193A6920 for ; Mon, 28 Mar 2011 06:37:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2SDd5tC022220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Mar 2011 15:39:06 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2SDd1uk020092 for ; Mon, 28 Mar 2011 15:39:05 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 15:39:01 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2011 15:38:57 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401DA9F6F@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110328132607.GE11935@nsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Scribes Thread-Index: AcvtS7mFPunAFOdqSomujEcBlqiHDgAAbvxQ References: <20110328132607.GE11935@nsn.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Kessens, David (NSN - US/Mountain View)" , X-OriginalArrivalTime: 28 Mar 2011 13:39:01.0506 (UTC) FILETIME=[7F59FE20:01CBED4D] Subject: Re: [netmod] Scribes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:37:35 -0000 I can jabber. Mehmet=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of ext David Kessens > Sent: Monday, March 28, 2011 3:26 PM > To: netmod@ietf.org > Subject: [netmod] Scribes >=20 >=20 > As mentioned earlier, we will have a rather short meeting slot this > IETF. >=20 > In order to spend the minimum of time on administrative matters, we > would > like to already ask for scribes and jabber scribes during our meeting. >=20 > David Kessens > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From reid@snmp.com Mon Mar 28 06:39:56 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE433A693A for ; Mon, 28 Mar 2011 06:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2BrkFPloo8d for ; Mon, 28 Mar 2011 06:39:55 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 175263A680D for ; Mon, 28 Mar 2011 06:39:55 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA04837; Mon, 28 Mar 2011 09:41:32 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA17451; Mon, 28 Mar 2011 09:41:32 -0400 (EDT) Message-Id: <201103281341.JAA17451@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Mon, 28 Mar 2011 12:28:22 +0200. <20110328102822.GB24256@elstar.local> Date: Mon, 28 Mar 2011 09:41:31 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:39:56 -0000 > > Section 4 states "Since SMIv2 module names are unique...", but SMIv2 module > > names are not guaranteed to be unique. Maybe it's OK to make this assumption, > > otherwise, I don't know how we'll get unique namespaces. > > RFC 2478 says: > > The names of all standard information modules must be unique (but > different versions of the same information module should have the > same name). Developers of enterprise information modules are > encouraged to choose names for their information modules that will > have a low probability of colliding with standard or other enterprise > information modules. > > My understanding here is that modules names really must be unique > because SMIv2 imports simply do not work if module names are not > unique. However, there is no registry to enforce that module names are > unique and hence this encouraging text to choose module names with low > collision probability. In other words, an SMIv2 parser (at least the > once I have seen) already makes the assumption that module names are > unique. I agree. Our tools make that assumption. It just bothered me to see the statement that "SMIv2 module names are unique" when the rfc only suggests picking names with a low probability of colliding. But I think I'm being too picky and your text is just fine. -David Reid From j.schoenwaelder@jacobs-university.de Mon Mar 28 06:40:46 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071433A6943 for ; Mon, 28 Mar 2011 06:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG1twx3At5aH for ; Mon, 28 Mar 2011 06:40:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D6A583A693A for ; Mon, 28 Mar 2011 06:40:44 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AC98C0021; Mon, 28 Mar 2011 15:42:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ldJhxxj0RwkS; Mon, 28 Mar 2011 15:42:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49ED4C0015; Mon, 28 Mar 2011 15:42:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDCFA174A001; Mon, 28 Mar 2011 15:42:16 +0200 (CEST) Date: Mon, 28 Mar 2011 15:42:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20110328134216.GA24700@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20110314220804.GA26712@elstar.local> <201103252110.RAA05270@adminfs.snmp.com> <20110328102822.GB24256@elstar.local> <4D907FD2.2060602@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D907FD2.2060602@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:40:46 -0000 On Mon, Mar 28, 2011 at 05:32:18AM -0700, Andy Bierman wrote: > On 03/28/2011 03:28 AM, Juergen Schoenwaelder wrote: > >On Fri, Mar 25, 2011 at 05:10:41PM -0400, David Reid wrote: > ... > >>In notifications, why are the non-index objects not of type leafref? > > > >I have to look at this. Perhaps this is simply dating back from the > >times where leafref was a keyref... > > > > If the notification varbind identifies an OBJECT-TYPE macro that is MAX-ACCESS > accessible-for-notify, then the YANG leaf will be inline within the notification. > > What if the varbind is MAX-ACCESS not-accessible (INDEX clause)? > Then is a leafref used or inline? My guess: leafref since keys are accessible in YANG. Yes, I think leafrefs should just work. > sec. 9, bullet 1: > > typo: > The name of this container > is the name of the notification and the name of the current > concatenated by a hyphen. > > name of the current object, concatenated ... fixed > comment: > > What if the OBJECTS clause contains objects that have the same descriptor > but from different modules (FOO-MIB.x and BAR-MIB.x)? > > Then you have container notif-x and container notif-x as siblings which is illegal > in YANG. You can have the same if you include the same object twice in a notification. I checked my code and to my surprise it handles this situation by generating the names notif-x and notif-x-2. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 28 08:08:22 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A52F3A6945 for ; Mon, 28 Mar 2011 08:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htAZ+xGyW6h5 for ; Mon, 28 Mar 2011 08:08:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9D8993A6828 for ; Mon, 28 Mar 2011 08:08:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E4BAC0020; Mon, 28 Mar 2011 17:09:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5K817Bw7-tUM; Mon, 28 Mar 2011 17:09:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73778C0015; Mon, 28 Mar 2011 17:09:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD06F174A380; Mon, 28 Mar 2011 17:09:50 +0200 (CEST) Date: Mon, 28 Mar 2011 17:09:50 +0200 From: Juergen Schoenwaelder To: David Reid Message-ID: <20110328150950.GB25084@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20110328102822.GB24256@elstar.local> <201103281333.JAA17382@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103281333.JAA17382@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:08:22 -0000 On Mon, Mar 28, 2011 at 09:33:44AM -0400, David Reid wrote: > > > Section 6.2: pattern "\p{IsBasicLatin}{0,255}". Should this be > > > "\\p{IsBasicLatin}{0,255}"? > > > > What makes you believe there should be two slashes? > > I thought double-quoted strings in yang required a backslash to be > represented as \\. Indeed. I changed to single quotes. Thanks. /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 Mar 28 08:23:03 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8673A697C for ; Mon, 28 Mar 2011 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A10e1dcbjA2k for ; Mon, 28 Mar 2011 08:23:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E454F3A6945 for ; Mon, 28 Mar 2011 08:23:00 -0700 (PDT) Received: from localhost (dhcp-1148.meeting.ietf.org [130.129.17.72]) by mail.tail-f.com (Postfix) with ESMTPSA id C7D9C76C3BA; Mon, 28 Mar 2011 17:24:36 +0200 (CEST) Date: Mon, 28 Mar 2011 17:24:34 +0200 (CEST) Message-Id: <20110328.172434.219515283.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110328150950.GB25084@elstar.local> References: <20110328102822.GB24256@elstar.local> <201103281333.JAA17382@adminfs.snmp.com> <20110328150950.GB25084@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:23:03 -0000 Juergen Schoenwaelder wrote: > On Mon, Mar 28, 2011 at 09:33:44AM -0400, David Reid wrote: > > > > Section 6.2: pattern "\p{IsBasicLatin}{0,255}". Should this be > > > > "\\p{IsBasicLatin}{0,255}"? > > > > > > What makes you believe there should be two slashes? > > > > I thought double-quoted strings in yang required a backslash to be > > represented as \\. > > Indeed. I changed to single quotes. Thanks. Actually, 6020, section 6.1.3 is not clear on what "\p" means... It could mean that since \p is not listed as a special combination, it means '\p'. Or it could mean that since \p is not special, it means 'p'. pyang treats it as '\p'. What do other implementations do? /martin From ietf@andybierman.com Mon Mar 28 09:15:15 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3530928C0FD for ; Mon, 28 Mar 2011 09:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kguOtb16ueBh for ; Mon, 28 Mar 2011 09:15:14 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by core3.amsl.com (Postfix) with ESMTP id 17D2A28C0FC for ; Mon, 28 Mar 2011 09:15:13 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2SGGhIq028558 for ; Mon, 28 Mar 2011 12:16:49 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.22.51] ([130.129.22.51:49107] helo=[130.129.22.51]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E0/60-26079-A64B09D4; Mon, 28 Mar 2011 12:16:43 -0400 Message-ID: <4D90B468.2030308@andybierman.com> Date: Mon, 28 Mar 2011 09:16:40 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Martin Bjorklund References: <20110328102822.GB24256@elstar.local> <201103281333.JAA17382@adminfs.snmp.com> <20110328150950.GB25084@elstar.local> <20110328.172434.219515283.mbj@tail-f.com> In-Reply-To: <20110328.172434.219515283.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] [idsubmission@ietf.org: New Version Notification for draft-schoenw-netmod-smi-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:15:15 -0000 On 03/28/2011 08:24 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Mar 28, 2011 at 09:33:44AM -0400, David Reid wrote: >>>>> Section 6.2: pattern "\p{IsBasicLatin}{0,255}". Should this be >>>>> "\\p{IsBasicLatin}{0,255}"? >>>> >>>> What makes you believe there should be two slashes? >>> >>> I thought double-quoted strings in yang required a backslash to be >>> represented as \\. >> >> Indeed. I changed to single quotes. Thanks. > > Actually, 6020, section 6.1.3 is not clear on what "\p" means... It > could mean that since \p is not listed as a special combination, it > means '\p'. Or it could mean that since \p is not special, it means > 'p'. > > pyang treats it as '\p'. What do other implementations do? > > yangdump does the same thing. Only the special sequences listed in 6.1.3 are converted. Just found a bug in yangdump --format=yang or --format=html. The converted string replaces the original string instead of preserving the original format. So description "\\t\"" turns into description "\t"", which is of course invalid. oops. > /martin > Andy From mbj@tail-f.com Tue Mar 29 00:59:54 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A1B3A69FC for ; Tue, 29 Mar 2011 00:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub1UwuZ58WkF for ; Tue, 29 Mar 2011 00:59:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 24F9A3A68E1 for ; Tue, 29 Mar 2011 00:59:52 -0700 (PDT) Received: from localhost (dhcp-44b4.meeting.ietf.org [130.129.68.180]) by mail.tail-f.com (Postfix) with ESMTPSA id 69C2C616001 for ; Tue, 29 Mar 2011 10:01:29 +0200 (CEST) Date: Tue, 29 Mar 2011 10:01:27 +0200 (CEST) Message-Id: <20110329.100127.236807628.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] review of draft-schoenw-netmod-smi-yang-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:59:54 -0000 Hi, I have reviewed this document, and here are my comments: o In general, I think the mapping would be more clear if you used 2119 language. For example, the first three paragraphs in section 4 are not clear currently: SMIv2 modules are mapped to corresponding YANG modules. The YANG module name is the same as the SMIv2 module name. this is a MUST The YANG namespace is constructed out of a constant prefix followed by the SMIv2 module name. Since SMIv2 module names are unique, the resulting YANG namespace is unique. The registered prefix is urn:ietf:params:xml:ns:yang:smiv2:, see the IANA considerations section. this is also a MUST The YANG prefix is derived from the SMIv2 module name using the module prefix generation algorithm described in Section 3. this is a MAY. The YANG prefix is supposed to be short and it must be unique within the set of all prefixes used by a YANG module. The algorithm described in Section 3 generates such prefixes. o Table 3 can be pruned by removing the explict SNMPv2-CONF symbols. SNMPv2-CONF is also listed as 'remove all symbols'. o In general, you should list in your translation rules sections where there's an ietf-yang-smiv2 extension statement available, so e.g. where it says: o The SMIv2 MAX-ACCESS clause is ignored. it could say that a smiv2:max-access statement MAY be generated. o I think section 5 should mention that a container is generated from the MODULE-IDENTITY (this is currently mentioned in section 7.1). o Section 7 says: The mapping suppresses many structural OBJECT IDENTIFIER assignments that are typically used to organize the OBJECT IDENTIFIER tree. I don't think this is true anymore, is it? o Section 7.1 says: o Object identifier assignments through ASN.1 value assignments or through the invocation of a MODULE-IDENTITY clause are translated to YANG container statements. I think more text is needed. It is not clear from this description how containment is done. For example, given this: bar OBJECT IDENTIFIER ::= { foo 1 } baz OBJECT IDENTIFIER ::= { bar 1 } it is not clear if the result is: container bar { ... } container baz { ... } or container bar { container baz { ... } ... } o Section 7.1, last bullet: o Implementations MAY suppress the generation of YANG containers for object identifiers that only contain SMIv2 conformance definitions. Same if the oid only contains notifications, I assume. o Section 9.2, the TODO. I suggest that only an identity is generated in the normal case, but if there is also some other oid defined under the object-identity oid, then a container is generated. o Section 10.1 The name of this container is the name of the notification and the name of the current concatenated by a hyphen. I must miss something obvious here, but why is the name of the notification prepended to the container name? o Section 10.1 is the name of the notification and the name of the current concatenated by a hyphen. this should be ... current object concatenated ... o Section 10.1 If the current object belongs a conceptual table, then a sequence of leaf statements is generated for each INDEX of the SMIv2 conceptual table. Next, a leaf statement is generated for the current object. This needs to specify that the type of the leaf is a leafref. It also needs to specify what the name of the leaf is. o Section 10.1 All container leafs are marked as config false. Not necessary. Remove. (Section 7.14 of RFC 6020 says: If a "config" statement is present for any node in the notification tree, the "config" statement is ignored.) /martin From j.schoenwaelder@jacobs-university.de Tue Mar 29 01:42:31 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7713A692D for ; Tue, 29 Mar 2011 01:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW7hV8lKdmqK for ; Tue, 29 Mar 2011 01:42:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 87DBF3A691B for ; Tue, 29 Mar 2011 01:42:30 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 441F1C002D for ; Tue, 29 Mar 2011 10:44:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i5FNLcBQlu7L; Tue, 29 Mar 2011 10:44:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86ADEC0025; Tue, 29 Mar 2011 10:44:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC3B7174B7B8; Tue, 29 Mar 2011 10:44:03 +0200 (CEST) Date: Tue, 29 Mar 2011 10:44:03 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110329084403.GB27060@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] js review of draft-lhotka-netmod-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:42:31 -0000 Hi, here are some comments on draft-lhotka-netmod-routing-cfg-00: a) I suggest that the introduction talks less about the charter of NETMOD - charters change and what matters is the purpose of the module, not how it was created. b) p6: s/initial design/design/ c) You require that "every compliant implementation MUST support IPv4 unicast routing and implement at least one (main) routing table". Isn't it the job of the IPv4/IPv6 node requirements document to say what nodes are expected to support? If my box is a router for a v6 only network, why should I be required by the YANG data model to support IPv4 routing? Perhaps better would be to state that a box supporting IPv4 forwarding (i.e a router) MUST support IPv4 unicast routing and implement at least one (main) routing table and perhaps for the IPv6 case. If we follow this path, we might want to also define a feature ipv4-routing. d) You define address family identities. This raises the question whether this is the proper place to do this, whether this needs to be extensible (ie under IANA control), how this relates to the AddressFamilyNumbers TC in the IANA-ADDRESS-FAMILY-NUMBERS-MIB. e) Should there be a get-route RPC, giving me the route used for a given destination address? f) You often have an id leaf of type string paired with a description leaf of type string. It is not totally clear to me how these are going to be used and whether they are both needed. g) I prefer to have an explicit identity defined for a blocking filter instead of overloading the base route-filter with these semantics. Perhaps we also need an identify for a filter that just passes everything. h) Should the routing-table have a key name? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 29 02:39:03 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6F33A68AB for ; Tue, 29 Mar 2011 02:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfCEhgyT1mo6 for ; Tue, 29 Mar 2011 02:39:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 57AB33A67B7 for ; Tue, 29 Mar 2011 02:39:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A2ABC0025 for ; Tue, 29 Mar 2011 11:40:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FhRjIJj4LAI2; Tue, 29 Mar 2011 11:40:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E8D3C0009; Tue, 29 Mar 2011 11:40:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7C14F174BAB9; Tue, 29 Mar 2011 11:40:34 +0200 (CEST) Date: Tue, 29 Mar 2011 11:40:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110329094034.GA27275@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] RFC 6095 on Extending YANG with Language Abstractions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:39:03 -0000 Hi, I think this deserves to be forwarded to the NETMOD working group since it is closely related to our work. /js ----- Forwarded message from rfc-editor@rfc-editor.org ----- Date: Tue, 29 Mar 2011 01:51:21 -0700 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org Subject: RFC 6095 on Extending YANG with Language Abstractions Message-ID: <20110329085121.8B54AE077C@rfc-editor.org> A new Request for Comments is now available in online RFC libraries. RFC 6095 Title: Extending YANG with Language Abstractions Author: B. Linowski, M. Ersue, S. Kuryla Status: Experimental Stream: IETF Date: March 2011 Mailbox: bernd.linowski.ext@nsn.com, mehmet.ersue@nsn.com, s.kuryla@gmail.com Pages: 75 Characters: 140259 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-linowski-netmod-yang-abstract-05.txt URL: http://www.rfc-editor.org/rfc/rfc6095.txt YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- From lhotka@cesnet.cz Tue Mar 29 04:58:35 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8CB28C111 for ; Tue, 29 Mar 2011 04:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scbF8DgiRsdL for ; Tue, 29 Mar 2011 04:58:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id C391D3A68F5 for ; Tue, 29 Mar 2011 04:58:33 -0700 (PDT) Received: from [IPv6:2001:df8::8:5ab0:35ff:fe73:8f1d] (unknown [IPv6:2001:df8:0:8:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0A3EF2CDE057; Tue, 29 Mar 2011 14:00:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20110329084403.GB27060@elstar.local> Date: Tue, 29 Mar 2011 14:00:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81D10A50-28CA-44B9-A1B1-4F64F89436CA@cesnet.cz> References: <20110329084403.GB27060@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-lhotka-netmod-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:58:35 -0000 On Mar 29, 2011, at 10:44 AM, Juergen Schoenwaelder wrote: > Hi, >=20 > here are some comments on draft-lhotka-netmod-routing-cfg-00: >=20 > a) I suggest that the introduction talks less about the charter of > NETMOD - charters change and what matters is the purpose of the > module, not how it was created. OK. >=20 > b) p6: s/initial design/design/ OK. >=20 > c) You require that "every compliant implementation MUST support IPv4 > unicast routing and implement at least one (main) routing table". > Isn't it the job of the IPv4/IPv6 node requirements document to say > what nodes are expected to support? If my box is a router for a v6 > only network, why should I be required by the YANG data model to > support IPv4 routing? Perhaps better would be to state that a box > supporting IPv4 forwarding (i.e a router) MUST support IPv4 unicast > routing and implement at least one (main) routing table and perhaps > for the IPv6 case. If we follow this path, we might want to also > define a feature ipv4-routing. You are right, I just wanted to make it really easy for common setups to = use just this module. But I am fine with changing it. >=20 > d) You define address family identities. This raises the question > whether this is the proper place to do this, whether this needs to > be extensible (ie under IANA control), how this relates to the > AddressFamilyNumbers TC in the IANA-ADDRESS-FAMILY-NUMBERS-MIB. OK, so only "address-family" identity can be defined here, but I think = it should remain implemented as identities, so the relation to = af-numbers should be only through the names. >=20 > e) Should there be a get-route RPC, giving me the route used for a > given destination address? Yes, there may be more admin operations, we should get some idea from = existing router implementations. >=20 > f) You often have an id leaf of type string paired with a description > leaf of type string. It is not totally clear to me how these are > going to be used and whether they are both needed. The "id" leaf is used as the mandatory key, but one that is not expected = to be used in leafrefs. Lists whose entries will be referenced have the = key named "name". Maybe this should be stated in the draft - or do you = have an idea of an alternative implementation? =20 >=20 > g) I prefer to have an explicit identity defined for a blocking filter > instead of overloading the base route-filter with these semantics. > Perhaps we also need an identify for a filter that just passes > everything. OK, no problem. >=20 > h) Should the routing-table have a key name? Yes, that's also my question: does it make sense to, e.g. enforce the = name of each address family default table? Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Tue Mar 29 05:51:54 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A653A6801 for ; Tue, 29 Mar 2011 05:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO4XE3hDnxzB for ; Tue, 29 Mar 2011 05:51:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 8166D3A67C3 for ; Tue, 29 Mar 2011 05:51:51 -0700 (PDT) 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 p2TCrPIK032168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2011 14:53:25 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2TCrPEx028354; Tue, 29 Mar 2011 14:53:25 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 14:53:25 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBEE10.4AD072B6" Date: Tue, 29 Mar 2011 14:53:23 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401DAA8E8@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110329094034.GA27275@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] RFC 6095 on Extending YANG with Language Abstractions Thread-Index: Acvt9WS6YcCc+/pLQSef45CqmmzfxgAFYacA References: <20110329094034.GA27275@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 29 Mar 2011 12:53:25.0012 (UTC) FILETIME=[4AAFE540:01CBEE10] Cc: hideki.okita.pf@hitachi.com Subject: Re: [netmod] RFC 6095 on Extending YANG with Language Abstractions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:51:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEE10.4AD072B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, indeed, RFC 6095 is closely related to YANG, as it defines YANG language extensions for Complex Types and Typed Instance Identifiers and aims to ease the life of implementers if they follow a top-down modeling approach and want to use abstract classes and inheritance.=20 Thank you everybody in NETMOD WG and our AD Dan Romascanu, who supported this activity with review and comments and helped to get it to the RFC state. RFC 6095 is an Experimental RFC and can be republished as standard track document, possibly as part of a future version of YANG, if the experiment results in successful usage.=20 We would be happy to hear from folks who plan to use the language extensions in RFC 6095 for modeling. Please send Bernd and myself a note if you would like to have support for such a modeling effort. There is an open source validation tool for YANG Complex Types and Typed Instance Identifiers available at http://code.google.com/p/pyang-ct/.=20 A 2nd implementation of the extensions has been incorporated into libsmi, which is available at http://www.ibr.cs.tu-bs.de/svn/libsmi.=20 Please see also the attachment for a potential use of the extensions in RFC 6095. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of ext Juergen Schoenwaelder > Sent: Tuesday, March 29, 2011 11:41 AM > To: netmod@ietf.org > Subject: [netmod] RFC 6095 on Extending YANG with Language Abstractions >=20 > Hi, >=20 > I think this deserves to be forwarded to the NETMOD working group > since it is closely related to our work. >=20 > /js >=20 > ----- Forwarded message from rfc-editor@rfc-editor.org ----- >=20 > Date: Tue, 29 Mar 2011 01:51:21 -0700 > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: rfc-editor@rfc-editor.org > Subject: RFC 6095 on Extending YANG with Language Abstractions > Message-ID: <20110329085121.8B54AE077C@rfc-editor.org> >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6095 >=20 > Title: Extending YANG with Language Abstractions > Author: B. Linowski, M. Ersue, > S. Kuryla > Status: Experimental > Stream: IETF > Date: March 2011 > Mailbox: bernd.linowski.ext@nsn.com, > mehmet.ersue@nsn.com, > s.kuryla@gmail.com > Pages: 75 > Characters: 140259 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-linowski-netmod-yang-abstract-05.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6095.txt >=20 > YANG -- the Network Configuration Protocol (NETCONF) Data Modeling > Language -- supports modeling of a tree of data elements that > represent the configuration and runtime status of a particular > network element managed via NETCONF. This memo suggests enhancing > YANG with supplementary modeling features and language abstractions > with the aim to improve the model extensibility and reuse. > This document defines an Experimental Protocol for the Internet > community. >=20 >=20 > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > ----- End forwarded message ----- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_001_01CBEE10.4AD072B6 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Disposition-Notification-To: "Ersue, Mehmet (NSN - DE/Munich)" Subject: Using YANG and its extension for Complex Types in draft-okita-ops-vnetmodel WAS:FW: RFC 6095 on Extending YANG with Language Abstractions Date: Tue, 29 Mar 2011 14:13:27 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using YANG and its extension for Complex Types in draft-okita-ops-vnetmodel WAS:FW: RFC 6095 on Extending YANG with Language Abstractions Thread-Index: Acvt7qp7JP2uYSkfSO+LI6ei3NVdzAAGXW9A From: "Ersue, Mehmet (NSN - DE/Munich)" To: Cc: , , "Linowski, Bernd (EXT-Other - DE)" Dear Hideki, as I commented in the OPSAWG session on Monday morning I would see it valuable if you would use YANG as the modeling language for the information model in your draft. I believe the YANG extension for Complex Types, which has been published today (a few hours ago :) as RFC 6095, will further ease your life as it supports the top-down modeling approach with class inheritance. Base classes you are using are already defined in this RFC and can be further reused. Please let me and Bernd know if you need help for modeling with YANG and its extensions. PS: Please check http://code.google.com/p/pyang-ct/ for an open source validation tool for YANG Complex Types. Cheers,=20 Mehmet=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ext rfc-editor@rfc-editor.org Sent: Tuesday, March 29, 2011 10:51 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 6095 on Extending YANG with Language Abstractions A new Request for Comments is now available in online RFC libraries. =20 RFC 6095 Title: Extending YANG with Language Abstractions=20 Author: B. Linowski, M. Ersue, S. Kuryla Status: Experimental Stream: IETF Date: March 2011 Mailbox: bernd.linowski.ext@nsn.com,=20 mehmet.ersue@nsn.com,=20 s.kuryla@gmail.com Pages: 75 Characters: 140259 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-linowski-netmod-yang-abstract-05.txt URL: http://www.rfc-editor.org/rfc/rfc6095.txt YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. =20 This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------_=_NextPart_001_01CBEE10.4AD072B6-- From B.Hedstrom@CableLabs.com Wed Mar 30 12:09:31 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5690B3A6BB3 for ; Wed, 30 Mar 2011 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgrwrpnQrsyC for ; Wed, 30 Mar 2011 12:09:27 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id C4ACD3A6A74 for ; Wed, 30 Mar 2011 12:09:27 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p2UJB6kX014237 for ; Wed, 30 Mar 2011 13:11:06 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 30 Mar 2011 13:11:06 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 30 Mar 2011 13:11:06 -0600 From: Brian Hedstrom To: "netmod@ietf.org" Date: Wed, 30 Mar 2011 13:11:05 -0600 Thread-Topic: Comments on draft-schoenw-netmod-smi-yang-02 Thread-Index: AcvvDjev5o6D7dIXSxmiX7mkiKzx2g== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D3541C5E7@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D3541C5E7srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [netmod] Comments on draft-schoenw-netmod-smi-yang-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:09:31 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D3541C5E7srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETMOD WG: I have some questions on the use cases around the intended use of draft-sch= oenw-netmod-smi-yang-02. Presuming we end up having standards-based tools that convert SMIv2 MIBs in= to YANG modules and we can easily convert all the RFC MIBs into YANG Module= s, what if we don't want all the SMIv2 baggage in our YANG modules and corr= esponding data model implementations on the client and server? Will there now be two YANG modules published for every RFC MIB? One that i= s auto-converted using the translation tool built around this draft standar= d and another one that is built from the ground-up (i.e., YANG-centric, no = SMI baggage), perhaps by this working group (for example, the SNMP Cfg modu= le)? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 AIM: brzahedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com --_000_76AC5FEF83F1E64491446437EA81A61F7D3541C5E7srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NETMOD WG:<= /o:p>

 

I h= ave some questions on the use cases around the intended use of draft-schoen= w-netmod-smi-yang-02.

Presuming we end u= p having standards-based tools that convert SMIv2 MIBs into YANG modules an= d we can easily convert all the RFC MIBs into YANG Modules, what if we don&= #8217;t want all the SMIv2 baggage in our YANG modules and corresponding da= ta model implementations on the client and server?

 

Will there now be tw= o YANG modules published for every RFC MIB?  One that is auto-converte= d using the translation tool built around this draft standard and another o= ne that is built from the ground-up (i.e., YANG-centric, no SMI baggage), p= erhaps by this working group (for example, the SNMP Cfg module)?=

 

Thanks,<= o:p>

 

Brian Hedstrom
Senior Architect, Busi= ness & Operational Support Systems
CableLabs, Inc.
858 Coal Creek= Circle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.81= 20
AIM: brzahedstrom
Skype IM: brian.hedstrom
b.hedstrom@cablelabs.com

 

= --_000_76AC5FEF83F1E64491446437EA81A61F7D3541C5E7srvxchg_-- From j.schoenwaelder@jacobs-university.de Thu Mar 31 06:31:16 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DD528C139 for ; Thu, 31 Mar 2011 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpReNLhhuFnG for ; Thu, 31 Mar 2011 06:31:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3F43628C0F2 for ; Thu, 31 Mar 2011 06:31:14 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0BC9C004E for ; Thu, 31 Mar 2011 15:32:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dvC9ckDuA83S; Thu, 31 Mar 2011 15:32:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA3A2C0019; Thu, 31 Mar 2011 15:32:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1ED3A175042B; Thu, 31 Mar 2011 15:32:48 +0200 (CEST) Date: Thu, 31 Mar 2011 15:32:48 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110331133248.GA34179@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] iana iftype in yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:31:16 -0000 Hi, during the WG session, there was a motion to use the existing ifType enumerations in YANG instead of identities. We have meanwhile spoken to IANA to better understand how the procedures work and how a YANG version of the IANA ifType can be created and maintained. We also consulted with Dan Romascanu, who is the current expert for ifType assignments and as a matter of convenience also our AD. ;-) Here is the current understanding and the proposed line of action. The IANA ifType registry got established in RFC 1573. The registry itself is maintained in http://www.iana.org/assignments/smi-numbers. In addition, IANA updates http://www.iana.org/assignments/ianaiftype-mib whenever assignments are made (in a manual process). What we are going to ask them to do is to maintain in addition a YANG module as another "view" on the registry. IANA told us this is not a big deal. To get this established, though, we need to have a document that specifies that this needs to be maintained and this document needs to include an initial version of the iftype YANG module. Since this is rather long, we prefer to create a separate Internet-Draft that establishes the YANG version of the ifType registry by specifying the necessary IANA rules and providing the initial version. If there are any concerns about this way forward, please let us know within the next week. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Thu Mar 31 07:11:39 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BF728C0FA for ; Thu, 31 Mar 2011 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RWlE2EWjo13 for ; Thu, 31 Mar 2011 07:11:37 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7D32E3A6B4B for ; Thu, 31 Mar 2011 07:11:35 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA00760; Thu, 31 Mar 2011 10:12:57 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA24143; Thu, 31 Mar 2011 10:12:52 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 31 Mar 2011 10:12:52 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110331133248.GA34179@elstar.local> Message-ID: References: <20110331133248.GA34179@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] iana iftype in yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:11:39 -0000 I think this is the right approach. I can't think of any concerns at this time. -dss On Thu, 31 Mar 2011, Juergen Schoenwaelder wrote: > Hi, > > during the WG session, there was a motion to use the existing ifType > enumerations in YANG instead of identities. We have meanwhile spoken > to IANA to better understand how the procedures work and how a YANG > version of the IANA ifType can be created and maintained. We also > consulted with Dan Romascanu, who is the current expert for ifType > assignments and as a matter of convenience also our AD. ;-) > > Here is the current understanding and the proposed line of action. > The IANA ifType registry got established in RFC 1573. The registry > itself is maintained in http://www.iana.org/assignments/smi-numbers. > In addition, IANA updates http://www.iana.org/assignments/ianaiftype-mib > whenever assignments are made (in a manual process). What we are going > to ask them to do is to maintain in addition a YANG module as another > "view" on the registry. IANA told us this is not a big deal. > > To get this established, though, we need to have a document that > specifies that this needs to be maintained and this document needs to > include an initial version of the iftype YANG module. Since this is > rather long, we prefer to create a separate Internet-Draft that > establishes the YANG version of the ifType registry by specifying the > necessary IANA rules and providing the initial version. > > If there are any concerns about this way forward, please let us know > within the next week. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From B.Hedstrom@CableLabs.com Thu Mar 31 08:04:35 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803B828B56A for ; Thu, 31 Mar 2011 08:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEEKbc+qURPz for ; Thu, 31 Mar 2011 08:04:34 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 0D0D83A6B24 for ; Thu, 31 Mar 2011 08:04:33 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p2VF6D0m008716; Thu, 31 Mar 2011 09:06:13 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 31 Mar 2011 09:06:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 31 Mar 2011 09:06:13 -0600 From: Brian Hedstrom To: Juergen Schoenwaelder , "netmod@ietf.org" Date: Thu, 31 Mar 2011 09:06:12 -0600 Thread-Topic: [netmod] iana iftype in yang Thread-Index: AcvvqCbHBLcmMIFwQS2iAd5NlH4+hgAC74Vg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D3541C659@srvxchg> References: <20110331133248.GA34179@elstar.local> In-Reply-To: <20110331133248.GA34179@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [netmod] iana iftype in yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:04:35 -0000 Hi Juergen, To better understand this approach, will the NETMOD WG create a new YANG da= ta type that mimics the IANAifType SNMP Textual Convention? And then the Interfaces Config YANG Module will just import that data type? Will this YANG Data Type be defined in a new RFC or existing RFC that alrea= dy defines YANG standard data types? What will be the process for updating the YANG data type each time IANA add= s a new ifType enum value? Will this deprecate that RFC each time this hap= pens? Or will the NETMOD WG queue up several new ifTypes from IANA and the= n add them all at once to a newer RFC that deprecates the prior RFC? Thanks for clarifying, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 AIM: brzahedstrom Skype IM: brian.hedstrom=20 b.hedstrom@cablelabs.com=20 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Thursday, March 31, 2011 7:33 AM To: netmod@ietf.org Subject: [netmod] iana iftype in yang Hi, during the WG session, there was a motion to use the existing ifType enumer= ations in YANG instead of identities. We have meanwhile spoken to IANA to b= etter understand how the procedures work and how a YANG version of the IANA= ifType can be created and maintained. We also consulted with Dan Romascanu= , who is the current expert for ifType assignments and as a matter of conve= nience also our AD. ;-) Here is the current understanding and the proposed line of action. The IANA ifType registry got established in RFC 1573. The registry itself i= s maintained in http://www.iana.org/assignments/smi-numbers. In addition, IANA updates http://www.iana.org/assignments/ianaiftype-mib whenever assignments are made (in a manual process). What we are going to a= sk them to do is to maintain in addition a YANG module as another "view" on= the registry. IANA told us this is not a big deal. To get this established, though, we need to have a document that specifies = that this needs to be maintained and this document needs to include an init= ial version of the iftype YANG module. Since this is rather long, we prefer= to create a separate Internet-Draft that establishes the YANG version of t= he ifType registry by specifying the necessary IANA rules and providing the= initial version. If there are any concerns about this way forward, please let us know within= the next week. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu Mar 31 08:15:29 2011 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68A73A6AD7 for ; Thu, 31 Mar 2011 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHOLNE8LnENQ for ; Thu, 31 Mar 2011 08:15:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B8DD03A680E for ; Thu, 31 Mar 2011 08:15:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1916EC004E; Thu, 31 Mar 2011 17:17:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Wo2louCDduE0; Thu, 31 Mar 2011 17:17:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 662EAC000A; Thu, 31 Mar 2011 17:17:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0633317507E9; Thu, 31 Mar 2011 17:17:03 +0200 (CEST) Date: Thu, 31 Mar 2011 17:17:03 +0200 From: Juergen Schoenwaelder To: Brian Hedstrom Message-ID: <20110331151703.GA34484@elstar.local> Mail-Followup-To: Brian Hedstrom , "netmod@ietf.org" References: <20110331133248.GA34179@elstar.local> <76AC5FEF83F1E64491446437EA81A61F7D3541C659@srvxchg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D3541C659@srvxchg> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] iana iftype in yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:15:29 -0000 On Thu, Mar 31, 2011 at 09:06:12AM -0600, Brian Hedstrom wrote: > Hi Juergen, > > To better understand this approach, will the NETMOD WG create a new YANG data type that mimics the IANAifType SNMP Textual Convention? > And then the Interfaces Config YANG Module will just import that data type? yes > Will this YANG Data Type be defined in a new RFC or existing RFC that already defines YANG standard data types? There will be an RFC that defines the initial version of the type and once published updates will handled by IANA as they do already for the IANA ifType. > What will be the process for updating the YANG data type each time IANA adds a new ifType enum value? Will this deprecate that RFC each time this happens? Or will the NETMOD WG queue up several new ifTypes from IANA and then add them all at once to a newer RFC that deprecates the prior RFC? IANA will provide the IANA maintained YANG module, pretty much as IANA provides the IANA maintained SMIv2 module. You request a new ifType as you do now. Once the request is approved, the registry is updated as well as the SMIv2 module and the YANG module. No need for new RFCs nor is there any WG involvement. IANA takes care. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103