From root@core3.amsl.com Tue Jun 1 15:15:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 937943A68F8; Tue, 1 Jun 2010 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100601221501.937943A68F8@core3.amsl.com> Date: Tue, 1 Jun 2010 15:15:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-13.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, 01 Jun 2010 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for the Network Configuration Protocol (NETCONF) Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-13.txt Pages : 185 Date : 2010-06-01 YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-01150107.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Wed Jun 9 09:42:25 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E4B593A698D; Wed, 9 Jun 2010 09:42:25 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100609164225.E4B593A698D@core3.amsl.com> Date: Wed, 9 Jun 2010 09:42:25 -0700 (PDT) X-Mailman-Approved-At: Wed, 09 Jun 2010 09:46:36 -0700 Cc: Internet Architecture Board , netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'YANG - A data modeling language for the Network Configuration Protocol (NETCONF)' to Proposed Standard 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, 09 Jun 2010 16:42:26 -0000 The IESG has approved the following document: - 'YANG - A data modeling language for the Network Configuration Protocol (NETCONF) ' as a Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-13.txt Technical Summary YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. YANG is used to model the operations and content layers of NETCONF. This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in XML, and how NETCONF operations are used to manipulate the data. Working Group Summary Consensus was reached among all interested parties before requesting the publication of this document. Document Quality There are multiple independent implementations of YANG today, both commercial and freely-available code and verification tools. Personnel David Partain is the document shepherd. Dan Romascanu is the responsible AD. RFC Editor Note OLD: 7.19.3. The description Statement The "description" statement takes as an argument a string which contains a high-level textual description of this definition. NEW: 7.19.3. The description Statement The "description" statement takes as an argument a string which contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer; for the sake of interoperability it is RECOMMENDED to choose a language that is widely understood among the community of network administrators who will use the module. From dromasca@avaya.com Wed Jun 9 09:46:36 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D276D3A6977 for ; Wed, 9 Jun 2010 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_50=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 u8tLWQ5abaKA for ; Wed, 9 Jun 2010 09:46:36 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 560D728C11A for ; Wed, 9 Jun 2010 09:46:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,392,1272859200"; d="scan'208";a="192654047" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Jun 2010 12:46:34 -0400 X-IronPort-AV: E=Sophos;i="4.53,392,1272859200"; d="scan'208";a="470935889" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Jun 2010 12:46:29 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jun 2010 18:46:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard Thread-Index: AcsH8s+cRa3N2t3QR9SBCGQpY9zCCAAAGA1w From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard 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, 09 Jun 2010 16:46:36 -0000 =20 Congratulations! Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, June 09, 2010 7:42 PM To: IETF-Announce Cc: Internet Architecture Board; netmod chair; netmod mailing list; RFC Editor Subject: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard The IESG has approved the following document: - 'YANG - A data modeling language for the Network Configuration Protocol=20 (NETCONF) ' as a Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group.=20 The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-13.txt Technical Summary YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. YANG is used to model the operations and content layers of NETCONF. This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in XML, and how NETCONF operations are used to manipulate the data. Working Group Summary Consensus was reached among all interested parties before requesting the publication of this document. Document Quality There are multiple independent implementations of YANG today, both commercial and freely-available code and verification tools. Personnel David Partain is the document shepherd. Dan Romascanu is the responsible AD.=20 RFC Editor Note OLD: 7.19.3. The description Statement The "description" statement takes as an argument a string which contains a high-level textual description of this definition. NEW: 7.19.3. The description Statement The "description" statement takes as an argument a string which contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer; for the sake of interoperability it is RECOMMENDED to choose a language that is widely understood among the community of network administrators who will use the module. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From david.kessens@nsn.com Wed Jun 9 11:27:01 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DCB3A659A for ; Wed, 9 Jun 2010 11:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 KHDxPqdPp1Xq for ; Wed, 9 Jun 2010 11:27:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0306A3A6359 for ; Wed, 9 Jun 2010 11:26:59 -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 o59IQuGo024973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jun 2010 20:26:56 +0200 Received: from localhost.localdomain ([10.138.49.76]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o59IQs1C006371; Wed, 9 Jun 2010 20:26:55 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o59IQs24005467; Wed, 9 Jun 2010 11:26:54 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o59IQraU005465; Wed, 9 Jun 2010 11:26:53 -0700 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Wed, 9 Jun 2010 11:26:53 -0700 From: David Kessens To: "Romascanu, Dan (Dan)" Message-ID: <20100609182652.GC3053@nsn.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) Cc: NETMOD Working Group Subject: Re: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard 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, 09 Jun 2010 18:27:01 -0000 All, I would like to thank all authors, contributors & reviewers for their work. This is document was by nature a long document and involved a significant amount of time investment of everybody involved. A big hurray for reaching this milestone! David Kessens --- On Wed, Jun 09, 2010 at 06:46:08PM +0200, Romascanu, Dan (Dan) wrote: > > > Congratulations! > > Dan > > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, June 09, 2010 7:42 PM > To: IETF-Announce > Cc: Internet Architecture Board; netmod chair; netmod mailing list; RFC > Editor > Subject: Protocol Action: 'YANG - A data modeling language for the > NetworkConfiguration Protocol (NETCONF)' to Proposed Standard > > The IESG has approved the following document: > > - 'YANG - A data modeling language for the Network Configuration > Protocol > (NETCONF) ' > as a Proposed Standard > > > This document is the product of the NETCONF Data Modeling Language > Working Group. > > The IESG contact persons are Dan Romascanu and Ron Bonica. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-13.txt > > Technical Summary > > YANG is a data modeling language used to model configuration and state > data manipulated by the Network Configuration Protocol (NETCONF) > protocol, NETCONF remote procedure calls, and NETCONF notifications. > YANG is used to model the operations and content layers of NETCONF. This > document describes the syntax and semantics of the YANG language, how > the data model defined in a YANG module is represented in XML, and how > NETCONF operations are used to manipulate the data. > > Working Group Summary > > Consensus was reached among all interested parties before requesting the > publication of this document. > > Document Quality > > There are multiple independent implementations of YANG today, both > commercial and freely-available code and verification tools. > > Personnel > > David Partain is the document shepherd. Dan Romascanu is the > responsible AD. > > RFC Editor Note > > OLD: > > 7.19.3. The description Statement > > The "description" statement takes as an argument a string which > contains a high-level textual description of this definition. > > NEW: > > 7.19.3. The description Statement > > The "description" statement takes as an argument a string which > contains a human-readable textual description of this definition. > The text is provided in a language (or languages) chosen by the > module developer; for the sake of interoperability it is RECOMMENDED > to choose a language that is widely understood among the community of > network administrators who will use the module. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod David Kessens --- From david.partain@ericsson.com Wed Jun 9 12:05:35 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D603A6359 for ; Wed, 9 Jun 2010 12:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 N0wQQygQ8QmT for ; Wed, 9 Jun 2010 12:05:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2011D3A6768 for ; Wed, 9 Jun 2010 12:05:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-b4-4c0fe5fba38b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B1.7B.29106.BF5EF0C4; Wed, 9 Jun 2010 21:05:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 21:05:31 +0200 Received: from [153.88.45.99] ([153.88.45.99]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 21:05:30 +0200 From: David Partain Organization: Ericsson To: netmod@ietf.org Date: Wed, 9 Jun 2010 21:05:29 +0200 User-Agent: KMail/1.9.10 References: <20100609182652.GC3053@nsn.com> In-Reply-To: <20100609182652.GC3053@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201006092105.29402.david.partain@ericsson.com> X-OriginalArrivalTime: 09 Jun 2010 19:05:30.0944 (UTC) FILETIME=[BAF20400:01CB0806] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard 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, 09 Jun 2010 19:05:35 -0000 On Wednesday 09 June 2010 20.26.53 David Kessens wrote: > All, > > I would like to thank all authors, contributors & reviewers for their work. > > This is document was by nature a long document and involved a significant > amount of time investment of everybody involved. > > A big hurray for reaching this milestone! I second that! Still more work to do, but this was a Big Step! Cheers, David.2 From mbj@tail-f.com Wed Jun 9 12:21:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575633A67AD for ; Wed, 9 Jun 2010 12:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 0aLuC4k6GcwC for ; Wed, 9 Jun 2010 12:21:15 -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 8F6063A659A for ; Wed, 9 Jun 2010 12:21:15 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 07939616001; Wed, 9 Jun 2010 21:21:16 +0200 (CEST) Date: Wed, 09 Jun 2010 21:21:15 +0200 (CEST) Message-Id: <20100609.212115.203527457.mbj@tail-f.com> To: david.partain@ericsson.com From: Martin Bjorklund In-Reply-To: <201006092105.29402.david.partain@ericsson.com> References: <20100609182652.GC3053@nsn.com> <201006092105.29402.david.partain@ericsson.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard 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, 09 Jun 2010 19:21:16 -0000 David Partain wrote: > On Wednesday 09 June 2010 20.26.53 David Kessens wrote: > > All, > > > > I would like to thank all authors, contributors & reviewers for their work. > > > > This is document was by nature a long document and involved a significant > > amount of time investment of everybody involved. > > > > A big hurray for reaching this milestone! > > I second that! Still more work to do, but this was a Big Step! Yes, and now it is time to write those data models ;-) /martin From phil@juniper.net Wed Jun 9 12:44:10 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B803A67CF for ; Wed, 9 Jun 2010 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df5aXZ4uuTak for ; Wed, 9 Jun 2010 12:44:09 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 28DE63A635F for ; Wed, 9 Jun 2010 12:44:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTA/vBjbehyfx4GuqquNBs9gh4w7Tl2MH@postini.com; Wed, 09 Jun 2010 12:44:11 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Wed, 9 Jun 2010 12:41:58 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 12:41:57 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 12:41:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 12:41:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o59JfuD53984; Wed, 9 Jun 2010 12:41:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o59JOEpi004945; Wed, 9 Jun 2010 19:24:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006091924.o59JOEpi004945@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100609.212115.203527457.mbj@tail-f.com> Date: Wed, 9 Jun 2010 15:24:14 -0400 From: Phil Shafer X-OriginalArrivalTime: 09 Jun 2010 19:41:57.0179 (UTC) FILETIME=[D20B00B0:01CB080B] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard 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, 09 Jun 2010 19:44:10 -0000 Martin Bjorklund writes: >David Partain wrote: >> > A big hurray for reaching this milestone! Amen. Thanks and congratulations to all of us!! Vvroomba!! >Yes, and now it is time to write those data models ;-) I'll second that! Thanks, Phil From dromasca@avaya.com Thu Jun 10 03:39:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3BE3A69F9 for ; Thu, 10 Jun 2010 03:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=1.288, 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 IwuRg338w2ZH for ; Thu, 10 Jun 2010 03:39:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8454E3A6956 for ; Thu, 10 Jun 2010 03:39:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,397,1272859200"; d="scan'208";a="222331159" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jun 2010 06:39:49 -0400 X-IronPort-AV: E=Sophos;i="4.53,397,1272859200"; d="scan'208";a="482350335" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2010 06:39:47 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jun 2010 12:39:25 +0200 Message-ID: In-Reply-To: <20100609.212115.203527457.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard Thread-Index: AcsICPPGvFdOzZmHRfO63cnj3RzbJwAf6wSw References: <20100609182652.GC3053@nsn.com><201006092105.29402.david.partain@ericsson.com> <20100609.212115.203527457.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netmod@ietf.org Subject: Re: [netmod] FW: Protocol Action: 'YANG - A data modeling language for the NetworkConfiguration Protocol (NETCONF)' to Proposed Standard 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, 10 Jun 2010 10:39:49 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 >=20 > Yes, and now it is time to write those data models ;-) >=20 Yes! Your AD is waiting for the concrete proposals on this respect. There are 45 days left until IETF-78. There are 25 days left until the Internet Draft Cut-off for initial document (-00) submission. Thanks and Regards, Dan From wwwrun@core3.amsl.com Thu Jun 10 09:18:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 90A253A6A16; Thu, 10 Jun 2010 09:18:01 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100610161801.90A253A6A16@core3.amsl.com> Date: Thu, 10 Jun 2010 09:18:01 -0700 (PDT) X-Mailman-Approved-At: Thu, 10 Jun 2010 09:30:48 -0700 Cc: Internet Architecture Board , netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'Common YANG Data Types' to Proposed Standard 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, 10 Jun 2010 16:18:01 -0000 The IESG has approved the following document: - 'Common YANG Data Types ' as a Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-09.txt Technical Summary YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol. The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. This document introduces a collection of common data types derived from the built-in YANG data types. The definitions are organized in several YANG modules. The "ietf-yang-types" module contains generally useful data types. The "ietf-inet-types" module contains definitions that are relevant for the Internet protocol suite. Working Group Summary Consensus was reached among all interested parties before requesting the publication of this document. Document Quality There are multiple independent implementations of YANG today, both commercial and freely-available code and verification tools. Personnel David Partain is the document shepherd. Dan Romascanu is the responsible AD. RFC Editor Note Section 3., paragraph 45: OLD: typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|[\+|-]\d{2}:\d{2})'; } description "The date-and-time type is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. The profile is defined by the date-time production in section 5.6 of RFC 3339. NEW: typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' + '(Z|[\+\-]\d{2}:\d{2})'; } description "The date-and-time type is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. The profile is defined by the date-time production in section 5.6 of RFC 3339. From david.partain@ericsson.com Thu Jun 10 13:20:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5E128C115 for ; Thu, 10 Jun 2010 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2Fj5Csnop1G for ; Thu, 10 Jun 2010 13:20:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CEC4B3A6784 for ; Thu, 10 Jun 2010 13:20:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-48-4c114914eb82 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A6.6B.29106.419411C4; Thu, 10 Jun 2010 22:20:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 22:20:36 +0200 Received: from selic022.lmera.ericsson.se ([150.132.89.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 22:20:36 +0200 From: David Partain Organization: Ericsson To: netmod mailing list Date: Thu, 10 Jun 2010 22:20:35 +0200 User-Agent: KMail/1.9.10 References: <20100610161801.90A253A6A16@core3.amsl.com> In-Reply-To: <20100610161801.90A253A6A16@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201006102220.35387.david.partain@ericsson.com> X-OriginalArrivalTime: 10 Jun 2010 20:20:36.0131 (UTC) FILETIME=[62A8BF30:01CB08DA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Protocol Action: 'Common YANG Data Types' to Proposed Standard 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, 10 Jun 2010 20:20:38 -0000 On Thursday 10 June 2010 18.18.01 The IESG wrote: > The IESG has approved the following document: > > - 'Common YANG Data Types ' > as a Proposed Standard Hi, Two in two days! Excellent work, folks! Cheers, David From bertietf@bwijnen.net Mon Jun 14 01:16:14 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D263A6886 for ; Mon, 14 Jun 2010 01:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=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 a8EuEJfEy7kc for ; Mon, 14 Jun 2010 01:16:13 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 7B2513A67B2 for ; Mon, 14 Jun 2010 01:16:10 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OO4pz-0004PU-8a for netmod@ietf.org; Mon, 14 Jun 2010 10:16:12 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-103.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OO4pz-0005qW-5Y for netmod@ietf.org; Mon, 14 Jun 2010 10:16:07 +0200 Message-ID: <4C15E547.7040102@bwijnen.net> Date: Mon, 14 Jun 2010 10:16:07 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netmod Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48919d9d3302139587323b60db4e3d160 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48919d9d3302139587323b60db4e3d160 Subject: [netmod] [Fwd: 5th draft for yang module security considerations] 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, 14 Jun 2010 08:16:14 -0000 Since the 4th draft, we have been informed of one typo that is fixed in this revision. Further, the security ADs wanted something added about secure transport of the data, and the secdir review of the netconf-monitoring draft also had questions about that. As a result, Juergen Schoenwaelder has suggested to add some text about that. The resulting text is now as below. Bert --- draft 5 for tang module security considerations: Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then the security considerations of each new RPC operation MUST be explained. X. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. -- if you have any writeable data nodes (those are all the -- "config true" nodes, and remember, that is the default) -- describe their specific sensitivity or vulnerability. There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e. config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g. edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: From bwijnen@ripe.net Mon Jun 14 01:09:14 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7473A6881 for ; Mon, 14 Jun 2010 01:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 b+idlcuPw+78 for ; Mon, 14 Jun 2010 01:09:12 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 1A9D13A67B2 for ; Mon, 14 Jun 2010 01:09:11 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OO4jD-0000M4-7b for netmod@ietf.org; Mon, 14 Jun 2010 10:09:12 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-103.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OO4jD-0005dZ-3P for netmod@ietf.org; Mon, 14 Jun 2010 10:09:07 +0200 Message-ID: <4C15E39E.6060502@ripe.net> Date: Mon, 14 Jun 2010 10:09:02 +0200 From: Bert Wijnen User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netmod Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e187280a6049d9ab23a60169dfb260126 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e187280a6049d9ab23a60169dfb260126 X-Mailman-Approved-At: Mon, 14 Jun 2010 01:22:45 -0700 Subject: [netmod] 5th draft for yang module security considerations 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, 14 Jun 2010 08:09:14 -0000 Since the 4th draft, we have been informed of one typo that is fixed in this revision. Further, the security ADs wanted something added about secure transport of the data, and the secdir review of the netconf-monitoring draft also had questions about that. As a result, Juergen Schoenwaelder has suggested to add some text about that. The resulting text is now as below. Bert --- draft 5 for tang module security considerations: Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then the security considerations of each new RPC operation MUST be explained. X. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. -- if you have any writeable data nodes (those are all the -- "config true" nodes, and remember, that is the default) -- describe their specific sensitivity or vulnerability. There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e. config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g. edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: From bertietf@bwijnen.net Mon Jun 14 23:46:53 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210083A6862 for ; Mon, 14 Jun 2010 23:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_50=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 eK3icnF13mxu for ; Mon, 14 Jun 2010 23:46:51 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 753D03A6809 for ; Mon, 14 Jun 2010 23:46:48 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OOPv3-0001OK-EB for netmod@ietf.org; Tue, 15 Jun 2010 08:46:50 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OOPv3-0003kC-8W for netmod@ietf.org; Tue, 15 Jun 2010 08:46:45 +0200 Message-ID: <4C1721D2.2030106@bwijnen.net> Date: Tue, 15 Jun 2010 08:46:42 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netmod Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a112fa2fe934772ef23b943946fe1972 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a112fa2fe934772ef23b943946fe1972 Subject: [netmod] Citations, reference clause in YANG and RFC References section 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, 15 Jun 2010 06:46:53 -0000 FYI and comments I am sending a disucssion we had with a few people as a result of a comment from an IESG memeber. Bert > -----Original Message----- > From: ext Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Monday, June 14, 2010 4:03 PM > To: bertietf@bwijnen.net > Cc: Ersue, Mehmet (NSN - DE/Munich); dromasca@avaya.com; > j.schoenwaelder@jacobs-university.de > Subject: Re: COMMENT: draft-ietf-netconf-monitoring > > [CC:ing Juergen also] > > "Bert (IETF) Wijnen" wrote: > > Inline > > > > Martin Bjorklund wrote: > > > Hi Lars, > > > > > > Lars Eggert wrote: > > > > > >> Comment: > > >> Contains several unused references. > > >> > > > > > > The other references are referenced from the YANG module, > > > like this: > > > > > > identity netconf-tls { > > > base transport; > > > description > > > "NETCONF over Transport Layer Security (TLS)."; > > > reference > > > "RFC 5539: NETCONF over Transport Layer Security (TLS)"; > > > } > > > > > > > We had similar things in MIB modules. > > We did not want a citation in the REF (in yang reference) > > clause. But the RFC-Editor DOES want > > the citation if a document is listed in the references. > > The way we solved that for MIB modules is to have some text > > just before the MIB module itself, > > which states something aka: > > > > In the following MIB module, references are made to > > SMIv2 [RFC2578] and Texttual Convention [RFC2579]. > > > > Maybe this approach would be workable for YANG modules too ? > > Right, I realized this. The yang-types document has similar issues; > it is of course now in the RFC editor queue, so I guess we'll see if > they will complain... > > A related problem, which might be solved by having a section like the > one you suggest, is that the YANG module has: > > import ietf-yang-types { prefix yang; } > > and then a normative reference to the yang-types RFC. But it is not > easy to understand that the import actually references the yang-types > RFC. > > Whatever the solution is, the YANG guidelines document should be > updated. > > > /martin > > > > Bert From dromasca@avaya.com Tue Jun 15 07:04:57 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B283A6A2F; Tue, 15 Jun 2010 07:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_50=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 Ya6gIzHi9H43; Tue, 15 Jun 2010 07:04:56 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id E4D753A690F; Tue, 15 Jun 2010 07:04:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,420,1272859200"; d="scan'208";a="193542289" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2010 10:04:58 -0400 X-IronPort-AV: E=Sophos;i="4.53,420,1272859200"; d="scan'208";a="472625263" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jun 2010 10:04:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2010 16:04:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Thread-Index: AcsMkzHeLgW5wNcqTr+c/glb3tQlmAAAGCNQ From: "Romascanu, Dan (Dan)" To: , Subject: [netmod] FW: FW: [Fwd: 5th draft for yang module security considerations] 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, 15 Jun 2010 14:04:57 -0000 The Security AD's approved the text for the security considerations as per the 5th draft.=20 Dan -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Tuesday, June 15, 2010 5:01 PM To: Romascanu, Dan (Dan) Cc: tim.polk@nist.gov; bertietf@bwijnen.net; mehmet.ersue@nsn.com; David Partain; David Kessens Subject: Re: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Dan, Tim and I talked about this this morning and we're happy with the text. spt Romascanu, Dan (Dan) wrote: > =20 >=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On=20 > Behalf Of Bert (IETF) Wijnen > Sent: Monday, June 14, 2010 11:16 AM > To: netmod Working Group > Subject: [netmod] [Fwd: 5th draft for yang module security=20 > considerations] >=20 > Since the 4th draft, we have been informed of one typo that is fixed=20 > in this revision. >=20 > Further, the security ADs wanted something added about secure=20 > transport of the data, and the secdir review of the netconf-monitoring > draft also had questions about that. As a result, Juergen=20 > Schoenwaelder has suggested to add some text about that. >=20 > The resulting text is now as below. >=20 > Bert >=20 > --- draft 5 for tang module security considerations: >=20 > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). >=20 > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. >=20 > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. >=20 > Further, if new RPC operations have been defined, > then the security considerations of each new > RPC operation MUST be explained. >=20 > X. Security Considerations >=20 > The YANG module defined in this memo is designed to be accessed via=20 > the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure > transport layer and the mandatory to implement secure transport is SSH > [RFC4742]. >=20 > -- if you have any writeable data nodes (those are all the > -- "config true" nodes, and remember, that is the default) > -- describe their specific sensitivity or vulnerability. >=20 > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the default). > These data nodes may be considered sensitive or vulnerable in some=20 > network environments. Write operations (e.g. edit-config) to these=20 > data nodes without proper protection can have a negative effect on=20 > network operations. These are the subtrees and data nodes and their > sensitivity/vulnerability: >=20 > >=20 > -- for all YANG modules you must evaluate whether any readable data > -- nodes (those are all the "config false" nodes, but also all other > -- nodes, because they can also be read via operations like get or > -- get-config) are sensitive or vulnerable (for instance, if they > -- might reveal customer information or violate personal privacy > -- laws such as those of the European Union if exposed to > -- unauthorized parties) >=20 > Some of the readable data nodes in this YANG module may be considered=20 > sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, get-config=20 > or > notification) to these data nodes. These are the subtrees and data=20 > nodes and their sensitivity/vulnerability: >=20 > >=20 > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. >=20 > Some of the RPC operations in this YANG module may be considered=20 > sensitive or vulnerable in some network environments. It is thus=20 > important to control access to these operations. These are the=20 > operations and their sensitivity/vulnerability: >=20 > >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From bertietf@bwijnen.net Tue Jun 15 07:09:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF3C3A690F for ; Tue, 15 Jun 2010 07:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] 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 NTdmACBu1y7w for ; Tue, 15 Jun 2010 07:09:27 -0700 (PDT) Received: from relay.versatel.net (relay61.tele2.vuurwerk.nl [62.250.3.61]) by core3.amsl.com (Postfix) with ESMTP id F1A7D3A68E9 for ; Tue, 15 Jun 2010 07:09:26 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OOWpV-00048X-Q8 for netmod@ietf.org; Tue, 15 Jun 2010 16:09:30 +0200 Message-ID: <00771498742A4AD0824741E586801D62@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "NETMOD Working Group" Date: Tue, 15 Jun 2010 16:02:56 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [netmod] Fw: FW: [Fwd: 5th draft for yang module security considerations] 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, 15 Jun 2010 14:09:28 -0000 So it seems that the SEcurit ADs are happy with revision 5 of the text. I think that means we are done. Dan, do you agree? bert ----- Original Message ----- From: "Sean Turner" To: "Romascanu, Dan (Dan)" Cc: ; ; ; "David Partain" ; "David Kessens" Sent: Tuesday, June 15, 2010 4:00 PM Subject: Re: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Dan, Tim and I talked about this this morning and we're happy with the text. spt Romascanu, Dan (Dan) wrote: > > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Bert (IETF) Wijnen > Sent: Monday, June 14, 2010 11:16 AM > To: netmod Working Group > Subject: [netmod] [Fwd: 5th draft for yang module security > considerations] > > Since the 4th draft, we have been informed of one typo that is fixed in > this revision. > > Further, the security ADs wanted something added about secure transport > of the data, and the secdir review of the netconf-monitoring draft also > had questions about that. As a result, Juergen Schoenwaelder has > suggested to add some text about that. > > The resulting text is now as below. > > Bert > > --- draft 5 for tang module security considerations: > > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). > > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. > > Further, if new RPC operations have been defined, > then the security considerations of each new > RPC operation MUST be explained. > > X. Security Considerations > > The YANG module defined in this memo is designed to be accessed via the > NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure > transport layer and the mandatory to implement secure transport is SSH > [RFC4742]. > > -- if you have any writeable data nodes (those are all the > -- "config true" nodes, and remember, that is the default) > -- describe their specific sensitivity or vulnerability. > > There are a number of data nodes defined in this YANG module which are > writable/creatable/deletable (i.e. config true, which is the default). > These data nodes may be considered sensitive or vulnerable in some > network environments. Write operations (e.g. edit-config) to these data > nodes without proper protection can have a negative effect on network > operations. These are the subtrees and data nodes and their > sensitivity/vulnerability: > > > > -- for all YANG modules you must evaluate whether any readable data > -- nodes (those are all the "config false" nodes, but also all other > -- nodes, because they can also be read via operations like get or > -- get-config) are sensitive or vulnerable (for instance, if they > -- might reveal customer information or violate personal privacy > -- laws such as those of the European Union if exposed to > -- unauthorized parties) > > Some of the readable data nodes in this YANG module may be considered > sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, get-config or > notification) to these data nodes. These are the subtrees and data > nodes and their sensitivity/vulnerability: > > > > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. > > Some of the RPC operations in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control access to these operations. These are the > operations and their sensitivity/vulnerability: > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From dromasca@avaya.com Tue Jun 15 07:11:19 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11DD3A6A63 for ; Tue, 15 Jun 2010 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 iMGi9Mi+gUOF for ; Tue, 15 Jun 2010 07:11:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9400B3A6A6D for ; Tue, 15 Jun 2010 07:11:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,420,1272859200"; d="scan'208";a="223138616" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jun 2010 10:11:19 -0400 X-IronPort-AV: E=Sophos;i="4.53,420,1272859200"; d="scan'208";a="472627782" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jun 2010 10:11:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2010 16:10:57 +0200 Message-ID: In-Reply-To: <00771498742A4AD0824741E586801D62@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Fw: FW: [Fwd: 5th draft for yang module securityconsiderations] Thread-Index: AcsMlGPm3DumR/z0SlCw1xKU8uiVGAAABG1g References: <00771498742A4AD0824741E586801D62@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "NETMOD Working Group" Subject: Re: [netmod] Fw: FW: [Fwd: 5th draft for yang module securityconsiderations] 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, 15 Jun 2010 14:11:19 -0000 Yes.=20 We should find the way to update the OPS Area Web page.=20 Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Tuesday, June 15, 2010 5:03 PM > To: NETMOD Working Group > Subject: [netmod] Fw: FW: [Fwd: 5th draft for yang module=20 > securityconsiderations] >=20 > So it seems that the SEcurit ADs are happy with revision 5 of=20 > the text. >=20 > I think that means we are done. >=20 > Dan, do you agree? >=20 > bert > ----- Original Message ----- > From: "Sean Turner" > To: "Romascanu, Dan (Dan)" > Cc: ; ;=20 > ; "David Partain"=20 > ; "David Kessens"=20 > > Sent: Tuesday, June 15, 2010 4:00 PM > Subject: Re: FW: [netmod] [Fwd: 5th draft for yang module=20 > security considerations] >=20 >=20 > Dan, >=20 > Tim and I talked about this this morning and we're happy with=20 > the text. >=20 > spt >=20 > Romascanu, Dan (Dan) wrote: > > > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On=20 > > Behalf Of Bert (IETF) Wijnen > > Sent: Monday, June 14, 2010 11:16 AM > > To: netmod Working Group > > Subject: [netmod] [Fwd: 5th draft for yang module security=20 > > considerations] > > > > Since the 4th draft, we have been informed of one typo that=20 > is fixed=20 > > in this revision. > > > > Further, the security ADs wanted something added about secure=20 > > transport of the data, and the secdir review of the=20 > netconf-monitoring=20 > > draft also had questions about that. As a result, Juergen=20 > > Schoenwaelder has suggested to add some text about that. > > > > The resulting text is now as below. > > > > Bert > > > > --- draft 5 for tang module security considerations: > > > > Each specification that defines one or more YANG > > modules MUST contain a section that discusses > > security considerations relevant to those modules. > > This section MUST be patterned after the latest > > approved template (available at [ed: URL TBD]). > > > > In particular, writable data nodes that could > > be especially disruptive if abused MUST be > > explicitly listed by name and the associated > > security risks MUST be spelled out. > > > > Similarly, readable data nodes that contain > > especially sensitive information or that raise > > significant privacy concerns MUST be explicitly > > listed by name and the reasons for the > > sensitivity/privacy concerns MUST be explained. > > > > Further, if new RPC operations have been defined, > > then the security considerations of each new > > RPC operation MUST be explained. > > > > X. Security Considerations > > > > The YANG module defined in this memo is designed to be accessed via=20 > > the NETCONF protocol [RFC4741]. The lowest NETCONF layer is=20 > the secure=20 > > transport layer and the mandatory to implement secure=20 > transport is SSH=20 > > [RFC4742]. > > > > -- if you have any writeable data nodes (those are all the > > -- "config true" nodes, and remember, that is the default) > > -- describe their specific sensitivity or vulnerability. > > > > There are a number of data nodes defined in this YANG=20 > module which are=20 > > writable/creatable/deletable (i.e. config true, which is=20 > the default). > > These data nodes may be considered sensitive or vulnerable in some=20 > > network environments. Write operations (e.g. edit-config) to these=20 > > data nodes without proper protection can have a negative effect on=20 > > network operations. These are the subtrees and data nodes and their > > sensitivity/vulnerability: > > > > > > > > -- for all YANG modules you must evaluate whether any readable data > > -- nodes (those are all the "config false" nodes, but also all other > > -- nodes, because they can also be read via operations like get or > > -- get-config) are sensitive or vulnerable (for instance, if they > > -- might reveal customer information or violate personal privacy > > -- laws such as those of the European Union if exposed to > > -- unauthorized parties) > > > > Some of the readable data nodes in this YANG module may be=20 > considered=20 > > sensitive or vulnerable in some network environments. > > It is thus important to control read access (e.g. via get,=20 > get-config=20 > > or > > notification) to these data nodes. These are the subtrees and data=20 > > nodes and their sensitivity/vulnerability: > > > > > > > > -- if your YANG module has defined any rpc operations > > -- describe their specific sensitivity or vulnerability. > > > > Some of the RPC operations in this YANG module may be considered=20 > > sensitive or vulnerable in some network environments. It is thus=20 > > important to control access to these operations. These are the=20 > > operations and their sensitivity/vulnerability: > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From phil@juniper.net Wed Jun 16 12:59:59 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2E428C16C for ; Wed, 16 Jun 2010 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oaXvAP22tkn for ; Wed, 16 Jun 2010 12:59:58 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 6818828C168 for ; Wed, 16 Jun 2010 12:59:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTBktPLmCCFckvmMsyR4TllUEuy1m1Nzp@postini.com; Wed, 16 Jun 2010 13:00:03 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Wed, 16 Jun 2010 12:58:07 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 12:58:07 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 12:58:07 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 12:58:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o5GJw5D01382; Wed, 16 Jun 2010 12:58:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5GJeGAm002414; Wed, 16 Jun 2010 19:40:17 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006161940.o5GJeGAm002414@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100518073950.GB11495@elstar.local> Date: Wed, 16 Jun 2010 15:40:16 -0400 From: Phil Shafer X-OriginalArrivalTime: 16 Jun 2010 19:58:06.0916 (UTC) FILETIME=[3CF16040:01CB0D8E] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-05.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: Wed, 16 Jun 2010 19:59:59 -0000 Juergen Schoenwaelder writes: >this is my WG last call review of . Many thanks for the comments. All have been made except the following: >d) p4: Did operators really ask for "low implementation costs"? I > would understand if they ask for "low deployment costs" - low > implementation costs is something vendors usually worry about. The term "implementation costs" is used in rfc3535, so assumably the workshoppers were comfortable with this term: 5. Consolidated Observations ... 16. The implementation costs have to be low on devices. 17. The implementation costs have to be low on managers. >r) p9: I would replace the import with two imports since that is a > more likely organization > > import ospf-types { prefix ospf-types; } > import interface-types { prefix if-types; } > > and then use ospf-types:area-id and if-types:interface-name. The example refers to nodes, not types, so I'm leaving it unchanged. >z) p14: Add a new section "2.X Usage Guidelines" that briefly points > to the usage guidelines document and explains that these > guidelines must be followed by (IETF) standard data models. I could not find suitable words in the current rev, so I made up some words: ** IETF Guidelines A set of additional guidelines are defined that indicate desirable usage for authors and reviewers of standards track specifications containing YANG data model modules (^RFCYANGUSAGE^). These guidelines should be used as a basis for reviews of other YANG data model documents. >W) p19: Should the section describing the device modeler not mention > that the developer should write deviation statements in cases > where his implementation puts restrictions on the data model? I'm iffy here, since we want to discourage deviations. >5) p27: Add the following section: > > 4.3.3.4 Introduction of Meta-Data Tags > > The NETCONF protocol might be extended to carry meta-data tags > (for example encoded in XML attributes) that identify whether an > XML element carries configuration data, operational state data, > or statistical data. This approach allows responses to > operations to contain mixed data, making it easy for clients to > separate configuration data from operational state data. Servers > may be allowed to skip over any non-config data supplied by > clients in or operations. I do not want to add this text, since this not a workable solution in the current YANG/NETCONF world. We certainly don't want to encourage modelers to step in this direction at this time. >6) p27: Does section 4.3 belong into this document? Unfortunately, as > long as the WGs have not converged to a solution, I believe it > is necessary to keep this text since we right now leave it to > the data modelers to figure out what to do. I believe this is > actually a bad idea but lets be honest about it. Section 4.3 was added at your request. I am not happy with it, since it doesn't contain any useful direction to modelers other than "we don't know either". I'd be happy to remove it, if that is the concensus of the WG. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Jun 16 14:42:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B6F28C198 for ; Wed, 16 Jun 2010 14:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 4SyCt66ZNHsk for ; Wed, 16 Jun 2010 14: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 3466028C192 for ; Wed, 16 Jun 2010 14:42:30 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D362AC0004; Wed, 16 Jun 2010 23:42:34 +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 CwLwAyvMVOaC; Wed, 16 Jun 2010 23:42:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40604C0007; Wed, 16 Jun 2010 23:42:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 090541341071; Wed, 16 Jun 2010 23:42:27 +0200 (CEST) Date: Wed, 16 Jun 2010 23:42:27 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100616214227.GA12869@elstar.local> Mail-Followup-To: Phil Shafer , "netmod@ietf.org" References: <20100518073950.GB11495@elstar.local> <201006161940.o5GJeGAm002414@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006161940.o5GJeGAm002414@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of draft-ietf-netmod-arch-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 21:42:31 -0000 On Wed, Jun 16, 2010 at 09:40:16PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >this is my WG last call review of . > > Many thanks for the comments. All have been made except the following: > > >d) p4: Did operators really ask for "low implementation costs"? I > > would understand if they ask for "low deployment costs" - low > > implementation costs is something vendors usually worry about. > > The term "implementation costs" is used in rfc3535, so assumably > the workshoppers were comfortable with this term: > 5. Consolidated Observations > ... > 16. The implementation costs have to be low on devices. > 17. The implementation costs have to be low on managers. The workshop was not just attended by operators, see RFC 3535 for the details. The sentence in question talks about operators, not the workshop attendees and thus my question remains valid. > >W) p19: Should the section describing the device modeler not mention > > that the developer should write deviation statements in cases > > where his implementation puts restrictions on the data model? > > I'm iffy here, since we want to discourage deviations. I thought we introduced the deviation statement since we believe a honest description of what an implementation does is worth to have. So if there are deviations, I think they should be documented. Or are you saying that it is better to not document them? > >5) p27: Add the following section: > > > > 4.3.3.4 Introduction of Meta-Data Tags > > > > The NETCONF protocol might be extended to carry meta-data tags > > (for example encoded in XML attributes) that identify whether an > > XML element carries configuration data, operational state data, > > or statistical data. This approach allows responses to > > operations to contain mixed data, making it easy for clients to > > separate configuration data from operational state data. Servers > > may be allowed to skip over any non-config data supplied by > > clients in or operations. > > I do not want to add this text, since this not a workable solution > in the current YANG/NETCONF world. We certainly don't want to > encourage modelers to step in this direction at this time. We do exactly this now to identify defaults in explicit config implementations - so if this is not workable, we should remove the attributes from with-defaults. > >6) p27: Does section 4.3 belong into this document? Unfortunately, as > > long as the WGs have not converged to a solution, I believe it > > is necessary to keep this text since we right now leave it to > > the data modelers to figure out what to do. I believe this is > > actually a bad idea but lets be honest about it. > > Section 4.3 was added at your request. I am not happy with it, > since it doesn't contain any useful direction to modelers other > than "we don't know either". I'd be happy to remove it, if that > is the concensus of the WG. My preference would be that 4.3 is not needed. However, since we do not seem to move into the direction of answering the question how we prefer to represent operational state, the second best choice for me still is to make the problem clear and to describe the solution space. This will help data modelers to understand the issue and pick one of the solutions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jun 16 17:46:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E720B28C1B1 for ; Wed, 16 Jun 2010 17:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIlJOsrm+vn7 for ; Wed, 16 Jun 2010 17:46:16 -0700 (PDT) Received: from smtp185.dfw.emailsrvr.com (smtp185.dfw.emailsrvr.com [67.192.241.185]) by core3.amsl.com (Postfix) with ESMTP id D382F3A6984 for ; Wed, 16 Jun 2010 17:46:15 -0700 (PDT) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id CEE0A16F1EFC; Wed, 16 Jun 2010 18:19:23 -0400 (EDT) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 87A1C16F1D04; Wed, 16 Jun 2010 18:19:23 -0400 (EDT) Message-ID: <4C194DA0.4020606@iwl.com> Date: Wed, 16 Jun 2010 15:18:08 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer , "netmod@ietf.org" References: <20100518073950.GB11495@elstar.local> <201006161940.o5GJeGAm002414@idle.juniper.net> <20100616214227.GA12869@elstar.local> In-Reply-To: <20100616214227.GA12869@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] js review of draft-ietf-netmod-arch-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 00:46:17 -0000 On 06/16/2010 02:42 PM, Juergen Schoenwaelder wrote: > On Wed, Jun 16, 2010 at 09:40:16PM +0200, Phil Shafer wrote: > >> Juergen Schoenwaelder writes: >> >>> this is my WG last call review of . >>> >> Many thanks for the comments. All have been made except the following: >> >> >>> d) p4: Did operators really ask for "low implementation costs"? I >>> would understand if they ask for "low deployment costs" - low >>> implementation costs is something vendors usually worry about. >>> >> The term "implementation costs" is used in rfc3535, so assumably >> the workshoppers were comfortable with this term: >> > >> 5. Consolidated Observations >> ... >> 16. The implementation costs have to be low on devices. >> 17. The implementation costs have to be low on managers. >> > > The workshop was not just attended by operators, see RFC 3535 for the > details. The sentence in question talks about operators, not the > workshop attendees and thus my question remains valid. > > >>> W) p19: Should the section describing the device modeler not mention >>> that the developer should write deviation statements in cases >>> where his implementation puts restrictions on the data model? >>> >> I'm iffy here, since we want to discourage deviations. >> > I thought we introduced the deviation statement since we believe a > honest description of what an implementation does is worth to have. > So if there are deviations, I think they should be documented. Or > are you saying that it is better to not document them? > > >>> 5) p27: Add the following section: >>> >>> 4.3.3.4 Introduction of Meta-Data Tags >>> >>> The NETCONF protocol might be extended to carry meta-data tags >>> (for example encoded in XML attributes) that identify whether an >>> XML element carries configuration data, operational state data, >>> or statistical data. This approach allows responses to >>> operations to contain mixed data, making it easy for clients to >>> separate configuration data from operational state data. Servers >>> may be allowed to skip over any non-config data supplied by >>> clients in or operations. >>> >> I do not want to add this text, since this not a workable solution >> in the current YANG/NETCONF world. We certainly don't want to >> encourage modelers to step in this direction at this time. >> > We do exactly this now to identify defaults in explicit config > implementations - so if this is not workable, we should remove the > attributes from with-defaults. > > >>> 6) p27: Does section 4.3 belong into this document? Unfortunately, as >>> long as the WGs have not converged to a solution, I believe it >>> is necessary to keep this text since we right now leave it to >>> the data modelers to figure out what to do. I believe this is >>> actually a bad idea but lets be honest about it. >>> >> Section 4.3 was added at your request. I am not happy with it, >> since it doesn't contain any useful direction to modelers other >> than "we don't know either". I'd be happy to remove it, if that >> is the concensus of the WG. >> > My preference would be that 4.3 is not needed. However, since we do > not seem to move into the direction of answering the question how we > prefer to represent operational state, the second best choice for me > still is to make the problem clear and to describe the solution space. > This will help data modelers to understand the issue and pick one of > the solutions. > > I do not think the NETCONF WG or the NETMOD WG has agreed on any standard classifications for data nodes other than the YANG config-stmt (=T/F). If people think the NETCONF operation set is wrong they should post comments on 4741bis. As it stands, if the operator is allowed to alter the value of a data node, it better be config=true. If the operator is never allowed to alter the value of operational data, then it really is config=false, and it has to be returned in a operation. We have known for years that there is stuff that falls in between, and have always decided not to bother doing anything about it. Why it this the time, especially since YANG considered this and rejected it, insisting that config-state is a boolean. I don't think sec. 4.3 belongs in this Informational document. If any standard NETCONF behavior related to operational state is ever done, then these definitions can be added then. > /js > > Andy From phil@juniper.net Wed Jun 16 22:41:59 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F276D3A67B7 for ; Wed, 16 Jun 2010 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 NZX5ZbDvL9cQ for ; Wed, 16 Jun 2010 22:41:50 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 54FFB3A6832 for ; Wed, 16 Jun 2010 22:41:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTBm1nznOVKk1nUfQan+wMuwJTxPn4nPK@postini.com; Wed, 16 Jun 2010 22:41:54 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 16 Jun 2010 22:34:58 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 22:34:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 22:34:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 22:34:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o5H5YuD45373; Wed, 16 Jun 2010 22:34:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5H5H7Ca006109; Thu, 17 Jun 2010 05:17:08 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006170517.o5H5H7Ca006109@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100616214227.GA12869@elstar.local> Date: Thu, 17 Jun 2010 01:17:07 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Jun 2010 05:34:57.0752 (UTC) FILETIME=[D29BD580:01CB0DDE] MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of draft-ietf-netmod-arch-05.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: Thu, 17 Jun 2010 05:41:59 -0000 Juergen Schoenwaelder writes: >The workshop was not just attended by operators, see RFC 3535 for the >details. The sentence in question talks about operators, not the >workshop attendees and thus my question remains valid. I'll change "operator's needs" to "observations". >I thought we introduced the deviation statement since we believe a >honest description of what an implementation does is worth to have. >So if there are deviations, I think they should be documented. Or >are you saying that it is better to not document them? Nope, just that I think this needs to be discussed in the section dedicated to it, instead of an brief mention earlier in the doc. >We do exactly this now to identify defaults in explicit config >implementations - so if this is not workable, we should remove the >attributes from with-defaults. The other three options can be chosen and implemented within the current NETCONF/YANG framework with little effort. The introduction of these attributes is not a valid choice for the modeler. In fact, the first option ("data models that explicitly differentiate between configuration data and operational state data") is probably the only realistic choice for modelers. >My preference would be that 4.3 is not needed. However, since we do >not seem to move into the direction of answering the question how we >prefer to represent operational state, the second best choice for me >still is to make the problem clear and to describe the solution space. >This will help data modelers to understand the issue and pick one of >the solutions. Given that we can't agree sufficiently to give guidance, how will this section help the typical modeler. This section reads more like an apologist view of why this issue is hard and why we didn't decide, but I'm not sure that has any real value to our audience. Perhaps the best fix is to add a conclusion that gives the "explicitly differentiated" as the only realistic current answer and push modelers in this direction. Thanks, Phil From root@core3.amsl.com Wed Jun 16 22:45:18 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EF1F43A6832; Wed, 16 Jun 2010 22:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100617054511.EF1F43A6832@core3.amsl.com> Date: Wed, 16 Jun 2010 22:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-06.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: Thu, 17 Jun 2010 05:45:18 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : An Architecture for Network Management using NETCONF and YANG Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-06.txt Pages : 33 Date : 2010-06-16 NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-arch-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-16224349.I-D@ietf.org> --NextPart-- From david.partain@ericsson.com Wed Jun 16 23:32:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98373A6A0C for ; Wed, 16 Jun 2010 23:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-2.650, BAYES_50=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 qZzXr0UnO8K3 for ; Wed, 16 Jun 2010 23:32:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B5C823A6A14 for ; Wed, 16 Jun 2010 23:32:27 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-5d-4c19c17e4412 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.53.06817.E71C91C4; Thu, 17 Jun 2010 08:32:30 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jun 2010 08:32:30 +0200 Received: from selic022.lmera.ericsson.se ([150.132.89.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jun 2010 08:32:29 +0200 Content-Language: en-US Content-Disposition: inline From: David Partain Organization: Ericsson To: netmod@ietf.org Date: Thu, 17 Jun 2010 08:32:29 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006170832.29294.david.partain@ericsson.com> X-OriginalArrivalTime: 17 Jun 2010 06:32:29.0882 (UTC) FILETIME=[DC3D11A0:01CB0DE6] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: An Architecture for Network Management using NETCONF and 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, 17 Jun 2010 06:32:28 -0000 Greetings, This is an one-week working group last call on the current working group document: Title: An Architecture for Network Management using NETCONF and YANG URL: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-06.txt Delta from previous revision: http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-arch-06.txt This WGLC will end on June 24, 2010. Please review the document and post your comments on the mailing list. Please use an appropriate Subject line so that the chairs and editor can easily keep track of the issues that need to be dealt with. This is a sanity-check WGLC since we've had a WGLC before. Thanks to Phil for getting the new revision out! Assuming no dramatic issues, this document will be shipped to the IESG shortly after the end of the WGLC. Thanks. David^2 From mbj@tail-f.com Wed Jun 16 23:37:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD1C3A6A0F for ; Wed, 16 Jun 2010 23:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.116 X-Spam-Level: X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, 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 iaWytf4ufNhR for ; Wed, 16 Jun 2010 23:37:49 -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 0E72E3A6833 for ; Wed, 16 Jun 2010 23:37:49 -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 DC09F616001 for ; Thu, 17 Jun 2010 08:37:52 +0200 (CEST) Date: Thu, 17 Jun 2010 08:37:52 +0200 (CEST) Message-Id: <20100617.083752.262317937.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20100617054511.EF1F43A6832@core3.amsl.com> References: <20100617054511.EF1F43A6832@core3.amsl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action:draft-ietf-netmod-arch-06.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: Thu, 17 Jun 2010 06:37:49 -0000 Phil, One quick comment; I will check the rest in more detail later. Your table of NETCONF operations is really a table of junoscript operations... NETCONF has "lock", not "lock-configuration" etc. Also in the text just before the table you talk about "commit-configuration". It should be "commit". /martin From bwijnen@ripe.net Thu Jun 17 06:24:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602793A67B8 for ; Thu, 17 Jun 2010 06:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.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 Z2i3g7czds+f for ; Thu, 17 Jun 2010 06:24:32 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 7CA333A67D3 for ; Thu, 17 Jun 2010 06:24:32 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OPF4z-000228-9Y for netmod@ietf.org; Thu, 17 Jun 2010 15:24:35 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-42.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OPF4z-0006ff-2e for netmod@ietf.org; Thu, 17 Jun 2010 15:24:25 +0200 Message-ID: <4C1A2209.6080802@ripe.net> Date: Thu, 17 Jun 2010 15:24:25 +0200 From: Bert Wijnen User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netmod Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e88283516eb2ac5d036c57dedc5e1764d X-RIPE-Spam-Level: ---- X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e88283516eb2ac5d036c57dedc5e1764d X-Mailman-Approved-At: Thu, 17 Jun 2010 06:25:36 -0700 Subject: [netmod] Template for YANG Module documents security considereations 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, 17 Jun 2010 13:24:33 -0000 Simon has nicely put the text (as now agreed to by the security ADs) online. It is part of http://www.ops.ietf.org/netconf/#yang-guidelines and specifically can be found here: http://www.ops.ietf.org/netconf/yang-security-considerations.txt Bert, and thanks to Simon for putting it on the web pages From phil@juniper.net Thu Jun 17 07:52:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889593A6855 for ; Thu, 17 Jun 2010 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 9ZCDZa4lENSp for ; Thu, 17 Jun 2010 07:52:20 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 434C83A67D6 for ; Thu, 17 Jun 2010 07:52:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTBo2pkRBaWnyStw+g7YfUe9lcpbv2v/s@postini.com; Thu, 17 Jun 2010 07:52:25 PDT Received: from p-emfe03-sac.jnpr.net (66.129.254.75) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Thu, 17 Jun 2010 07:49:00 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe03-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 07:49:00 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jun 2010 07:48:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 07:48:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o5HEmwD01886; Thu, 17 Jun 2010 07:48:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5HEV9nk009691; Thu, 17 Jun 2010 14:31:09 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006171431.o5HEV9nk009691@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100617.083752.262317937.mbj@tail-f.com> Date: Thu, 17 Jun 2010 10:31:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Jun 2010 14:48:59.0574 (UTC) FILETIME=[38475560:01CB0E2C] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action:draft-ietf-netmod-arch-06.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: Thu, 17 Jun 2010 14:52:21 -0000 Martin Bjorklund writes: >Your table of NETCONF operations is really a table of junoscript >operations... NETCONF has "lock", not "lock-configuration" etc. Also >in the text just before the table you talk about >"commit-configuration". It should be "commit". Doh! Fixed.... Thanks, Phil From root@core3.amsl.com Sat Jun 19 06:00:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A9E953A692D; Sat, 19 Jun 2010 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100619130001.A9E953A692D@core3.amsl.com> Date: Sat, 19 Jun 2010 06:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-06.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: Sat, 19 Jun 2010 13:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-06.txt Pages : 111 Date : 2010-06-19 This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-dsdl-map-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-19055742.I-D@ietf.org> --NextPart-- From lhotka@cesnet.cz Sat Jun 19 06:05:20 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024DF3A6888 for ; Sat, 19 Jun 2010 06:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.072 X-Spam-Level: * X-Spam-Status: No, score=1.072 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 FL6Ru3dL1C22 for ; Sat, 19 Jun 2010 06:05:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id DE1B93A6847 for ; Sat, 19 Jun 2010 06:05:18 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id CB5812CDE058 for ; Sat, 19 Jun 2010 15:05:23 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 19 Jun 2010 15:05:22 +0200 Message-ID: <1276952722.8253.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: [netmod] [Fwd: New Version Notification for draft-ietf-netmod-dsdl-map-06] 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, 19 Jun 2010 13:05:20 -0000 Hi, this is the sixth revision of the DSDL mapping draft, based on the reviews by Martin Björklund and Jirka Kosek and also on my experience with the implementation in pyang. The mapping procedure has been considerably streamlined, so hopefully the text also became more readable. Lada -------- Přeposlaná zpráva -------- Od: IETF I-D Submission Tool Komu: lhotka@cesnet.cz Kopie: rohan@ekabal.com, schishol@nortel.com Předmět: New Version Notification for draft-ietf-netmod-dsdl-map-06 Datum: Sat, 19 Jun 2010 05:57:43 -0700 (PDT) A new version of I-D, draft-ietf-netmod-dsdl-map-06.txt has been successfully submitted by Ladislav Lhotka and posted to the IETF repository. Filename: draft-ietf-netmod-dsdl-map Revision: 06 Title: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Creation_date: 2010-06-19 WG ID: netmod Number_of_pages: 111 Abstract: This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed. The IETF Secretariat. -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Tue Jun 22 07:09:07 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471893A69A8 for ; Tue, 22 Jun 2010 07:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_50=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 I3RU2GYQbbNu for ; Tue, 22 Jun 2010 07:09:06 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C7A923A69A0 for ; Tue, 22 Jun 2010 07:09:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,460,1272859200"; d="scan'208";a="224319902" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jun 2010 10:09:12 -0400 X-IronPort-AV: E=Sophos;i="4.53,460,1272859200"; d="scan'208";a="474822191" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jun 2010 10:09:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 16:08:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-netmod-yang-usage-05.txt Thread-Index: AcsSFHThnwohaOtkQf26skae0pOUag== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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, 22 Jun 2010 14:09:07 -0000 Here are my comments on draft-ietf-netmod-yang-usage-05.txt. These are divided into Technical (marked T) and Editorial (marked E) comments. I believe that one more revision of the document that addresses these comments is necessary before proceeding to IETF Last Call.=20 Thanks and Regards, Dan T1. Running idnits results into the following warning.=20 =3D=3D Using lowercase 'not' together with uppercase 'MUST', = 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). =20 Found 'MUST not' in this paragraph: =20 Once a module name is published, it MUST not be reused, even if the RFC containing the module is reclassified to 'Historic' status. T2. I would add to the second paragraph in the Introduction section a phrase mentioning that while RFC 4181 was developped after more than one decade of writing and deploying MIB modules, this document is issued earlier in the YANG history, hence the hesitation of going directly to a BCP, although from many aspects the document looks like a BCP document.=20 T3. I suggest to add a phrase to the introduction about the target audience - future YANG modules writers and reviewers.=20 T4. Are there any exceptions that would justify using SHOULD rather than MUST in 3.1?=20 T5. Section 3.3 - 'These modules MUST be written in YANG'=20 Do we really need a MUST here? The document is already about documents that contain YANG modules, there is no need to repeat this. However, one may imagine documents that combine for example YANG modules with MIB modules - the MUST seems not to allow such a mix.=20 T6. Sections 3.4 and 6 and Appendix A point 4 - we already have approved security sections guidelines at http://www.ops.ietf.org/netconf/yang-security-considerations.txt T7. Section 3.5 - I suggest to add a phrase at the end of the section mentioning that for cases when there are no IANA section RFC 5226 allows to remove this section before the publication of the RFC>=20 T8. Section 3.5.1 - s/a new YANG Namespace registry entry must be requested from IANA/a new YANG Namespace registry entry MUST be requested from IANA/ T9. Section 4.1 s/MUST not/MUST NOT/ T10. Need to add a normative reference to XPATH T11. Section 4.7 - 'the document author contact information SHOULD be present' - many documents have multiple authors, usually only the contact information of one author is being included (at least with MIB modules).=20 T12. Section 4.8: Unless there is some good reason that I am missing: s/It is desirable to include only valid YANG modules in documents/It is RECOMMENDED to include only valid YANG modules in documents/ T13. Section 4.9:=20 There SHOULD only be one top-level data node defined in each YANG module. However, there MAY be more than one if needed. It would be good to describe an example of such a justified exception.=20 T14. Section 4.10:=20 For string data types, if the length of the string is required to bounded in all implementations, then a length statement SHOULD be present. s/SHOULD/MUST/=20 (or am I missing something?) T15. Section 4.11:=20 If the type definition semantics are defined in an external document, then the reference statement SHOULD be present. s/SHOULD/MUST/=20 (or am I missing something?) T16. Same comment for the similar text in 4.12 17. Same comment for the similar text about operations in 4.13 18. Same content for the similar text about notifications semantics in 4.14 19. Appendix A, point 5 - is it really true that an IANA section will always be present in a YANG module document? What about the case when we just define a submodule? RFC 5226 allows not to include an IANA Considerations section in an RFC if there are no IANA actions 20. Appendix A, point 9 - [ed.: online YANG validation tool URL TBD]. Should we rather consider here a pointer to a list of tools to be maintained on the OPS Area Web pages (or wiki)?=20 E1. The header of RFC 4181 is 'Guidelines for MIB documents'. Is there any special reason not to use a similar header (like 'Guidelines for YANG documents') for this document?=20 E2. in section 2.1, second paragraph s/regarding YANG module content/regarding YANG modules content/ E3. All over the document use consistently Internet-Draft rather than Internet Draft.=20 E4. in section 3.2 s/as MUST any special interpretations/as MUST be noted any special interpretations/ E5. section 3.7 - provide a reference for the TLP.=20 E6. section 4.2 - s/These includes/These include/ From andyb@iwl.com Tue Jun 22 08:13:38 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2B03A683A for ; Tue, 22 Jun 2010 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599, 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 TrIbEU69kHdO for ; Tue, 22 Jun 2010 08:13:36 -0700 (PDT) Received: from smtp165.dfw.emailsrvr.com (smtp165.dfw.emailsrvr.com [67.192.241.165]) by core3.amsl.com (Postfix) with ESMTP id D355F3A682E for ; Tue, 22 Jun 2010 08:13:36 -0700 (PDT) Received: from relay16.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 3024415295; Tue, 22 Jun 2010 11:13:44 -0400 (EDT) Received: by relay16.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E159815213; Tue, 22 Jun 2010 11:13:43 -0400 (EDT) Message-ID: <4C20D32F.8090906@iwl.com> Date: Tue, 22 Jun 2010 08:13:51 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 15:13:38 -0000 On 06/22/2010 07:08 AM, Romascanu, Dan (Dan) wrote: > Here are my comments on draft-ietf-netmod-yang-usage-05.txt. These are > divided into Technical (marked T) and Editorial (marked E) comments. I > believe that one more revision of the document that addresses these > comments is necessary before proceeding to IETF Last Call. > > I will look at these comments in detail soon. Some of your changes look like they will ignore WG consensus (e.g., change SHOULD to MUST). The reason this draft was written so early in the process is that the YANG spec has minimum level requirements that are not suitable for standardization. I am actually surprised that the IESG approved YANG, even though not 1 descriptive statement is required in the entire document. We went from MUST have every DESCRIPTION clause in SMIv2, to MAY have zero description-stmts in YANG. > Thanks and Regards, > > Dan > Andy > > > T1. Running idnits results into the following warning. > > == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', > 'SHOULD', > or 'RECOMMENDED' is not an accepted usage according to RFC 2119. > Please > use uppercase 'NOT' together with RFC 2119 keywords (if that is > what you > mean). > > Found 'MUST not' in this paragraph: > > Once a module name is published, it MUST not be reused, even if the > RFC containing the module is reclassified to 'Historic' status. > > T2. I would add to the second paragraph in the Introduction section a > phrase mentioning that while RFC 4181 was developped after more than one > decade of writing and deploying MIB modules, this document is issued > earlier in the YANG history, hence the hesitation of going directly to a > BCP, although from many aspects the document looks like a BCP document. > > T3. I suggest to add a phrase to the introduction about the target > audience - future YANG modules writers and reviewers. > > T4. Are there any exceptions that would justify using SHOULD rather than > MUST in 3.1? > > T5. Section 3.3 - 'These modules MUST be written in YANG' > > Do we really need a MUST here? The document is already about documents > that contain YANG modules, there is no need to repeat this. However, one > may imagine documents that combine for example YANG modules with MIB > modules - the MUST seems not to allow such a mix. > > T6. Sections 3.4 and 6 and Appendix A point 4 - we already have approved > security sections guidelines at > http://www.ops.ietf.org/netconf/yang-security-considerations.txt > > T7. Section 3.5 - I suggest to add a phrase at the end of the section > mentioning that for cases when there are no IANA section RFC 5226 allows > to remove this section before the publication of the RFC> > > T8. Section 3.5.1 - s/a new YANG Namespace registry entry must be > requested from IANA/a new YANG Namespace registry entry MUST be > requested from IANA/ > > T9. Section 4.1 s/MUST not/MUST NOT/ > > T10. Need to add a normative reference to XPATH > > T11. Section 4.7 - 'the document author contact information SHOULD be > present' - many documents have multiple authors, usually only the > contact information of one author is being included (at least with MIB > modules). > > T12. Section 4.8: Unless there is some good reason that I am missing: > s/It is desirable to include only valid YANG modules in documents/It is > RECOMMENDED to include only valid YANG modules in documents/ > > T13. Section 4.9: > > There SHOULD only be one top-level data node defined in each YANG > module. However, there MAY be more than one if needed. > > It would be good to describe an example of such a justified exception. > > T14. Section 4.10: > > For string data types, if the length of the string is required to > bounded in all implementations, then a length statement SHOULD be > present. > > s/SHOULD/MUST/ > > (or am I missing something?) > > T15. Section 4.11: > > If the type definition semantics are defined in an external document, > then the reference statement SHOULD be present. > > s/SHOULD/MUST/ > > (or am I missing something?) > > T16. Same comment for the similar text in 4.12 > > 17. Same comment for the similar text about operations in 4.13 > > 18. Same content for the similar text about notifications semantics in > 4.14 > > 19. Appendix A, point 5 - is it really true that an IANA section will > always be present in a YANG module document? What about the case when we > just define a submodule? RFC 5226 allows not to include an IANA > Considerations section in an RFC if there are no IANA actions > > 20. Appendix A, point 9 - [ed.: online YANG validation tool URL TBD]. > Should we rather consider here a pointer to a list of tools to be > maintained on the OPS Area Web pages (or wiki)? > > > > > > E1. The header of RFC 4181 is 'Guidelines for MIB documents'. Is there > any special reason not to use a similar header (like 'Guidelines for > YANG documents') for this document? > > E2. in section 2.1, second paragraph s/regarding YANG module > content/regarding YANG modules content/ > > E3. All over the document use consistently Internet-Draft rather than > Internet Draft. > > E4. in section 3.2 s/as MUST any special interpretations/as MUST be > noted any special interpretations/ > > E5. section 3.7 - provide a reference for the TLP. > > E6. section 4.2 - s/These includes/These include/ > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From dromasca@avaya.com Tue Jun 22 08:19:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0267F3A6857 for ; Tue, 22 Jun 2010 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.899, 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 qk8DniwhtG90 for ; Tue, 22 Jun 2010 08:19:50 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BFB7F3A69AA for ; Tue, 22 Jun 2010 08:19:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,460,1272859200"; d="scan'208";a="224336096" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jun 2010 11:19:56 -0400 X-IronPort-AV: E=Sophos;i="4.53,460,1272859200"; d="scan'208";a="474852256" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jun 2010 11:19:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 17:19:48 +0200 Message-ID: In-Reply-To: <4C20D32F.8090906@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt Thread-Index: AcsSHYP3ZcCe7jMYTVKdMKl/2H3sVAAADnqQ References: <4C20D32F.8090906@iwl.com> From: "Romascanu, Dan (Dan)" To: Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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, 22 Jun 2010 15:19:52 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Some of your changes look like they will ignore WG consensus=20 > (e.g., change SHOULD to MUST). >=20 I assume that any change at this phase would challenge the WG consensus. I am open to discussion on all suggested points.=20 Dan From phil@juniper.net Tue Jun 22 08:52:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC743A63CA for ; Tue, 22 Jun 2010 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 GR7m3dgKis22 for ; Tue, 22 Jun 2010 08:52:30 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 65CFF3A6887 for ; Tue, 22 Jun 2010 08:52:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTCDcQYJnGb+qPBKqfgVANgDMoWjY/fNO@postini.com; Tue, 22 Jun 2010 08:52:38 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Tue, 22 Jun 2010 08:48:41 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 08:48:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jun 2010 08:48:40 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 08:48:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o5MFmdD78892; Tue, 22 Jun 2010 08:48:39 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o5MFUjJg062854; Tue, 22 Jun 2010 15:30:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201006221530.o5MFUjJg062854@idle.juniper.net> To: In-Reply-To: <4C20D32F.8090906@iwl.com> Date: Tue, 22 Jun 2010 11:30:45 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jun 2010 15:48:40.0337 (UTC) FILETIME=[62A52810:01CB1222] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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, 22 Jun 2010 15:52:31 -0000 Andy Bierman writes: >I am actually surprised that the IESG approved YANG, >even though not 1 descriptive statement is >required in the entire document. We went from >MUST have every DESCRIPTION clause in SMIv2, >to MAY have zero description-stmts in YANG. Fortunately IESG members lived thru those days too ;^) Thanks, Phil From andyb@iwl.com Tue Jun 22 09:05:39 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350993A68C0 for ; Tue, 22 Jun 2010 09:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, 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 DLYUvCMMAHc0 for ; Tue, 22 Jun 2010 09:05:38 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id 8823E3A6896 for ; Tue, 22 Jun 2010 09:05:38 -0700 (PDT) Received: from relay12.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E7D63208027B; Tue, 22 Jun 2010 12:05:45 -0400 (EDT) Received: by relay12.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A763820800C3; Tue, 22 Jun 2010 12:05:45 -0400 (EDT) Message-ID: <4C20DF61.8080508@iwl.com> Date: Tue, 22 Jun 2010 09:05:53 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer References: <201006221530.o5MFUjJg062854@idle.juniper.net> In-Reply-To: <201006221530.o5MFUjJg062854@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:05:39 -0000 On 06/22/2010 08:30 AM, Phil Shafer wrote: > Andy Bierman writes: > >> I am actually surprised that the IESG approved YANG, >> even though not 1 descriptive statement is >> required in the entire document. We went from >> MUST have every DESCRIPTION clause in SMIv2, >> to MAY have zero description-stmts in YANG. >> > Fortunately IESG members lived thru those days too ;^) > Except that you can't submit a YANG module to the IETF that is missing a description stmt, so not sure how this is really an improvement. It is convenient for software developers writing test modules that are never intended to be published as part of a distributed management system. > Thanks, > Phil > > Andy From andyb@iwl.com Tue Jun 22 09:50:41 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3FB3A6943 for ; Tue, 22 Jun 2010 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, 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 jXOVYdMv1LXR for ; Tue, 22 Jun 2010 09:50:39 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id C65173A68BD for ; Tue, 22 Jun 2010 09:50:33 -0700 (PDT) Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C497030B167F; Tue, 22 Jun 2010 12:50:39 -0400 (EDT) Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 95AD830B1677; Tue, 22 Jun 2010 12:50:39 -0400 (EDT) Message-ID: <4C20E9E7.20803@iwl.com> Date: Tue, 22 Jun 2010 09:50:47 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:50:41 -0000 On 06/22/2010 07:08 AM, Romascanu, Dan (Dan) wrote: no problems so far.... up to T5... > ... > T5. Section 3.3 - 'These modules MUST be written in YANG' > > Do we really need a MUST here? The document is already about documents > that contain YANG modules, there is no need to repeat this. However, one > may imagine documents that combine for example YANG modules with MIB > modules - the MUST seems not to allow such a mix. > > I changed the text as follows: This section contains the module(s) defined by the specification. These modules MUST be written using the YANG syntax defined in [I-D.ietf-netmod-yang]. A YIN syntax version of the module MAY also be present in the document. I don't think we want WGs publishing YANG modules in YIN syntax *instead* of YANG syntax. Andy From andyb@iwl.com Tue Jun 22 11:28:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461243A67EC for ; Tue, 22 Jun 2010 11:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, 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 RMmSpUvhB52I for ; Tue, 22 Jun 2010 11:28:30 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 9447C3A67F8 for ; Tue, 22 Jun 2010 11:28:30 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id CC7633EF9F8; Tue, 22 Jun 2010 14:28:37 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 9B8173EF463; Tue, 22 Jun 2010 14:28:37 -0400 (EDT) Message-ID: <4C2100DE.4000104@iwl.com> Date: Tue, 22 Jun 2010 11:28:46 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 18:28:31 -0000 On 06/22/2010 07:08 AM, Romascanu, Dan (Dan) wrote: up to T15 now... > T15. Section 4.11: > > If the type definition semantics are defined in an external document, > then the reference statement SHOULD be present. > > s/SHOULD/MUST/ > > (or am I missing something?) > There was lots of debate on this one. The reason it is a SHOULD is that the import-stmt for the module that defines the external typedef MUST have a reference, so this one may be redundant. Do you still think s/SHOULD/MUST/ ? Is an explanation sufficient? Andy From root@core3.amsl.com Tue Jun 22 12:45:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CDF9C3A69BC; Tue, 22 Jun 2010 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100622194501.CDF9C3A69BC@core3.amsl.com> Date: Tue, 22 Jun 2010 12:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-06.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, 22 Jun 2010 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for YANG Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-06.txt Pages : 31 Date : 2010-06-22 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-usage-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-22123228.I-D@ietf.org> --NextPart-- From mbj@tail-f.com Tue Jun 22 15:11:50 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93DF28C11A for ; Tue, 22 Jun 2010 15:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=0.364, 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 MV4oHCaY5pEv for ; Tue, 22 Jun 2010 15:11:48 -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 952C328C125 for ; Tue, 22 Jun 2010 15:11:48 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A78476C1B4; Wed, 23 Jun 2010 00:11:54 +0200 (CEST) Date: Wed, 23 Jun 2010 00:11:53 +0200 (CEST) Message-Id: <20100623.001153.19604170.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 7.0.50 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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, 22 Jun 2010 22:11:50 -0000 Hi Dan and Andy, "Romascanu, Dan (Dan)" wrote: > T14. Section 4.10: > > For string data types, if the length of the string is required to > bounded in all implementations, then a length statement SHOULD be > present. There's a typo in this sentence, s/to bounded/to be bounded/ > 19. Appendix A, point 5 - is it really true that an IANA section will > always be present in a YANG module document? What about the case when we > just define a submodule? RFC 5226 allows not to include an IANA > Considerations section in an RFC if there are no IANA actions Also submodules are registred in the IANA registry, so I believe all these documents will have an IANA Considerations section. Based on experience from the monitoring draft, should we also add that references to all imported modules are listed in the text, as well as all references from the 'reference' statement? This is what we ended up with in montoring: This YANG module imports typedefs from [YANG-TYPES] and references [RFC4741], [RFC4742], [RFC4743], [RFC4744], [RFC5539], [xmlschema-1], [YANG], [ISO/IEC 19757-2:2008], and [RFC5717]. I believe the RFC editor wants all references in text. /martin From dromasca@avaya.com Wed Jun 23 01:44:39 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4104E3A6970 for ; Wed, 23 Jun 2010 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 LnSmzE4VG9CN for ; Wed, 23 Jun 2010 01:44:38 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C26313A6813 for ; Wed, 23 Jun 2010 01:44:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="224468856" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jun 2010 04:44:39 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="475089601" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2010 04:44:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2010 10:44:08 +0200 Message-ID: In-Reply-To: <4C20E9E7.20803@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt Thread-Index: AcsSKwwiG+gW6wkYTdOt4El9nyKu+AAhHZtA References: <4C20E9E7.20803@iwl.com> From: "Romascanu, Dan (Dan)" To: Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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: Wed, 23 Jun 2010 08:44:39 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Sent: Tuesday, June 22, 2010 7:51 PM > To: Romascanu, Dan (Dan) > Cc: NETMOD Working Group > Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt >=20 > On 06/22/2010 07:08 AM, Romascanu, Dan (Dan) wrote: >=20 > no problems so far.... up to T5... > > ... > > T5. Section 3.3 - 'These modules MUST be written in YANG'=20 > > > > Do we really need a MUST here? The document is already=20 > about documents=20 > > that contain YANG modules, there is no need to repeat this.=20 > However,=20 > > one may imagine documents that combine for example YANG=20 > modules with=20 > > MIB modules - the MUST seems not to allow such a mix. > > > > =20 >=20 > I changed the text as follows: >=20 > This section contains the module(s) defined by the specification. > These modules MUST be written using the YANG syntax defined in > [I-D.ietf-netmod-yang]. A YIN syntax version of the module MAY > also be present in the document. >=20 > I don't think we want WGs publishing YANG modules in YIN=20 > syntax *instead* of YANG syntax. >=20 >=20 >=20 > Andy >=20 I think that you are partially missing the point I was trying to make. Your observation about using YIN is fine, but there can be other data models in the definition section not related to YANG or YIN (or NETCONF). We would not prevent somebody to write a data model document using say YANG and SMIv2 and we would like to apply the usage document obviously only for the YANG DM. To cover this I suggest:=20 This section contains the module(s) defined by the specification. These modules MUST be written using the YANG syntax defined in [I-D.ietf-netmod-yang]. A YIN syntax version of the module or data models expressed in other data modeling languages MAY also be=20 present in the document. Dan From dromasca@avaya.com Wed Jun 23 01:47:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F7C3A67F2 for ; Wed, 23 Jun 2010 01:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.856, 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 wh2JwE00PAX0 for ; Wed, 23 Jun 2010 01:47:18 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5D3443A6822 for ; Wed, 23 Jun 2010 01:47:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="194807628" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jun 2010 04:47:18 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="475090530" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2010 04:47:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2010 10:46:52 +0200 Message-ID: In-Reply-To: <4C2100DE.4000104@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt Thread-Index: AcsSOL/1rYazSFHAQoiqBqOuDICo/AAd7i1Q References: <4C2100DE.4000104@iwl.com> From: "Romascanu, Dan (Dan)" To: Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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: Wed, 23 Jun 2010 08:47:21 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Sent: Tuesday, June 22, 2010 9:29 PM > To: Romascanu, Dan (Dan) > Cc: NETMOD Working Group > Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt >=20 > On 06/22/2010 07:08 AM, Romascanu, Dan (Dan) wrote: >=20 > up to T15 now... >=20 > > T15. Section 4.11:=20 > > > > If the type definition semantics are defined in an=20 > external document, > > then the reference statement SHOULD be present. > > > > s/SHOULD/MUST/ > > > > (or am I missing something?) > > =20 >=20 > There was lots of debate on this one. > The reason it is a SHOULD is that the > import-stmt for the module that defines the external typedef=20 > MUST have a reference, so this one may be redundant. >=20 > Do you still think s/SHOULD/MUST/ ? > Is an explanation sufficient? >=20 >=20 > Andy >=20 >=20 The explanation is sufficient. I agree with the WG consensus and rest my case on this one.=20 Thanks and Regards, Dan From dromasca@avaya.com Wed Jun 23 01:49:06 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8073A6A69 for ; Wed, 23 Jun 2010 01:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.837, 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 n3NEQYSYluu8 for ; Wed, 23 Jun 2010 01:49:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5B6443A6A65 for ; Wed, 23 Jun 2010 01:49:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="194807817" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jun 2010 04:49:10 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="485678943" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2010 04:49:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2010 10:49:08 +0200 Message-ID: In-Reply-To: <20100623.001153.19604170.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt Thread-Index: AcsSV+1wqJBrzUjBT62FS/iw4g69dgAWNtow References: <20100623.001153.19604170.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.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: Wed, 23 Jun 2010 08:49:06 -0000 =20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Wednesday, June 23, 2010 1:12 AM > To: Romascanu, Dan (Dan) > Cc: netmod@ietf.org > Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt >=20 > Hi Dan and Andy, >=20 >=20 > "Romascanu, Dan (Dan)" wrote: > > T14. Section 4.10:=20 > >=20 > > For string data types, if the length of the string is required to > > bounded in all implementations, then a length statement SHOULD be > > present. >=20 > There's a typo in this sentence, s/to bounded/to be bounded/ >=20 > > 19. Appendix A, point 5 - is it really true that an IANA=20 > section will=20 > > always be present in a YANG module document? What about the=20 > case when=20 > > we just define a submodule? RFC 5226 allows not to include an IANA=20 > > Considerations section in an RFC if there are no IANA actions >=20 > Also submodules are registred in the IANA registry, so I=20 > believe all these documents will have an IANA Considerations section. OK.=20 >=20 >=20 > Based on experience from the monitoring draft, should we also=20 > add that references to all imported modules are listed in the=20 > text, as well as all references from the 'reference'=20 > statement? This is what we ended up with in montoring: >=20 > This YANG module imports typedefs from [YANG-TYPES] and references > [RFC4741], [RFC4742], [RFC4743], [RFC4744], [RFC5539],=20 > [xmlschema-1], > [YANG], [ISO/IEC 19757-2:2008], and [RFC5717]. >=20 > I believe the RFC editor wants all references in text. Probably a SHOULD with an explanation of the rationale.=20 Dan >=20 >=20 > /martin >=20 From dromasca@avaya.com Wed Jun 23 04:20:29 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2680E3A6971 for ; Wed, 23 Jun 2010 04:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.731, 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 chPDpr7LoaA2 for ; Wed, 23 Jun 2010 04:20:28 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id C2E6E3A69A2 for ; Wed, 23 Jun 2010 04:20:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="21964032" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 23 Jun 2010 07:20:33 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="485722088" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2010 07:20:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2010 13:20:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-netmod-yang-usage-06 Thread-Index: AcsSxhSbwEOMT3qTRg6EcaZ+LQJfig== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] AD comments on draft-ietf-netmod-yang-usage-06 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, 23 Jun 2010 11:20:29 -0000 Thanks to Andy for issuing so fast a revised I-D and for taking into consideration many of my comments.=20 Here are my observations on draft-06:=20 1. There is a change in title which I do not feel comfortable with. My comment E1 referred to the header of the pages, not to the title. The previous title was fine (and consistent with RFC 4181).=20 2. Section 3.3 - see my earlier mail.=20 3. Appendix A.9 - as appendices are typically non-normative the use of capitalized 2119 keywords is not customary.=20 Overall the document looks good and ready enough for IETF Last Call. Let me know if you prefer to re-spin a new version (in case you accept the last round of comments) or rather go directly to IETF LC considering the three comments above as LC comments.=20 Regards, Dan From andyb@iwl.com Wed Jun 23 08:43:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532BC3A6889 for ; Wed, 23 Jun 2010 08:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, 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 AYnyJlh-V3Kr for ; Wed, 23 Jun 2010 08:43:11 -0700 (PDT) Received: from smtp135.dfw.emailsrvr.com (smtp135.dfw.emailsrvr.com [67.192.241.135]) by core3.amsl.com (Postfix) with ESMTP id 27ED73A6831 for ; Wed, 23 Jun 2010 08:43:09 -0700 (PDT) Received: from relay13.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E7F4431318DB; Wed, 23 Jun 2010 11:43:16 -0400 (EDT) Received: by relay13.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B7C9731315BF; Wed, 23 Jun 2010 11:43:16 -0400 (EDT) Message-ID: <4C222BA0.9010901@iwl.com> Date: Wed, 23 Jun 2010 08:43:28 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4C20E9E7.20803@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:43:12 -0000 On 06/23/2010 01:44 AM, Romascanu, Dan (Dan) wrote: > > > >> -----Original Message----- >> From: Andy Bierman [mailto:andyb@iwl.com] >> Sent: Tuesday, June 22, 2010 7:51 PM >> To: Romascanu, Dan (Dan) >> Cc: NETMOD Working Group >> Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-usage-05.txt >> >> On 06/22/2010 07:08 AM, Romascanu, Dan (Dan) wrote: >> >> no problems so far.... up to T5... >> >>> ... >>> T5. Section 3.3 - 'These modules MUST be written in YANG' >>> >>> Do we really need a MUST here? The document is already >>> >> about documents >> >>> that contain YANG modules, there is no need to repeat this. >>> >> However, >> >>> one may imagine documents that combine for example YANG >>> >> modules with >> >>> MIB modules - the MUST seems not to allow such a mix. >>> >>> >>> >> I changed the text as follows: >> >> This section contains the module(s) defined by the specification. >> These modules MUST be written using the YANG syntax defined in >> [I-D.ietf-netmod-yang]. A YIN syntax version of the module MAY >> also be present in the document. >> >> I don't think we want WGs publishing YANG modules in YIN >> syntax *instead* of YANG syntax. >> >> >> >> Andy >> >> > I think that you are partially missing the point I was trying to make. > Your observation about using YIN is fine, but there can be other data > models in the definition section not related to YANG or YIN (or > NETCONF). We would not prevent somebody to write a data model document > using say YANG and SMIv2 and we would like to apply the usage document > obviously only for the YANG DM. To cover this I suggest: > > This section contains the module(s) defined by the specification. > These modules MUST be written using the YANG syntax defined in > [I-D.ietf-netmod-yang]. A YIN syntax version of the module or > data > models expressed in other data modeling languages MAY also be > present in the document. > > I will add a sentence that says this document does not apply to any module types other than YANG, which MAY also exist in the document. > Dan > > Andy From andyb@iwl.com Wed Jun 23 08:43:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1040E3A6831 for ; Wed, 23 Jun 2010 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, 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 r9edPsTlZjnk for ; Wed, 23 Jun 2010 08:43:31 -0700 (PDT) Received: from smtp135.dfw.emailsrvr.com (smtp135.dfw.emailsrvr.com [67.192.241.135]) by core3.amsl.com (Postfix) with ESMTP id 444DA3A6889 for ; Wed, 23 Jun 2010 08:43:31 -0700 (PDT) Received: from relay13.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 346C631318D2; Wed, 23 Jun 2010 11:43:39 -0400 (EDT) Received: by relay13.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E505C3130D31; Wed, 23 Jun 2010 11:43:38 -0400 (EDT) Message-ID: <4C222BB7.5080908@iwl.com> Date: Wed, 23 Jun 2010 08:43:51 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] AD comments on draft-ietf-netmod-yang-usage-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:43:32 -0000 On 06/23/2010 04:20 AM, Romascanu, Dan (Dan) wrote: > Thanks to Andy for issuing so fast a revised I-D and for taking into > consideration many of my comments. > > Here are my observations on draft-06: > > 1. There is a change in title which I do not feel comfortable with. My > comment E1 referred to the header of the pages, not to the title. The > previous title was fine (and consistent with RFC 4181). > > 2. Section 3.3 - see my earlier mail. > > 3. Appendix A.9 - as appendices are typically non-normative the use of > capitalized 2119 keywords is not customary. > > Overall the document looks good and ready enough for IETF Last Call. Let > me know if you prefer to re-spin a new version (in case you accept the > last round of comments) or rather go directly to IETF LC considering the > three comments above as LC comments. > > I will spin a new version this morning with corrections. > Regards, > > Dan > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From root@core3.amsl.com Wed Jun 23 09:45:02 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A15913A6AC0; Wed, 23 Jun 2010 09:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100623164502.A15913A6AC0@core3.amsl.com> Date: Wed, 23 Jun 2010 09:45:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-07.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: Wed, 23 Jun 2010 16:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-07.txt Pages : 31 Date : 2010-06-23 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-usage-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-23093600.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Jun 23 10:00:02 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 191563A6AAE; Wed, 23 Jun 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100623170002.191563A6AAE@core3.amsl.com> Date: Wed, 23 Jun 2010 10:00:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-07.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: Wed, 23 Jun 2010 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : An Architecture for Network Management using NETCONF and YANG Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-07.txt Pages : 32 Date : 2010-06-23 NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-arch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-23095134.I-D@ietf.org> --NextPart-- From david.kessens@nsn.com Wed Jun 23 15:25:45 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D4A28C0F3 for ; Wed, 23 Jun 2010 15:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 MVCVznKZai9M for ; Wed, 23 Jun 2010 15:25:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 374373A69F9 for ; Wed, 23 Jun 2010 15:25:44 -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 o5NMPohc030977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Jun 2010 00:25:50 +0200 Received: from localhost.localdomain ([10.138.50.177]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5NMPmdS026625 for ; Thu, 24 Jun 2010 00:25:49 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o5NMPl1G009693 for ; Wed, 23 Jun 2010 15:25:48 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o5NMPluu009692 for netmod@ietf.org; Wed, 23 Jun 2010 15:25:47 -0700 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Wed, 23 Jun 2010 15:25:47 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20100623222546.GC6574@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) Subject: [netmod] FW: Nomcom 2010-2011: Second Call for Volunteers 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, 23 Jun 2010 22:25:46 -0000 For those of you who are not on the ietf(-announce)?@ietf.org mailing list. ----- Forwarded message from "Romascanu, Dan (Dan)" ----- Date: Tue, 22 Jun 2010 09:30:14 +0200 From: "Romascanu, Dan (Dan)" To: ops-chairs@ietf.org Subject: FW: Nomcom 2010-2011: Second Call for Volunteers OPS Area Chairs, Please forward this message to your WG mail lists. Participation in the Nomcom process is an opportunity for any IETF participant to support the IETF and influence its future by selecting the next generation of IETF leaders and by receiving and processing the inputs of the community about the IETF work and processes. Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Tuesday, June 22, 2010 12:49 AM To: IETF Announcement list Subject: Nomcom 2010-2011: Second Call for Volunteers Hi all, This is the Second call for Volunteers for the 2010-11 nomcom. We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon. I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF pouplation. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of nomcom may be found in RFC 3777. The process on how to volunteer for nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are: Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- From wwwrun@core3.amsl.com Thu Jun 24 06:44:38 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 455023A697B; Thu, 24 Jun 2010 06:44:37 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100624134438.455023A697B@core3.amsl.com> Date: Thu, 24 Jun 2010 06:44:38 -0700 (PDT) X-Mailman-Approved-At: Thu, 24 Jun 2010 08:14:23 -0700 Cc: netmod@ietf.org Subject: [netmod] Last Call: draft-ietf-netmod-yang-usage (Guidelines for Authors and Reviewers of YANG Data Model Documents) to Informational RFC X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 13:44:38 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Guidelines for Authors and Reviewers of YANG Data Model Documents ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18576&rfc_flag=0 From lhotka@cesnet.cz Fri Jun 25 08:29:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6C33A69E5 for ; Fri, 25 Jun 2010 08:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.093 X-Spam-Level: * X-Spam-Status: No, score=1.093 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 IrbWhwlDDhqx for ; Fri, 25 Jun 2010 08:29:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7E2273A6969 for ; Fri, 25 Jun 2010 08:29:28 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4BCBB2CDE06B for ; Fri, 25 Jun 2010 17:29:36 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 25 Jun 2010 17:29:34 +0200 Message-ID: <1277479774.2674.32.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [netmod] bidirectional links 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 Jun 2010 15:29:30 -0000 Hi, I am now trying to translate our old RELAX NG data model for a simple router to YANG and I ran into this trouble: It would be natural to have a module for interfaces and another for packet filters. However, I need a link from an interface to a packet filter chain, but also vice versa - an interface may be assigned a particular packet filter chain and, on the other hand, a packet filter rule may have an incoming interface as one of the match criteria. YANG "leafref" type would be quite effective for this purpose, but the problem is that I need to refer (via the 'path' statement) to a leaf in the "packet-filters" module tree from the "interfaces" module and vice versa, something like module interfaces { ... prefix "if"; import packet-filters { prefix pf; } ... leaf filter-in { type leafref { path "/pf:packet-filters/pf:packet-filter-chain/pf:name"; } } ... } module packet-filters { ... prefix "pf"; import interfaces { prefix if; } ... leaf match-interface { type leafref { path "/if:interfaces/if:device/if:name"; } } ... } This of course is not allowed in YANG because of the circular import, but I see no other way how to get mutual access from one module to another and back. Any ideas? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Fri Jun 25 11:46:14 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4CE3A6800 for ; Fri, 25 Jun 2010 11:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_50=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 xS6C22h4mSPG for ; Fri, 25 Jun 2010 11:46:13 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 809363A68B2 for ; Fri, 25 Jun 2010 11:46:07 -0700 (PDT) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 408BC908443; Fri, 25 Jun 2010 14:46:16 -0400 (EDT) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 12BE39081F2; Fri, 25 Jun 2010 14:46:16 -0400 (EDT) Message-ID: <4C24F991.2020504@iwl.com> Date: Fri, 25 Jun 2010 11:46:41 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <1277479774.2674.32.camel@missotis> In-Reply-To: <1277479774.2674.32.camel@missotis> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] bidirectional links X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:46:14 -0000 On 06/25/2010 08:29 AM, Ladislav Lhotka wrote: > Hi, > > I am now trying to translate our old RELAX NG data model for a simple > router to YANG and I ran into this trouble: > > It would be natural to have a module for interfaces and another for > packet filters. However, I need a link from an interface to a packet > filter chain, but also vice versa - an interface may be assigned a > particular packet filter chain and, on the other hand, a packet filter > rule may have an incoming interface as one of the match criteria. > > YANG "leafref" type would be quite effective for this purpose, but the > problem is that I need to refer (via the 'path' statement) to a leaf in > the "packet-filters" module tree from the "interfaces" module and vice > versa, something like > > module interfaces { > ... > prefix "if"; > import packet-filters { > prefix pf; > } > ... > leaf filter-in { > type leafref { > path "/pf:packet-filters/pf:packet-filter-chain/pf:name"; > } > } > ... > } > > module packet-filters { > ... > prefix "pf"; > import interfaces { > prefix if; > } > ... > leaf match-interface { > type leafref { > path "/if:interfaces/if:device/if:name"; > } > } > ... > } > > This of course is not allowed in YANG because of the circular import, > but I see no other way how to get mutual access from one module to > another and back. Any ideas? > > SQL tools deal with this by mapping INT primary keys. Elixir has a ManytoMany macro that may sort of apply here. What if you had a 3rd module for the mapping relation? module pfif-mapping { ... import interfaces { prefix if; } import packet-filters { prefix pf; } list pfif-map { key "filter-in match-interface"; leaf filter-in { type leafref { path "/pf:packet-filters/pf:packet-filter-chain/pf:name"; } leaf match-interface { type leafref { path "/if:interfaces/if:device/if:name"; } } } It is a bit clumsy to need a 3rd YANG module, but this happens a lot in C code as well to avoid an #include loop. > Lada > > Andy From lhotka@cesnet.cz Fri Jun 25 23:41:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB123A67D9 for ; Fri, 25 Jun 2010 23:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.111 X-Spam-Level: * X-Spam-Status: No, score=1.111 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 zH9Fc34pwUGE for ; Fri, 25 Jun 2010 23:41:04 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E04C93A635F for ; Fri, 25 Jun 2010 23:41:03 -0700 (PDT) Received: from [172.29.2.216] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 6E77C2CDE05B; Sat, 26 Jun 2010 08:41:07 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C24F991.2020504@iwl.com> References: <1277479774.2674.32.camel@missotis> <4C24F991.2020504@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sat, 26 Jun 2010 08:41:05 +0200 Message-ID: <1277534465.1818.5.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] bidirectional links 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 Jun 2010 06:41:05 -0000 On Pá, 2010-06-25 at 11:46 -0700, Andy Bierman wrote: > SQL tools deal with this by mapping INT primary keys. > Elixir has a ManytoMany macro that may sort of apply here. > > What if you had a 3rd module for the mapping relation? > > module pfif-mapping { > ... > import interfaces { prefix if; } > import packet-filters { prefix pf; } > > list pfif-map { > key "filter-in match-interface"; > > leaf filter-in { > type leafref { > path "/pf:packet-filters/pf:packet-filter-chain/pf:name"; > } > leaf match-interface { > type leafref { > path "/if:interfaces/if:device/if:name"; > } > } > } This is possible but then I will need such ad hoc modules for links between interfaces and individual routing protocols, route filters etc., so it can get a bit unwieldy. > > It is a bit clumsy to need a 3rd YANG module, but this happens a lot > in C code as well to avoid an #include loop. YANG import actually doesn't import anything, it's just a handle to the stuff in the other module. I am thinking about possible consequences - could it make any harm to allow the circular imports? Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andyb@iwl.com Sun Jun 27 10:24:07 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBF63A68CF for ; Sun, 27 Jun 2010 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.935 X-Spam-Level: X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLS4PnjQpWpw for ; Sun, 27 Jun 2010 10:24:05 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id C3B643A688E for ; Sun, 27 Jun 2010 10:24:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4AF462A8513 for ; Sun, 27 Jun 2010 13:24:15 -0400 (EDT) X-Virus-Scanned: OK Received: from [192.168.0.8] (cpe-75-84-164-152.socal.res.rr.com [75.84.164.152]) (Authenticated sender: andyb@iwlcorp.com) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPSA id 1971A2A84EC for ; Sun, 27 Jun 2010 13:24:15 -0400 (EDT) Message-ID: <4C278972.6050802@iwl.com> Date: Sun, 27 Jun 2010 10:25:06 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] NETCONF conformance for YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 17:24:07 -0000 Hi, I am not proposing any changes to the YANG spec, but I think more work is needed on conformance. The current simplistic model is extremely deficient in 3 ways: 1) no way to have a mandatory-to-implement non-config leaf that is conditional on the description-stmt. - if mandatory=true then it MUST be in a non-filtered reply - if mandatory=FALSE then it is optional-to-implement by the server, - the client has no way to know if a config=false and non-mandatory object is implemented on a particular server from the message 2) no way to allow read-only MIN-ACCESS for a config node as part of the conformance options. Deviations are not allowed in standard modules, so they do not help. They also indicate a lack of conformance, not a conformance option. 3) no way to allow a subset of the complete syntax for a given leaf or leaf-list. YANG features only control whether the node is allowed to exist or not. Simple example: inet-address for which not all variants apply: YANG has no formal mechanisms to support even this well-known use-case. I think it will be apparent as WGs try to use YANG, just how unworkable the current conformance mechanisms are. For now I am wondering if any usage guidelines are needed. Andy From randy_presuhn@mindspring.com Sun Jun 27 15:01:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C040C3A69C9 for ; Sun, 27 Jun 2010 15:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_50=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 0Vmsyq--Ksit for ; Sun, 27 Jun 2010 15:01:37 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E7AE73A6954 for ; Sun, 27 Jun 2010 15:01:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AfQ+OS3JSSfnaoFPAH6TQQB9876nQHLCLB+qzwOdLd37SMOtevc8ucYhsL3kw1uX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.70] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OSzv8-00058Y-Dd for netmod@ietf.org; Sun, 27 Jun 2010 18:01:46 -0400 Message-ID: <002601cb1644$9768b500$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <4C278972.6050802@iwl.com> Date: Sun, 27 Jun 2010 15:03:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780358ca8b284baba390a268833322caaa1b1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.70 Subject: Re: [netmod] NETCONF conformance for YANG modules 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: Sun, 27 Jun 2010 22:01:37 -0000 Hi - > From: "Andy Bierman" > To: "NETMOD Working Group" > Sent: Sunday, June 27, 2010 10:25 AM > Subject: [netmod] NETCONF conformance for YANG modules ... > 2) no way to allow read-only MIN-ACCESS for a config node > as part of the conformance options. Deviations are not > allowed in standard modules, so they do not help. They > also indicate a lack of conformance, not a conformance option. ... This sounds like a feature to me. In my opinion, the read-only MIN-ACCESS was a big enabler (in the bad sense of "enabling" an addict) for implementors wanting to claim conformance to MIB modules without providing for configuration. Omitting this from YANG might be a bit of an over-correction, in that there may be cases where this arguably useful, but we've already seen how having MIN-ACCESS read-only as an option in MIB-land worked against standardized network configuration management. Randy From andyb@iwl.com Sun Jun 27 15:47:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9963A6A10 for ; Sun, 27 Jun 2010 15:47:54 -0700 (PDT) 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.766, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tram6YxIoWiE for ; Sun, 27 Jun 2010 15:47:51 -0700 (PDT) Received: from smtp115.iad.emailsrvr.com (smtp115.iad.emailsrvr.com [207.97.245.115]) by core3.amsl.com (Postfix) with ESMTP id 0C9983A687F for ; Sun, 27 Jun 2010 15:47:51 -0700 (PDT) Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 93D071B403A; Sun, 27 Jun 2010 18:48:00 -0400 (EDT) Received: by relay31.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 4F2A81B4003; Sun, 27 Jun 2010 18:48:00 -0400 (EDT) Message-ID: <4C27D555.2010009@iwl.com> Date: Sun, 27 Jun 2010 15:48:53 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Randy Presuhn References: <4C278972.6050802@iwl.com> <002601cb1644$9768b500$6801a8c0@oemcomputer> In-Reply-To: <002601cb1644$9768b500$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] NETCONF conformance for YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 22:47:55 -0000 On 06/27/2010 03:03 PM, Randy Presuhn wrote: > Hi - > > >> From: "Andy Bierman" >> To: "NETMOD Working Group" >> Sent: Sunday, June 27, 2010 10:25 AM >> Subject: [netmod] NETCONF conformance for YANG modules >> > ... > >> 2) no way to allow read-only MIN-ACCESS for a config node >> as part of the conformance options. Deviations are not >> allowed in standard modules, so they do not help. They >> also indicate a lack of conformance, not a conformance option. >> > ... > > This sounds like a feature to me. In my opinion, the read-only MIN-ACCESS > was a big enabler (in the bad sense of "enabling" an addict) for implementors > wanting to claim conformance to MIB modules without providing for configuration. > Omitting this from YANG might be a bit of an over-correction, in that there may be > cases where this arguably useful, but we've already seen how having MIN-ACCESS > read-only as an option in MIB-land worked against standardized network > configuration management. > > This is somewhat true, but often an application just needs to read some bit of config-data to know how to do its job wrt/ that device. Being able to read a standard config setting is better than nothing. Standard CM is just as hard as before NETCONF/YANG. Agreeing on the domain-specific knobs is the first-order problem, and the IETF has never addressed that very well. > Randy > Andy From mbj@tail-f.com Mon Jun 28 01:13:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51303A69A0 for ; Mon, 28 Jun 2010 01:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_50=0.001, 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 2HCJ0HVC3YaW for ; Mon, 28 Jun 2010 01:13:46 -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 E56563A67D9 for ; Mon, 28 Jun 2010 01:13:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0083E616004; Mon, 28 Jun 2010 10:13:54 +0200 (CEST) Date: Mon, 28 Jun 2010 08:30:14 +0200 (CEST) Message-Id: <20100628.083014.167618363.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1277479774.2674.32.camel@missotis> References: <1277479774.2674.32.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=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] bidirectional links 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 Jun 2010 08:13:46 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > I am now trying to translate our old RELAX NG data model for a simple > router to YANG and I ran into this trouble: > > It would be natural to have a module for interfaces and another for > packet filters. However, I need a link from an interface to a packet > filter chain, but also vice versa - an interface may be assigned a > particular packet filter chain and, on the other hand, a packet filter > rule may have an incoming interface as one of the match criteria. > > YANG "leafref" type would be quite effective for this purpose, but the > problem is that I need to refer (via the 'path' statement) to a leaf in > the "packet-filters" module tree from the "interfaces" module and vice > versa One way to solve this is to let the packet-filter module augment the interface module: module interfaces { namespace "urn:example:if"; prefix "if"; container interfaces { list interface { key name; leaf name { type string; } } } } module packet-filters { namespace "urn:example:pf"; prefix "pf"; import interfaces { prefix if; } augment "/if:interfaces/if:interface" { leaf filter-in { type leafref { path "/pf:packet-filters/pf:packet-filter-chain/pf:name"; } } } container packet-filters { list packet-filter-chain { key name; leaf name { type string; } leaf match-interface { type leafref { path "/if:interfaces/if:interface/if:name"; } } } } } /martin From david.partain@ericsson.com Mon Jun 28 06:36:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E313A6877 for ; Mon, 28 Jun 2010 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=-1.674, BAYES_40=-0.185] 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 jMa6pLM8eDda for ; Mon, 28 Jun 2010 06:36:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7F1443A681C for ; Mon, 28 Jun 2010 06:36:01 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-29-4c28a54a858a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.B9.19600.A45A82C4; Mon, 28 Jun 2010 15:36:10 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jun 2010 15:36:10 +0200 Received: from selic022.lmera.ericsson.se ([150.132.89.13]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jun 2010 15:36:10 +0200 Content-Language: en-US Content-Disposition: inline From: David Partain Organization: Ericsson AB User-Agent: KMail/1.9.10 MIME-Version: 1.0 To: netmod@ietf.org Date: Mon, 28 Jun 2010 15:36:09 +0200 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006281536.09547.david.partain@ericsson.com> X-OriginalArrivalTime: 28 Jun 2010 13:36:10.0054 (UTC) FILETIME=[DE62BE60:01CB16C6] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: draft-ietf-netmod-dsdl-map-06.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: Mon, 28 Jun 2010 13:36:05 -0000 Greetings, Now that Lada has updated the mapping document, it's time to finish it up and ship it to the IESG. As such, we're issuing a five-day working group last call on the current working group document: draft-ietf-netmod-dsdl-map-06.txt Title: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content URL: http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-06 Diff from previous version: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-dsdl-map-06.txt This WGLC will end on July 2, 2010. Please review the document and post your comments on the mailing list. Please use an appropriate Subject line so that the chairs and editor can easily keep track of the issues that need to be dealt with. NOTE: It is very important that the chairs can judge whether the Working Group thinks we're finished or not. As such, please provide your comments, even if it is only to say "It's fine. Ship it!" Thanks. David^2 From mbj@tail-f.com Mon Jun 28 08:09:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5CE3A68BB for ; Mon, 28 Jun 2010 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKRcRUUA76v8 for ; Mon, 28 Jun 2010 08:09:28 -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 E92C43A6920 for ; Mon, 28 Jun 2010 08:09:27 -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 92E5A616002; Mon, 28 Jun 2010 17:09:36 +0200 (CEST) Date: Mon, 28 Jun 2010 17:09:36 +0200 (CEST) Message-Id: <20100628.170936.66613553.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C278972.6050802@iwl.com> References: <4C278972.6050802@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules 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 Jun 2010 15:09:28 -0000 Hi, Andy Bierman wrote: > Hi, > > I am not proposing any changes to the YANG spec, but I think > more work is needed on conformance. The current simplistic model > is extremely deficient in 3 ways: > > 1) no way to have a mandatory-to-implement non-config leaf > that is conditional on the description-stmt. > - if mandatory=true then it MUST be in a non-filtered reply > - if mandatory=FALSE then it is optional-to-implement > by the server, mandatory false does not mean that it is optional to implement. In some (most?) cases the difference doesn't matter though. > - the client has no way to know if a config=false and > non-mandatory object is implemented on a particular server > from the message > > 2) no way to allow read-only MIN-ACCESS for a config node > as part of the conformance options. Deviations are not > allowed in standard modules, so they do not help. They > also indicate a lack of conformance, not a conformance option. See Randy's reply. > 3) no way to allow a subset of the complete syntax for a given > leaf or leaf-list. YANG features only control whether the node > is allowed to exist or not. In Phil's and mine original proposal for features, we had this, but it was rejected at the interim meeting. I agree that this would be useful... /martin From andyb@iwl.com Mon Jun 28 08:28:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF283A68F6 for ; Mon, 28 Jun 2010 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_50=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] 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 T9Z9c-CBwUCb for ; Mon, 28 Jun 2010 08:28:21 -0700 (PDT) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id D24FF3A6915 for ; Mon, 28 Jun 2010 08:28:19 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id AEE911B4071; Mon, 28 Jun 2010 11:28:29 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 5C6961B4090; Mon, 28 Jun 2010 11:28:29 -0400 (EDT) Message-ID: <4C28BFDC.2000507@iwl.com> Date: Mon, 28 Jun 2010 08:29:32 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C278972.6050802@iwl.com> <20100628.170936.66613553.mbj@tail-f.com> In-Reply-To: <20100628.170936.66613553.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 15:28:22 -0000 On 06/28/2010 08:09 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > >> Hi, >> >> I am not proposing any changes to the YANG spec, but I think >> more work is needed on conformance. The current simplistic model >> is extremely deficient in 3 ways: >> >> 1) no way to have a mandatory-to-implement non-config leaf >> that is conditional on the description-stmt. >> - if mandatory=true then it MUST be in a non-filtered reply >> - if mandatory=FALSE then it is optional-to-implement >> by the server, >> > mandatory false does not mean that it is optional to implement. In > some (most?) cases the difference doesn't matter though. > Yes it does for a non-config leaf. It means the server never has to send the node -- ever. That means every config=false data node, every RPC output node and every notification node, unless they are marked mandatory=true, do not have to be implemented. > >> - the client has no way to know if a config=false and >> non-mandatory object is implemented on a particular server >> from the message >> >> 2) no way to allow read-only MIN-ACCESS for a config node >> as part of the conformance options. Deviations are not >> allowed in standard modules, so they do not help. They >> also indicate a lack of conformance, not a conformance option. >> > See Randy's reply. > See my reply to Randy's reply. I would love to be proven wrong by seeing any meaningful standard CM data models emerge from the IETF. How many implementations of the ipfix-psamp model exist? Zero? How many other YANG modules with any writable objects at all? Zero? Sometimes this all-or-nothing approach backfires. > >> 3) no way to allow a subset of the complete syntax for a given >> leaf or leaf-list. YANG features only control whether the node >> is allowed to exist or not. >> > In Phil's and mine original proposal for features, we had this, but it > was rejected at the interim meeting. I agree that this would be > useful... > > > > /martin > > Andy From mbj@tail-f.com Mon Jun 28 08:47:33 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C8A28C16A for ; Mon, 28 Jun 2010 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnQ9NqS9IwWb for ; Mon, 28 Jun 2010 08:47:32 -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 E30F828C16E for ; Mon, 28 Jun 2010 08:47:31 -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 AF84976C098; Mon, 28 Jun 2010 17:47:41 +0200 (CEST) Date: Mon, 28 Jun 2010 17:47:40 +0200 (CEST) Message-Id: <20100628.174740.233831854.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C28BFDC.2000507@iwl.com> References: <4C278972.6050802@iwl.com> <20100628.170936.66613553.mbj@tail-f.com> <4C28BFDC.2000507@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules 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 Jun 2010 15:47:33 -0000 Andy Bierman wrote: > On 06/28/2010 08:09 AM, Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > > > >> Hi, > >> > >> I am not proposing any changes to the YANG spec, but I think > >> more work is needed on conformance. The current simplistic model > >> is extremely deficient in 3 ways: > >> > >> 1) no way to have a mandatory-to-implement non-config leaf > >> that is conditional on the description-stmt. > >> - if mandatory=true then it MUST be in a non-filtered reply > >> - if mandatory=FALSE then it is optional-to-implement > >> by the server, > >> > > mandatory false does not mean that it is optional to implement. In > > some (most?) cases the difference doesn't matter though. > > > > > Yes it does for a non-config leaf. > It means the server never has to send the node -- ever. > That means every config=false data node, every > RPC output node and every notification node, unless they > are marked mandatory=true, do not have to be implemented. Can you point me to where the YANG spec says that a server can choose to not implement a mandatory false leaf? As I wrote above, I agree that in some cases a valid implementation strategy can be to not implement such a leaf, but it all depends on the semantics of the leaf. > >> - the client has no way to know if a config=false and > >> non-mandatory object is implemented on a particular server > >> from the message > >> > >> 2) no way to allow read-only MIN-ACCESS for a config node > >> as part of the conformance options. Deviations are not > >> allowed in standard modules, so they do not help. They > >> also indicate a lack of conformance, not a conformance option. > >> > > See Randy's reply. > > > > See my reply to Randy's reply. > I would love to be proven wrong by > seeing any meaningful standard CM data models > emerge from the IETF. How many implementations > of the ipfix-psamp model exist? Zero? > How many other YANG modules with any > writable objects at all? Zero? > Sometimes this all-or-nothing approach backfires. I don't think the lack of deployed standard writable YANG models is due to the coarse grained conformance model... /martin From andyb@iwl.com Mon Jun 28 09:23:26 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06A33A68CE for ; Mon, 28 Jun 2010 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYNCY6xNbDXq for ; Mon, 28 Jun 2010 09:23:26 -0700 (PDT) Received: from smtp135.dfw.emailsrvr.com (smtp135.dfw.emailsrvr.com [67.192.241.135]) by core3.amsl.com (Postfix) with ESMTP id 04D6E3A6A56 for ; Mon, 28 Jun 2010 09:23:25 -0700 (PDT) Received: from relay23.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 2D8EF156813C; Mon, 28 Jun 2010 12:23:35 -0400 (EDT) Received: by relay23.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D86661568130; Mon, 28 Jun 2010 12:23:34 -0400 (EDT) Message-ID: <4C28CCC6.4000200@iwl.com> Date: Mon, 28 Jun 2010 09:24:38 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C278972.6050802@iwl.com> <20100628.170936.66613553.mbj@tail-f.com> <4C28BFDC.2000507@iwl.com> <20100628.174740.233831854.mbj@tail-f.com> In-Reply-To: <20100628.174740.233831854.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:23:27 -0000 On 06/28/2010 08:47 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > >> On 06/28/2010 08:09 AM, Martin Bjorklund wrote: >> >>> Hi, >>> >>> Andy Bierman wrote: >>> >>> >>>> Hi, >>>> >>>> I am not proposing any changes to the YANG spec, but I think >>>> more work is needed on conformance. The current simplistic model >>>> is extremely deficient in 3 ways: >>>> >>>> 1) no way to have a mandatory-to-implement non-config leaf >>>> that is conditional on the description-stmt. >>>> - if mandatory=true then it MUST be in a non-filtered reply >>>> - if mandatory=FALSE then it is optional-to-implement >>>> by the server, >>>> >>>> >>> mandatory false does not mean that it is optional to implement. In >>> some (most?) cases the difference doesn't matter though. >>> >>> >> >> Yes it does for a non-config leaf. >> It means the server never has to send the node -- ever. >> That means every config=false data node, every >> RPC output node and every notification node, unless they >> are marked mandatory=true, do not have to be implemented. >> > Can you point me to where the YANG spec says that a server can choose > to not implement a mandatory false leaf? > > If a vendor never ever has to return a node, then how would the client know if it is implemented or not? Please explain to me why a config=false node is mandatory to implement since it never has to be returned by the server. If it is optional to provide read access to a read-only object, then 100% of the applicable NETCONF operations are optional. > As I wrote above, I agree that in some cases a valid implementation > strategy can be to not implement such a leaf, but it all depends on > the semantics of the leaf. > > It is a great marketing strategy ;-) "We implement every counter in the world, except none of them can be retrieved. A minor technicality." >>>> - the client has no way to know if a config=false and >>>> non-mandatory object is implemented on a particular server >>>> from the message >>>> >>>> 2) no way to allow read-only MIN-ACCESS for a config node >>>> as part of the conformance options. Deviations are not >>>> allowed in standard modules, so they do not help. They >>>> also indicate a lack of conformance, not a conformance option. >>>> >>>> >>> See Randy's reply. >>> >>> >> See my reply to Randy's reply. >> I would love to be proven wrong by >> seeing any meaningful standard CM data models >> emerge from the IETF. How many implementations >> of the ipfix-psamp model exist? Zero? >> How many other YANG modules with any >> writable objects at all? Zero? >> Sometimes this all-or-nothing approach backfires. >> > I don't think the lack of deployed standard writable YANG models is > due to the coarse grained conformance model... > > It is possible that 20 years of working on standardizing MIB modules will have no relevance to YANG data modeling, but I doubt it. Getting vendors to agree on having a writable object at all often required a read-only MIN-ACCESS or there never would have been WG consensus to add the object. If you take that bargaining chip off the table, the result might be that the set of objects with WG consensus is near empty. We shall find out eventually. > /martin > > Andy From mbj@tail-f.com Mon Jun 28 11:16:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558293A6935 for ; Mon, 28 Jun 2010 11:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciIesfKpZKid for ; Mon, 28 Jun 2010 11:16:30 -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 B15DE3A693C for ; Mon, 28 Jun 2010 11:16:29 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 45791616001; Mon, 28 Jun 2010 20:16:38 +0200 (CEST) Date: Mon, 28 Jun 2010 20:16:37 +0200 (CEST) Message-Id: <20100628.201637.206251800.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4C28CCC6.4000200@iwl.com> References: <4C28BFDC.2000507@iwl.com> <20100628.174740.233831854.mbj@tail-f.com> <4C28CCC6.4000200@iwl.com> X-Mailer: Mew version 7.0.50 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules 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 Jun 2010 18:16:31 -0000 Andy Bierman wrote: > On 06/28/2010 08:47 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > >> On 06/28/2010 08:09 AM, Martin Bjorklund wrote: > >> > >>> Hi, > >>> > >>> Andy Bierman wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> I am not proposing any changes to the YANG spec, but I think > >>>> more work is needed on conformance. The current simplistic model > >>>> is extremely deficient in 3 ways: > >>>> > >>>> 1) no way to have a mandatory-to-implement non-config leaf > >>>> that is conditional on the description-stmt. > >>>> - if mandatory=true then it MUST be in a non-filtered reply > >>>> - if mandatory=FALSE then it is optional-to-implement > >>>> by the server, > >>>> > >>>> > >>> mandatory false does not mean that it is optional to implement. In > >>> some (most?) cases the difference doesn't matter though. > >>> > >>> > >> > >> Yes it does for a non-config leaf. > >> It means the server never has to send the node -- ever. > >> That means every config=false data node, every > >> RPC output node and every notification node, unless they > >> are marked mandatory=true, do not have to be implemented. > >> > > Can you point me to where the YANG spec says that a server can choose > > to not implement a mandatory false leaf? > > > > > > If a vendor never ever has to return a node, > then how would the client know if it is implemented > or not? That's not the point. You originally wrote that mandatory is a way to do conformance; that mandatory false means that the node is optional to implement. I'm saying that this is not true. Please see section 5.6 of the YANG spec - it doesn't mention mandatory. > Please explain to me why a config=false node > is mandatory to implement since it never has > to be returned by the server. It all depends on the semantics of the object, e.g. leaf enable-break-in-attempts-checking { type boolean; config true; } leaf break-in-attempts { type yang:counter32; config false; mandatory false; } If enable-break-in-attempts-checking is implemented and set to true, the server is still not free to simply not implement the counter. [Sure, this can be modelled in other ways, but that's not the point] /martin From andyb@iwl.com Mon Jun 28 11:22:50 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8CD3A6929 for ; Mon, 28 Jun 2010 11:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIEeHX-Si4Vg for ; Mon, 28 Jun 2010 11:22:47 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 99ED93A691F for ; Mon, 28 Jun 2010 11:22:46 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 984B93F0909; Mon, 28 Jun 2010 14:22:55 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 66BF03EF264; Mon, 28 Jun 2010 14:22:55 -0400 (EDT) Message-ID: <4C28E8C0.7030109@iwl.com> Date: Mon, 28 Jun 2010 11:24:00 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C28BFDC.2000507@iwl.com> <20100628.174740.233831854.mbj@tail-f.com> <4C28CCC6.4000200@iwl.com> <20100628.201637.206251800.mbj@tail-f.com> In-Reply-To: <20100628.201637.206251800.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 18:22:50 -0000 On 06/28/2010 11:16 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > >> On 06/28/2010 08:47 AM, Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>> >>> >>>> On 06/28/2010 08:09 AM, Martin Bjorklund wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I am not proposing any changes to the YANG spec, but I think >>>>>> more work is needed on conformance. The current simplistic model >>>>>> is extremely deficient in 3 ways: >>>>>> >>>>>> 1) no way to have a mandatory-to-implement non-config leaf >>>>>> that is conditional on the description-stmt. >>>>>> - if mandatory=true then it MUST be in a non-filtered reply >>>>>> - if mandatory=FALSE then it is optional-to-implement >>>>>> by the server, >>>>>> >>>>>> >>>>>> >>>>> mandatory false does not mean that it is optional to implement. In >>>>> some (most?) cases the difference doesn't matter though. >>>>> >>>>> >>>>> >>>> Yes it does for a non-config leaf. >>>> It means the server never has to send the node -- ever. >>>> That means every config=false data node, every >>>> RPC output node and every notification node, unless they >>>> are marked mandatory=true, do not have to be implemented. >>>> >>>> >>> Can you point me to where the YANG spec says that a server can choose >>> to not implement a mandatory false leaf? >>> >>> >>> >> If a vendor never ever has to return a node, >> then how would the client know if it is implemented >> or not? >> > That's not the point. You originally wrote that mandatory is a way to > do conformance; that mandatory false means that the node is optional > to implement. I'm saying that this is not true. Please see section > 5.6 of the YANG spec - it doesn't mention mandatory. > > When reading a YANG object, and there is no explanation whatsoever when/why the server MUST return a value, then the reader must assume there are no conditions and it is completely up to the server implementor to decide. > >> Please explain to me why a config=false node >> is mandatory to implement since it never has >> to be returned by the server. >> > It all depends on the semantics of the object, e.g. > > leaf enable-break-in-attempts-checking { > type boolean; > config true; > } > leaf break-in-attempts { > type yang:counter32; > config false; > mandatory false; > } > > If enable-break-in-attempts-checking is implemented and set to true, > the server is still not free to simply not implement the counter. > > [Sure, this can be modelled in other ways, but that's not the point] > > This is fine, except not quite for modules submitted to the IETF. Every 'single config=false and non-mandatory' node needs to explain in the description-stmt the conditions in which the node MUST be available for retrieval. This needs to be added to the YANG usage spec. > /martin > > Andy From andyb@iwl.com Mon Jun 28 11:33:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024443A6935 for ; Mon, 28 Jun 2010 11:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] 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 tuGn8L1jKQnF for ; Mon, 28 Jun 2010 11:33:39 -0700 (PDT) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id D3AC53A6947 for ; Mon, 28 Jun 2010 11:33:31 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id CF1691B4052; Mon, 28 Jun 2010 14:33:34 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 886A61B404E; Mon, 28 Jun 2010 14:33:34 -0400 (EDT) Message-ID: <4C28EB3F.604@iwl.com> Date: Mon, 28 Jun 2010 11:34:39 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <4C28BFDC.2000507@iwl.com> <20100628.174740.233831854.mbj@tail-f.com> <4C28CCC6.4000200@iwl.com> <20100628.201637.206251800.mbj@tail-f.com> In-Reply-To: <20100628.201637.206251800.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 18:33:50 -0000 On 06/28/2010 11:16 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > >> On 06/28/2010 08:47 AM, Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>> >>> >>>> On 06/28/2010 08:09 AM, Martin Bjorklund wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I am not proposing any changes to the YANG spec, but I think >>>>>> more work is needed on conformance. The current simplistic model >>>>>> is extremely deficient in 3 ways: >>>>>> >>>>>> 1) no way to have a mandatory-to-implement non-config leaf >>>>>> that is conditional on the description-stmt. >>>>>> - if mandatory=true then it MUST be in a non-filtered reply >>>>>> - if mandatory=FALSE then it is optional-to-implement >>>>>> by the server, >>>>>> >>>>>> >>>>>> >>>>> mandatory false does not mean that it is optional to implement. In >>>>> some (most?) cases the difference doesn't matter though. >>>>> >>>>> >>>>> >>>> Yes it does for a non-config leaf. >>>> It means the server never has to send the node -- ever. >>>> That means every config=false data node, every >>>> RPC output node and every notification node, unless they >>>> are marked mandatory=true, do not have to be implemented. >>>> >>>> >>> Can you point me to where the YANG spec says that a server can choose >>> to not implement a mandatory false leaf? >>> >>> >>> >> If a vendor never ever has to return a node, >> then how would the client know if it is implemented >> or not? >> > That's not the point. You originally wrote that mandatory is a way to > do conformance; that mandatory false means that the node is optional > to implement. I'm saying that this is not true. Please see section > 5.6 of the YANG spec - it doesn't mention mandatory. > > > >> Please explain to me why a config=false node >> is mandatory to implement since it never has >> to be returned by the server. >> > It all depends on the semantics of the object, e.g. > > leaf enable-break-in-attempts-checking { > type boolean; > config true; > } > leaf break-in-attempts { > Add: when "../enable-break-in-attempts"; > type yang:counter32; > config false; > mandatory false; > } > > If enable-break-in-attempts-checking is implemented and set to true, > the server is still not free to simply not implement the counter. > > [Sure, this can be modelled in other ways, but that's not the point] > > I understand now -- the YANG guidelines need to make it mandatory to provide the optionality conditions in a description-stmt if a when-stmt is not applicable. > /martin > > Andy From dromasca@avaya.com Tue Jun 29 02:01:04 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D4B3A684A for ; Tue, 29 Jun 2010 02:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_40=-0.185] 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 D3+iQSmBbB7E for ; Tue, 29 Jun 2010 02:01:04 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id C1A1F3A635F for ; Tue, 29 Jun 2010 02:01:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,503,1272859200"; d="scan'208";a="22845476" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 29 Jun 2010 05:01:02 -0400 X-IronPort-AV: E=Sophos;i="4.53,503,1272859200"; d="scan'208";a="487243216" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jun 2010 05:01:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jun 2010 11:00:58 +0200 Message-ID: In-Reply-To: <20100628.174740.233831854.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] NETCONF conformance for YANG modules Thread-Index: AcsW2UF+HxHhkp13QZKQUGLspWg+ZgAjwIwg References: <4C278972.6050802@iwl.com><20100628.170936.66613553.mbj@tail-f.com><4C28BFDC.2000507@iwl.com> <20100628.174740.233831854.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules 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 Jun 2010 09:01:04 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Monday, June 28, 2010 6:48 PM > To: andyb@iwl.com > Cc: netmod@ietf.org > Subject: Re: [netmod] NETCONF conformance for YANG modules >=20 > Andy Bierman wrote: > > On 06/28/2010 08:09 AM, Martin Bjorklund wrote: ... > > How many implementations of the ipfix-psamp model exist? Zero? > > How many other YANG modules with any > > writable objects at all? Zero? > > Sometimes this all-or-nothing approach backfires. >=20 > I don't think the lack of deployed standard writable YANG=20 > models is due to the coarse grained conformance model... >=20 Is not it too early to start drawing conclusions about the lack of deployed standard writeable YANG models? We do not have the YANG RFC published yet. No coordinated effort was started to develop standard YANG models. Actually I start to become concerned that I do not see activity on this respect here - there seem to be more interest to use YANG to write models out of the netconf/netmod community than inside it. We just have fragments in examples in the various I-Ds. Is anybody working on the equivalent of MIB-II, Interfaces MIB, Entity MIB, etc. in YANG?=20 Dan From david.partain@ericsson.com Tue Jun 29 04:44:34 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335863A6A77 for ; Tue, 29 Jun 2010 04:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 6yiW9zcmQEnv for ; Tue, 29 Jun 2010 04:44:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 038BF3A6AB4 for ; Tue, 29 Jun 2010 04:44:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-8c-4c29dcaa8eb4 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.FF.10125.AACD92C4; Tue, 29 Jun 2010 13:44:43 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:44:42 +0200 Received: from selic022.ki.sw.ericsson.se ([147.214.22.183]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:42:41 +0200 From: David Partain Organization: Ericsson To: "netmod@ietf.org" Date: Tue, 29 Jun 2010 13:42:41 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201006291342.41399.david.partain@ericsson.com> X-OriginalArrivalTime: 29 Jun 2010 11:42:41.0763 (UTC) FILETIME=[2EBDBB30:01CB1780] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Call for NETMOD Agenda Items for Maastricht 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 Jun 2010 11:44:34 -0000 Greetings, Our current status on documents is: 1. YANG - In the RFC Editor queue (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang/) 2. Common YANG Data Types - In the RFC Editor queue (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-types/) 3. Guidelines for Authors and Reviewers of YANG Data Model Documents - In IETF Last Call, which ends 2010-07-08 (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-usage/) 4. An Architecture for Network Management using NETCONF and YANG - Submitted to the IESG Secretary today to request publication. Should show up in the tracker soon and sent out for IETF Last Call when Dan requests it. 5. Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content - Currently in WGLC. When that is done, will be submitted for publication to the IESG Secretary. Unless something dramatic happens, this will happen next Monday. This means that all of our chartered work is nearing completion. We will, nonetheless, meet in Maastricht and have a 2.5 hour slot. As such, if you have a topic that you would like to present at the meeting, please let The Davids know as soon as possible. Of particular interest would be any work that you have done on YANG models that you would like to present and get feedback on. Note that the cut-off date for -00 internet drafts is on Mon, July 5 (see http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78) Thanks. David From j.schoenwaelder@jacobs-university.de Tue Jun 29 08:20:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEDB3A690D for ; Tue, 29 Jun 2010 08:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 5h63TacCOJFu for ; Tue, 29 Jun 2010 08:20:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BDB383A68DF for ; Tue, 29 Jun 2010 08:20:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F7F9C0009; Tue, 29 Jun 2010 17:20:26 +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 fovTpmjAy6js; Tue, 29 Jun 2010 17:20:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 050E3C0002; Tue, 29 Jun 2010 17:20:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5777213712B6; Tue, 29 Jun 2010 17:20:24 +0200 (CEST) Date: Tue, 29 Jun 2010 17:20:24 +0200 From: Juergen Schoenwaelder To: David Partain Message-ID: <20100629152023.GA35692@elstar.local> Mail-Followup-To: David Partain , "netmod@ietf.org" References: <201006291342.41399.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006291342.41399.david.partain@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Call for NETMOD Agenda Items for Maastricht 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 Jun 2010 15:20:17 -0000 On Tue, Jun 29, 2010 at 01:42:41PM +0200, David Partain wrote: > Of particular interest would be any work that you have done on YANG > models that you would like to present and get feedback on. Note > that the cut-off date for -00 internet drafts is on Mon, July 5 (see > http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78) At IETF 75 (one year ago), I presented how libsmi translates SMIv2 to YANG (the YANG version valid about 1.5 years ago). The slides are here: http://www.ietf.org/proceedings/75/slides/netmod-0.pdf The meanwhile expired ID is here: http://tools.ietf.org/html/draft-schoenw-netmod-smi-yang-00 I do not plan to repeat this presentation. But if the WG plans to recharter, than this work might be considered as a possible work item. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jun 29 12:05:43 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A775D3A67B1 for ; Tue, 29 Jun 2010 12:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.271 X-Spam-Level: X-Spam-Status: No, score=-0.271 tagged_above=-999 required=5 tests=[AWL=0.286, 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 df3kNgWD5+jJ for ; Tue, 29 Jun 2010 12:05:43 -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 C6C123A66B4 for ; Tue, 29 Jun 2010 12:05:42 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 0704B616002; Tue, 29 Jun 2010 21:05:52 +0200 (CEST) Date: Tue, 29 Jun 2010 21:05:50 +0200 (CEST) Message-Id: <20100629.210550.233280071.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: <4C28BFDC.2000507@iwl.com> <20100628.174740.233831854.mbj@tail-f.com> X-Mailer: Mew version 7.0.50 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NETCONF conformance for YANG modules 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 Jun 2010 19:05:43 -0000 "Romascanu, Dan (Dan)" wrote: > > > > -----Original Message----- > > From: netmod-bounces@ietf.org > > [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund > > Sent: Monday, June 28, 2010 6:48 PM > > To: andyb@iwl.com > > Cc: netmod@ietf.org > > Subject: Re: [netmod] NETCONF conformance for YANG modules > > > > Andy Bierman wrote: > > > On 06/28/2010 08:09 AM, Martin Bjorklund wrote: > > ... > > > > How many implementations of the ipfix-psamp model exist? Zero? > > > How many other YANG modules with any > > > writable objects at all? Zero? > > > Sometimes this all-or-nothing approach backfires. > > > > I don't think the lack of deployed standard writable YANG > > models is due to the coarse grained conformance model... > > > > Is not it too early to start drawing conclusions about the lack of > deployed standard writeable YANG models? We do not have the YANG RFC > published yet. Exactly my point. > No coordinated effort was started to develop standard > YANG models. Actually I start to become concerned that I do not see > activity on this respect here - there seem to be more interest to use > YANG to write models out of the netconf/netmod community than inside it. > We just have fragments in examples in the various I-Ds. Is anybody > working on the equivalent of MIB-II, Interfaces MIB, Entity MIB, etc. in > YANG? There is NACM (expect an update RSN) and Andy also published his system module, which I hope we will discuss in Maastricht. There is some informal discussions about interface configuration going on as well... /martin