From j.schoenwaelder@jacobs-university.de Mon Mar 1 08:02: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 2E47E3A8B8B for ; Mon, 1 Mar 2010 08:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sKKhaO5j016f for ; Mon, 1 Mar 2010 08:02:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EA8BE3A8B87 for ; Mon, 1 Mar 2010 08:02:53 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31B0BC0007 for ; Mon, 1 Mar 2010 17:02:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XQ99Gofgh5QK; Mon, 1 Mar 2010 17:02:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2ED1C0011; Mon, 1 Mar 2010 17:02:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6369310A0AE1; Mon, 1 Mar 2010 17:02:34 +0100 (CET) Date: Mon, 1 Mar 2010 17:02:34 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20100301160234.GA43607@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [netmod] js review of draft-ietf-netmod-arch-03.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: Mon, 01 Mar 2010 16:02:55 -0000 Hi, I have read draft-ietf-netmod-arch-03.txt and I believe the document needs more work and is not yet ready to go to the IESG. My main concern is that the document looks like a collection of ideas related to NETCONF/NETMOD without a clear storyline. Some parts read like a highlevel summary of NETCONF/YANG (which is however somewhat incomplete in the discussion of NETCONF/YANG cool features) while other parts read like advise implementors, data modelers or any future NETCONF/NETMOD extensions. The section titled "An Architecture for NETMOD" essentially talks about the benefit of discovering data models via the capability exchange. It seems the WG needs to find out what this document's contribution and focus should be. More detailed comments: a] Section 1 is not needed since the document does not use RFC 2119 language. And if it would, I 'd prefer to have this RFC 2119 language note at the end of the section "Introduction". b] p5: probably an explanation should be given what "CLI world" means c] p6,p8,p9,p10: In the examples, I think we should avoid names that look like IETF official names, resorting to reserved example names and IP addresses. d] The NETCONF summary is very short, leaving out aspects where NETCONF really shines, e.g. the support of different transaction models. Now, this might be on purpose - depending on what the focus of this document is going to be. e] Should the document also refer to other NETCONF features such as support for notifications? Right now, the document only talks about RFC 4741. If the purpose is to provide an introduction, we might have to introduce _all_ the pieces that are part of the NETCONF / NETMOD technology. f] p8: The data model should use appropriate uint8/uint16 types - the type uint does not really exist in YANG. Also, ospf-types might be more appropriate than network-types. g] There are a number of missing references where the text either says [ref] or it says something like [DSDL] that does not appear in the reference list. h] p12: what is "the provider"? Should it be "network operators"? i] p21: s/that provide explicitely/that explicitely/ j] The security considerations look like a cut 'n paste error. /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 Mon Mar 1 15:04:11 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 B721D28C204 for ; Mon, 1 Mar 2010 15:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApcMhMKLLCLa for ; Mon, 1 Mar 2010 15:04:11 -0800 (PST) Received: from smtp235.iad.emailsrvr.com (smtp235.iad.emailsrvr.com [207.97.245.235]) by core3.amsl.com (Postfix) with ESMTP id 47D8D28C1FD for ; Mon, 1 Mar 2010 15:04:10 -0800 (PST) Received: from relay13.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9D8211CF1C6 for ; Mon, 1 Mar 2010 18:04:10 -0500 (EST) Received: by relay13.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6DFA81CF0B0 for ; Mon, 1 Mar 2010 18:04:10 -0500 (EST) Message-ID: <4B8C47F5.1020903@iwl.com> Date: Mon, 01 Mar 2010 15:04:21 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: netmod@ietf.org References: <20100301160234.GA43607@elstar.local> In-Reply-To: <20100301160234.GA43607@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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: Mon, 01 Mar 2010 23:04:11 -0000 Juergen Schoenwaelder wrote: > Hi, > > I have read draft-ietf-netmod-arch-03.txt and I believe the document > needs more work and is not yet ready to go to the IESG. > > My main concern is that the document looks like a collection of ideas > related to NETCONF/NETMOD without a clear storyline. Some parts read > like a highlevel summary of NETCONF/YANG (which is however somewhat > incomplete in the discussion of NETCONF/YANG cool features) while > other parts read like advise implementors, data modelers or any future > NETCONF/NETMOD extensions. The section titled "An Architecture for > NETMOD" essentially talks about the benefit of discovering data models > via the capability exchange. It seems the WG needs to find out what > this document's contribution and focus should be. > I agree with your concerns, but I have a specific concern about the 'transformations' discussed in section 3: If the device doesn't implement such a standard or no such standard exists, the application may use a transformation that is particular to that device's vendor, product model, hardware, or software. Depending on the application, this transformation may be provided by the application vendor, the device vendor, a third-party, or the provider. For a popular application, the device vendor may wish to provide this transformation to increase market acceptance of their devices. For popular devices, the application may provide this transformation as a means of making the application useful in the maximum number of provider networks. For problem domains where the mapping from the application to the device is not straight-forward or requires tailoring to the specific provider or environment, the provider may wish to control this transformation. Additionally, other parties may make such transformations available via open source. I don't think this document needs to talk about server implementation details, and refer to undefined transformations that the application developer may be able to use. How the server magically produces correct and outputs is not really an architecture issue. If the server developer want to support module X, object X1, and wants to do it by 'plugging in' the code for module Y, object Y1, that is up to the server vendor. > /js > Andy From phil@juniper.net Mon Mar 1 23:36: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 D00EB28C684 for ; Mon, 1 Mar 2010 23:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QVJ0eHsAicqT for ; Mon, 1 Mar 2010 23:36:45 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id DD14028C6DE for ; Mon, 1 Mar 2010 23:36:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKS4zADMnb1ZOpnsvALwcQOuHvP2JjhksD@postini.com; Mon, 01 Mar 2010 23:36:46 PST 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.1.393.1; Mon, 1 Mar 2010 23:35:01 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 23:35:01 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 23:35:01 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 23:35:00 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o227Z0D22028; Mon, 1 Mar 2010 23:35:00 -0800 (PST) (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 o227Itpj092581; Tue, 2 Mar 2010 07:18:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003020718.o227Itpj092581@idle.juniper.net> To: In-Reply-To: <4B8C47F5.1020903@iwl.com> Date: Tue, 2 Mar 2010 02:18:55 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Mar 2010 07:35:00.0810 (UTC) FILETIME=[DDC402A0:01CAB9DA] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 07:36:46 -0000 Andy Bierman writes: >I don't think this document needs to talk about server implementation >details, and refer to undefined transformations that the application >developer may be able to use. This section tries to illustrate how YANG and NETCONF are able to help the development of new standards while handling devices that do not support those standards. IMHO this is an important feature, but I will happily remove it if that is the WG concensus. Thanks, Phil From phil@juniper.net Mon Mar 1 23:46: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 7F7343A88DC for ; Mon, 1 Mar 2010 23:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCbZ+TYkbn-v for ; Mon, 1 Mar 2010 23:46:32 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 950D33A88D9 for ; Mon, 1 Mar 2010 23:46:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS4zCVPnaDunyPSvsBRbI4W9JFglQQNpp@postini.com; Mon, 01 Mar 2010 23:46:33 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 1 Mar 2010 23:45:18 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 23:45:17 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 23:45:17 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 23:45:17 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o227jGD25717; Mon, 1 Mar 2010 23:45:16 -0800 (PST) (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 o227TABb092673; Tue, 2 Mar 2010 07:29:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003020729.o227TABb092673@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100301160234.GA43607@elstar.local> Date: Tue, 2 Mar 2010 02:29:10 -0500 From: Phil Shafer X-OriginalArrivalTime: 02 Mar 2010 07:45:17.0341 (UTC) FILETIME=[4D3F2CD0:01CAB9DC] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 07:46:33 -0000 Juergen Schoenwaelder writes: >It seems the WG needs to find out what >this document's contribution and focus should be. I concur. Should the focus be closed until only the current WG documents (YANG, YIN, DSDL) are discussed? Should it discuss how YANG fits into the device, or the application? Or the problem domain being addressed? Is it an overview? There have been many objections to content (and removals), so I guess I'm confused about where this document fits and what it is allowed to say. Please advise. Thanks, Phil From j.schoenwaelder@jacobs-university.de Tue Mar 2 00:45:08 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 31A6E3A70E2 for ; Tue, 2 Mar 2010 00:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Y1neoB8Aje+f for ; Tue, 2 Mar 2010 00:45:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 15B3C3A7607 for ; Tue, 2 Mar 2010 00:45:07 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42C8DC0010; Tue, 2 Mar 2010 09:45:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NMpesnXKEOxu; Tue, 2 Mar 2010 09:45:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3359C000A; Tue, 2 Mar 2010 09:45:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5628A10AD2B3; Tue, 2 Mar 2010 09:44:46 +0100 (CET) Date: Tue, 2 Mar 2010 09:44:46 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100302084446.GA47604@elstar.local> Mail-Followup-To: Phil Shafer , "netmod@ietf.org" References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003020729.o227TABb092673@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-03.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: Tue, 02 Mar 2010 08:45:08 -0000 On Tue, Mar 02, 2010 at 08:29:10AM +0100, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >It seems the WG needs to find out what > >this document's contribution and focus should be. > > I concur. Should the focus be closed until only the current WG > documents (YANG, YIN, DSDL) are discussed? Should it discuss how > YANG fits into the device, or the application? Or the problem > domain being addressed? Is it an overview? > > There have been many objections to content (and removals), so I > guess I'm confused about where this document fits and what it is > allowed to say. > > Please advise. Right now, the document contains fragments of the following: 1) Overview of NETCONF and YANG, highlighting special features, explaining how they can be used in practice Likely makes a lot of sense sense, but then I happen to know that there is an IEEE Communications Magazine paper in the printing pipeline that does try to address this. But yes, I am aware that not everybody has access to the IEEE library and surely there is no IETF concensus on this paper - so it might be still worthwhile to produce a similar RFC. 2) Advise to NETCONF and YANG implementors (servers and apps) Might make sense, but might also take time to get agreement on and I am not sure how many implementors are going to actively contribute to this. 3) Advise to YANG data model writers Might make sense, but I am not sure how much advise we really have. The down to earth part is going to be part of the usage document . 4) Advise to the evolution of NETCONF and YANG I guess this is really going to be difficult to find agreement on. None of these things I really consider an architecture. ;-) Anyway, the WG needs to figure out (a) what the WG really wants and (b) what the resources are to write the document the WG wants. There is also the option to simply drop the ball on this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Tue Mar 2 01: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 887333A8A24; Tue, 2 Mar 2010 01:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100302090001.887333A8A24@core3.amsl.com> Date: Tue, 2 Mar 2010 01:00:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-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, 02 Mar 2010 09: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-05.txt Pages : 119 Date : 2010-03-02 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 used 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 PDU 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-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-02005839.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Tue Mar 2 02:59: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 677653A8768 for ; Tue, 2 Mar 2010 02:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 r1+579GzdqSU for ; Tue, 2 Mar 2010 02:59:19 -0800 (PST) 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 08C353A863F for ; Tue, 2 Mar 2010 02:59:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="5803299" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 02 Mar 2010 05:59:19 -0500 X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="451133251" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Mar 2010 05:59:18 -0500 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, 2 Mar 2010 11:59:07 +0100 Message-ID: In-Reply-To: <20100302084446.GA47604@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] js review of draft-ietf-netmod-arch-03.txt Thread-Index: Acq55K4/4Ugh3MquTeGHEk/Cn4fldwAETsPQ References: <20100301160234.GA43607@elstar.local><201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 10:59:20 -0000 It looks like we have lost the premises of this document, and what we had in mind when we started it. When NETMOD was chartered there were a lot of discussions why we need it, what are the alternatives, and how it fits in the landscape of NETCONF, other ways of writing data models, mappings and translations. The best we could come before the charter was approved was a napkin diagram in the good tradition of the IETF which I remember that Mehmet photographed. It may be interesting to produce that picture for future historians, but this is not the goal of this discussion. We thought at that point in time that we need to write a document that describes how NETMOD interconnects with other components of the NETMOD family of protocols and possible other network management framework components.=20 FWIW the text we put in the WG charter is:=20 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) I still think that we need this document. If we do not explain well to ourselves and to the rest of the IETF what we are doing and how it fits in the broader NM and IETF landscape the YANG effort has less chances of success. I do not think that the current version covers well this scope, maybe only #1 in Juergen's list to some extent, but the rest may be useful but it is not in scope.=20 Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 02, 2010 10:45 AM > To: Phil Shafer > Cc: netmod@ietf.org > Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt >=20 > On Tue, Mar 02, 2010 at 08:29:10AM +0100, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > > >It seems the WG needs to find out what this document's=20 > contribution=20 > > >and focus should be. > >=20 > > I concur. Should the focus be closed until only the current WG=20 > > documents (YANG, YIN, DSDL) are discussed? Should it=20 > discuss how YANG=20 > > fits into the device, or the application? Or the problem=20 > domain being=20 > > addressed? Is it an overview? > >=20 > > There have been many objections to content (and removals),=20 > so I guess=20 > > I'm confused about where this document fits and what it is=20 > allowed to=20 > > say. > >=20 > > Please advise. >=20 > Right now, the document contains fragments of the following: >=20 > 1) Overview of NETCONF and YANG, highlighting special features, > explaining how they can be used in practice >=20 > Likely makes a lot of sense sense, but then I happen to know that > there is an IEEE Communications Magazine paper in the printing > pipeline that does try to address this. But yes, I am aware that > not everybody has access to the IEEE library and surely there is no > IETF concensus on this paper - so it might be still worthwhile to > produce a similar RFC. >=20 > 2) Advise to NETCONF and YANG implementors (servers and apps) >=20 > Might make sense, but might also take time to get agreement on and > I am not sure how many implementors are going to actively > contribute to this. > =20 > 3) Advise to YANG data model writers >=20 > Might make sense, but I am not sure how much advise we really > have. The down to earth part is going to be part of the usage > document . >=20 > 4) Advise to the evolution of NETCONF and YANG >=20 > I guess this is really going to be difficult to find agreement > on. >=20 > None of these things I really consider an architecture. ;-)=20 > Anyway, the WG needs to figure out (a) what the WG really=20 > wants and (b) what the resources are to write the document=20 > the WG wants. There is also the option to simply drop the=20 > ball on this document. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From j.schoenwaelder@jacobs-university.de Tue Mar 2 03:20: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 8F94C3A7622 for ; Tue, 2 Mar 2010 03:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AQ0X6FZCJ9y0 for ; Tue, 2 Mar 2010 03:20:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6FED83A8640 for ; Tue, 2 Mar 2010 03:20:05 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D049C000A; Tue, 2 Mar 2010 12:20:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZeURJmwkyLQy; Tue, 2 Mar 2010 12:20:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A183BC0008; Tue, 2 Mar 2010 12:20:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E45FC10ADECD; Tue, 2 Mar 2010 12:19:45 +0100 (CET) Date: Tue, 2 Mar 2010 12:19:45 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100302111945.GB48768@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Phil Shafer , "netmod@ietf.org" References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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: Tue, 02 Mar 2010 11:20:12 -0000 On Tue, Mar 02, 2010 at 11:59:07AM +0100, Romascanu, Dan (Dan) wrote: > It looks like we have lost the premises of this document, and what we > had in mind when we started it. > > When NETMOD was chartered there were a lot of discussions why we need > it, what are the alternatives, and how it fits in the landscape of > NETCONF, other ways of writing data models, mappings and translations. > The best we could come before the charter was approved was a napkin > diagram in the good tradition of the IETF which I remember that Mehmet > photographed. It may be interesting to produce that picture for future > historians, but this is not the goal of this discussion. We thought at > that point in time that we need to write a document that describes how > NETMOD interconnects with other components of the NETMOD family of > protocols and possible other network management framework components. > > FWIW the text we put in the WG charter is: > > 1. An architecture document explaining the relationship > between YANG and its inputs and outputs. (informational) This sentence is close to a joke. Here is the answer to it: YANG is a language for writing NETCONF data models. YANG tools process data models written in the YANG language as input and produce other representations, translations, code stubs, documentation etc. as output. Is this the document we are after? Could be a one page document plus N pages of boilerplate. ;-) > I still think that we need this document. If we do not explain well to > ourselves and to the rest of the IETF what we are doing and how it fits > in the broader NM and IETF landscape the YANG effort has less chances of > success. I do not think that the current version covers well this > scope, maybe only #1 in Juergen's list to some extent, but the rest may > be useful but it is not in scope. Now you talk about how NETCONF/YANG fits into the rest of the IETF, which is IMHO very different from "explaining the relationship between YANG and its inputs and outputs". Explaining how NETCONF/YANG fits into the IETF's collection of protocols might make sense, but it seems the charter text does not really point to this. I believe the WG needs to find the answer what the document should cover. So let me add your proposal to the list: 1) Overview of NETCONF and YANG, highlighting special features, explaining how they can be used in practice 2) Advise to NETCONF and YANG implementors (servers and apps) 3) Advise to YANG data model writers 4) Advise to the evolution of NETCONF and YANG 5) Overview how NETCONF/YANG fits into the collection of IETF (network management) protocols Any other proposals? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Mar 2 03:35: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 08D333A7D1E for ; Tue, 2 Mar 2010 03:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 Ys-ziYTs4-dG for ; Tue, 2 Mar 2010 03:35:19 -0800 (PST) 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 541403A87B0 for ; Tue, 2 Mar 2010 03:35:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="5806819" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 02 Mar 2010 06:35:18 -0500 X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="437239919" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Mar 2010 06:34:38 -0500 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, 2 Mar 2010 12:34:16 +0100 Message-ID: In-Reply-To: <20100302111945.GB48768@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] js review of draft-ietf-netmod-arch-03.txt Thread-Index: Acq5+lInxATJUkLYS6CJrmkpZL3t9QAAFH6Q References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 11:35:21 -0000 See in-line.=20 Regards, Dan =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, March 02, 2010 1:20 PM > To: Romascanu, Dan (Dan) > Cc: Phil Shafer; netmod@ietf.org > Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt >=20 > On Tue, Mar 02, 2010 at 11:59:07AM +0100, Romascanu, Dan (Dan) wrote: > > It looks like we have lost the premises of this document,=20 > and what we=20 > > had in mind when we started it. > >=20 > > When NETMOD was chartered there were a lot of discussions=20 > why we need=20 > > it, what are the alternatives, and how it fits in the landscape of=20 > > NETCONF, other ways of writing data models, mappings and=20 > translations. > > The best we could come before the charter was approved was a napkin=20 > > diagram in the good tradition of the IETF which I remember=20 > that Mehmet=20 > > photographed. It may be interesting to produce that picture=20 > for future=20 > > historians, but this is not the goal of this discussion. We=20 > thought at=20 > > that point in time that we need to write a document that=20 > describes how=20 > > NETMOD interconnects with other components of the NETMOD family of=20 > > protocols and possible other network management framework=20 > components. > >=20 > > FWIW the text we put in the WG charter is:=20 > >=20 > > 1. An architecture document explaining the relationship=20 > between YANG=20 > > and its inputs and outputs. (informational) >=20 > This sentence is close to a joke. Here is the answer to it: >=20 > YANG is a language for writing NETCONF data models. YANG tools > process data models written in the YANG language as input and > produce other representations, translations, code stubs, > documentation etc. as output. >=20 > Is this the document we are after? Could be a one page=20 > document plus N pages of boilerplate. ;-) This is why I wrote FWIW :-) In the IETF we are not famous with charter wordsmithing and it may be that the text in the charter is not W too much, and this is why I am trying to get back to the origins of the work. The process of having this WG approved was not easy, the IESG, IAB and participants from other areas in the IETF asked questions and some of these questions may be back now that the WG output approaches the IETF Last Call and IESG reviews.=20 > =20 > > I still think that we need this document. If we do not=20 > explain well to=20 > > ourselves and to the rest of the IETF what we are doing and how it=20 > > fits in the broader NM and IETF landscape the YANG effort has less=20 > > chances of success. I do not think that the current version covers=20 > > well this scope, maybe only #1 in Juergen's list to some=20 > extent, but=20 > > the rest may be useful but it is not in scope. >=20 > Now you talk about how NETCONF/YANG fits into the rest of the=20 > IETF, which is IMHO very different from "explaining the=20 > relationship between YANG and its inputs and outputs".=20 > Explaining how NETCONF/YANG fits into the IETF's collection=20 > of protocols might make sense, but it seems the charter text=20 > does not really point to this.=20 It is not only relations with the IETF collection of protocols, but also about relations with other modes to express data models that can be used by NETCONF, translation and mapping between different DMLs.=20 > I believe the WG needs to find=20 > the answer what the document should cover. So let me add your=20 > proposal to the list: >=20 > 1) Overview of NETCONF and YANG, highlighting special features, > explaining how they can be used in practice >=20 > 2) Advise to NETCONF and YANG implementors (servers and apps) >=20 > 3) Advise to YANG data model writers >=20 > 4) Advise to the evolution of NETCONF and YANG >=20 > 5) Overview how NETCONF/YANG fits into the collection of IETF (network > management) protocols >=20 Thank you for adding my proposal to the list. My opinion is that only part of 1 is within the scope of an architecture document, while 2, 3, and 4 are out of scope (but may be useful items for future work to be chartered).=20 > Any other proposals? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From j.schoenwaelder@jacobs-university.de Tue Mar 2 04:04:00 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 EF7883A880F for ; Tue, 2 Mar 2010 04:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fTByIucn-sJa for ; Tue, 2 Mar 2010 04:04:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D92773A8738 for ; Tue, 2 Mar 2010 04:03:59 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7ADEFC0016; Tue, 2 Mar 2010 13:04:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F1oHqqaYnXa7; Tue, 2 Mar 2010 13:03:59 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A145C0008; Tue, 2 Mar 2010 13:03:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 68F6610AE08A; Tue, 2 Mar 2010 13:03:43 +0100 (CET) Date: Tue, 2 Mar 2010 13:03:43 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100302120343.GD48768@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Phil Shafer , "netmod@ietf.org" References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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: Tue, 02 Mar 2010 12:04:01 -0000 On Tue, Mar 02, 2010 at 12:34:16PM +0100, Romascanu, Dan (Dan) wrote: > It is not only relations with the IETF collection of protocols, but also > about relations with other modes to express data models that can be used > by NETCONF, translation and mapping between different DMLs. YANG -> XSD exists, not specified, because DSDL was more sexy YANG -> DSDL (RNG) exists YANG -> SMIv2 does not make sense YANG -> YIN exists XSD -> YANG nope, full XSD does not make sense and XSD without extensions won't cover what is needed DSDL -> YANG nope, full DSDL does not make sense and DSDL without extensions won't cover what is needed SMIv2 -> YANG expired ID, could be worked out, not chartered YIN -> YANG exists What else do you think needs to be discussed? Do we (have to) care about languages like CIM, GDMO, ... not invented by the IETF? Do we have to include other ad-hoc IETF protocol specific languages, e.g. the templates used for defining IPFIX information models, the somewhat historic SPPI language for COPS-PR? EPP seems to use some form of commented XSD - I would have to check if they allow any XSD or some subset. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Mar 2 04:14:09 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 E39C03A88EC for ; Tue, 2 Mar 2010 04:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BtSOLiq11wIC for ; Tue, 2 Mar 2010 04:14:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B0B6D3A8816 for ; Tue, 2 Mar 2010 04:13:57 -0800 (PST) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7B68F2CDE058 for ; Tue, 2 Mar 2010 13:13:55 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20100302111945.GB48768@elstar.local> References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 02 Mar 2010 13:13:53 +0100 Message-ID: <1267532033.12502.229.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 12:14:10 -0000 Juergen Schoenwaelder píše v Út 02. 03. 2010 v 12:19 +0100: > 1) Overview of NETCONF and YANG, highlighting special features, > explaining how they can be used in practice > > 2) Advise to NETCONF and YANG implementors (servers and apps) > > 3) Advise to YANG data model writers > > 4) Advise to the evolution of NETCONF and YANG > > 5) Overview how NETCONF/YANG fits into the collection of IETF (network > management) protocols 6) Overview of how NETCONF/YANG fits into the XML landscape, explaining in particular its relationship to the existing schema and data modelling languages. Lada > > Any other proposals? > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Tue Mar 2 04:37:44 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 5090E3A87D9 for ; Tue, 2 Mar 2010 04:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5M1cSvCBdFu for ; Tue, 2 Mar 2010 04:37:43 -0800 (PST) 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 26D083A8692 for ; Tue, 2 Mar 2010 04:37:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="207380374" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Mar 2010 07:37:43 -0500 X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="437258292" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Mar 2010 07:37:07 -0500 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, 2 Mar 2010 13:37:04 +0100 Message-ID: In-Reply-To: <20100302120343.GD48768@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] js review of draft-ietf-netmod-arch-03.txt Thread-Index: Acq6AHY+Z/meBJ5qSkGdbKlkV35FkwAAp9Qg References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> <20100302120343.GD48768@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 12:37:44 -0000 This looks quite complete. I think that the focus should be on languages or ways to express XML data models that can work with NETCONF. We need to deal with what is out of the XML realm only to the extent that it helps to understand how the existing installed base of MB modules can be used. This is why I think that talking about SMIv2 -> YANG is still useful. If there are other DMLs that need to be mapped / translated into YANG we can deal with them later.=20 Dan > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, March 02, 2010 2:04 PM > To: Romascanu, Dan (Dan) > Cc: Phil Shafer; netmod@ietf.org > Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt >=20 > On Tue, Mar 02, 2010 at 12:34:16PM +0100, Romascanu, Dan (Dan) wrote: > =20 > > It is not only relations with the IETF collection of protocols, but=20 > > also about relations with other modes to express data=20 > models that can=20 > > be used by NETCONF, translation and mapping between different DMLs. >=20 > YANG -> XSD exists, not specified, because=20 > DSDL was more sexy > YANG -> DSDL (RNG) exists > YANG -> SMIv2 does not make sense > YANG -> YIN exists >=20 > XSD -> YANG nope, full XSD does not make sense and XSD > without extensions won't cover what is needed > DSDL -> YANG nope, full DSDL does not make sense and DSDL > without extensions won't cover what is needed > SMIv2 -> YANG expired ID, could be worked out, not chartered > YIN -> YANG exists >=20 > What else do you think needs to be discussed? Do we (have to)=20 > care about languages like CIM, GDMO, ... not invented by the=20 > IETF? Do we have to include other ad-hoc IETF protocol=20 > specific languages, e.g. the templates used for defining=20 > IPFIX information models, the somewhat historic SPPI language=20 > for COPS-PR? EPP seems to use some form of commented XSD - I=20 > would have to check if they allow any XSD or some subset. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From dromasca@avaya.com Tue Mar 2 04:39: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 DD9233A87D9 for ; Tue, 2 Mar 2010 04:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 epkn5gekuCYB for ; Tue, 2 Mar 2010 04:39:30 -0800 (PST) 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 B93EC3A87F0 for ; Tue, 2 Mar 2010 04:39:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="178569537" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Mar 2010 07:39:28 -0500 X-IronPort-AV: E=Sophos;i="4.49,566,1262581200"; d="scan'208";a="437258871" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Mar 2010 07:38:48 -0500 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, 2 Mar 2010 13:38:31 +0100 Message-ID: In-Reply-To: <1267532033.12502.229.camel@missotis> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] js review of draft-ietf-netmod-arch-03.txt Thread-Index: Acq6AeBwjy6D9dMkSDWoZzAK+b6XGgAA1FNw References: <20100301160234.GA43607@elstar.local><201003020729.o227TABb092673@idle.juniper.net><20100302084446.GA47604@elstar.local><20100302111945.GB48768@elstar.local> <1267532033.12502.229.camel@missotis> From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" , Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 12:39:31 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >=20 > 6) Overview of how NETCONF/YANG fits into the XML landscape,=20 > explaining in particular its relationship to the existing=20 > schema and data modelling languages. >=20 > Lada >=20 >=20 Indeed.=20 Dan From randy_presuhn@mindspring.com Tue Mar 2 14:26: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 DFB3428C252 for ; Tue, 2 Mar 2010 14:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xMHYY7mxP4C for ; Tue, 2 Mar 2010 14:26:37 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id E5AE328C19F for ; Tue, 2 Mar 2010 14:26:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=k5KdvX4bhj+/SfnNGdCITo3Gn6rCMN+ntzL56UapzvaD44CeKVIeAYIJQvwIEGqR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.53.252] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NmaY1-0000JZ-LC for netmod@ietf.org; Tue, 02 Mar 2010 17:26:37 -0500 Message-ID: <007701caba57$917ba100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100301160234.GA43607@elstar.local><201003020729.o227TABb092673@idle.juniper.net><20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> Date: Tue, 2 Mar 2010 14:27:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888494b88d665f13b4028a47b96b39593c7c6a1cb3cf06520f1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.53.252 Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 22:26:38 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Romascanu, Dan (Dan)" > Cc: > Sent: Tuesday, March 02, 2010 3:19 AM > Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt ... > Any other proposals? ... Explain how it helps (or does not) address issues raised in the IAB workshop oh-so-long-ago. Ones that come to mind at the moment include: - providing a systematic way of relating vendor-specific features to standardized models - supporting automation of the generation of vendor-specific configuration data from generic configuration requirements - supporting configuration of multi-system abstractions, like a trunk, where successful configuration requires delivery of configuration data to multiple devices - versioning of configuration data - separation of access control configuration data from configuration configuration data - pre-provisioning support - human-friendly configuration data representations - support for federation of administrative domains Randy From andyb@iwl.com Tue Mar 2 14:38: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 EF4683A8CE8 for ; Tue, 2 Mar 2010 14:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipd3gYOyfW9B for ; Tue, 2 Mar 2010 14:38:49 -0800 (PST) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id 4C04A3A8CD1 for ; Tue, 2 Mar 2010 14:38:49 -0800 (PST) Received: from relay19.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 28E231B5382; Tue, 2 Mar 2010 17:38:50 -0500 (EST) Received: by relay19.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DBA781B404D; Tue, 2 Mar 2010 17:38:49 -0500 (EST) Message-ID: <4B8D938A.3060309@iwl.com> Date: Tue, 02 Mar 2010 14:39:06 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Randy Presuhn References: <20100301160234.GA43607@elstar.local><201003020729.o227TABb092673@idle.juniper.net><20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> <007701caba57$917ba100$6801a8c0@oemcomputer> In-Reply-To: <007701caba57$917ba100$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 02 Mar 2010 22:38:51 -0000 Randy Presuhn wrote: > Hi - > >> From: "Juergen Schoenwaelder" >> To: "Romascanu, Dan (Dan)" >> Cc: >> Sent: Tuesday, March 02, 2010 3:19 AM >> Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt > ... >> Any other proposals? > ... > > Explain how it helps (or does not) address issues raised in the IAB > workshop oh-so-long-ago. Ones that come to mind at the moment > include: > > - providing a systematic way of relating vendor-specific features > to standardized models > - supporting automation of the generation of vendor-specific > configuration data from generic configuration requirements > - supporting configuration of multi-system abstractions, like a > trunk, where successful configuration requires delivery of > configuration data to multiple devices > - versioning of configuration data > - separation of access control configuration data from > configuration configuration data > - pre-provisioning support > - human-friendly configuration data representations > - support for federation of administrative domains > This is all very nice, but we went through all this when the arch document was chartered. IMO, Phil has done a great job with a very vague charter. The WG never chimed in with any input about clarifying the "inputs and outputs of YANG" charter scope. Each review cycle, there have been lots of comments about what is in scope for this document. Nobody is really sure. Maybe if we called it an Overview document instead of the over-loaded 'Architecture' term? The document is Informational, so no future standards track documents are going to be constrained by any normative reference to this document. I propose we take the path that gets this document done the fastest, without expanding the scope at the last minute. (I don't know what that is though :-) > Randy Andy From j.schoenwaelder@jacobs-university.de Tue Mar 2 23: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 758D93A7DD9 for ; Tue, 2 Mar 2010 23:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 L4-G7FwcyV7U for ; Tue, 2 Mar 2010 23:05:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5216128C14B for ; Tue, 2 Mar 2010 23:05:34 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDC7FC0011; Wed, 3 Mar 2010 08:05:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xE+Nz-19RM8w; Wed, 3 Mar 2010 08:05:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7950DC0008; Wed, 3 Mar 2010 08:05:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9D23010B03E8; Wed, 3 Mar 2010 08:05:17 +0100 (CET) Date: Wed, 3 Mar 2010 08:05:17 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100303070517.GA52728@elstar.local> Mail-Followup-To: Andy Bierman , Randy Presuhn , "netmod@ietf.org" References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> <007701caba57$917ba100$6801a8c0@oemcomputer> <4B8D938A.3060309@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B8D938A.3060309@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 03 Mar 2010 07:05:35 -0000 On Tue, Mar 02, 2010 at 11:39:06PM +0100, Andy Bierman wrote: > IMO, Phil has done a great job with a very vague charter. Nobody is criticizing Phil. It is the charter text which is not clear and we likely all remember how this document got on the charter. > The WG never chimed in with any input about clarifying the > "inputs and outputs of YANG" charter scope. Each review > cycle, there have been lots of comments about what is in > scope for this document. Nobody is really sure. Exactly. This is why I am trying to get us working towards a WG decision what this document's scope is going to be. The current list of things to choose from: 1) Overview of NETCONF and YANG, highlighting special features, explaining how they can be used in practice 2) Advise to NETCONF and YANG implementors (servers and apps) 3) Advise to YANG data model writers 4) Advise to the evolution of NETCONF and YANG 5) Overview how NETCONF/YANG fits into the collection of IETF (network management) protocols 6) Overview of how NETCONF/YANG fits into the XML landscape, explaining in particular its relationship to the existing schema and data modelling languages 7) Explain how it helps (or does not) address issues raised in the IAB workshop oh-so-long-ago > Maybe if we called it an Overview document instead of the > over-loaded 'Architecture' term? The document is Informational, > so no future standards track documents are going to be > constrained by any normative reference to this document. So you seem to vote for option 1) of the above. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Mar 3 02:27: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 C577E3A8D5E for ; Wed, 3 Mar 2010 02:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 xcLnqWgbs-nd for ; Wed, 3 Mar 2010 02:27:37 -0800 (PST) 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 F03653A7C20 for ; Wed, 3 Mar 2010 02:27:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,573,1262581200"; d="scan'208";a="207556565" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2010 05:27:37 -0500 X-IronPort-AV: E=Sophos;i="4.49,573,1262581200"; d="scan'208";a="451596563" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Mar 2010 05:27:37 -0500 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, 3 Mar 2010 11:27:27 +0100 Message-ID: In-Reply-To: <20100303070517.GA52728@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] js review of draft-ietf-netmod-arch-03.txt Thread-Index: Acq6n+6wiWKOnlCNSDSLWexVvaX9RQAG9Grw References: <20100301160234.GA43607@elstar.local><201003020729.o227TABb092673@idle.juniper.net><20100302084446.GA47604@elstar.local><20100302111945.GB48768@elstar.local><007701caba57$917ba100$6801a8c0@oemcomputer><4B8D938A.3060309@iwl.com> <20100303070517.GA52728@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Andy Bierman" Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 03 Mar 2010 10:27:37 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder >=20 > > Maybe if we called it an Overview document instead of the=20 > over-loaded=20 > > 'Architecture' term? The document is Informational, so no future=20 > > standards track documents are going to be constrained by=20 > any normative=20 > > reference to this document. >=20 > So you seem to vote for option 1) of the above. >=20 > /js >=20 This is fine and probably useful, but it does not meet the scope of the work as defined (not in the best words) in the charter.=20 Dan From andy@netconfcentral.com Wed Mar 3 04:34: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 B06743A889E for ; Wed, 3 Mar 2010 04:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 L3vn-0YCxu1H for ; Wed, 3 Mar 2010 04:34:56 -0800 (PST) Received: from smtp102.sbc.mail.gq1.yahoo.com (smtp102.sbc.mail.gq1.yahoo.com [67.195.15.61]) by core3.amsl.com (Postfix) with SMTP id DF9CA3A845C for ; Wed, 3 Mar 2010 04:34:56 -0800 (PST) Received: (qmail 23436 invoked from network); 3 Mar 2010 12:34:55 -0000 Received: from cpe-75-82-172-218.socal.res.rr.com (andy@75.82.172.218 with plain) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 03 Mar 2010 04:34:55 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: BMrDVH4VM1npR1jvvgkw237RPJ5rb2alAp2upCfCyQC2PqFLfRVxKmnFtPo22ZsGuAvclu5jHV8vWw_X1EbjrP.wx_hRnCNxkop5KcTgrc2OOniSmMbGYl.BlGMAagTgU_0kraa5k9r0AJW8dSp7jI_XDEYnN0FyOyPXczso0eQpoxZizWOcF_jti0Q_A2MXD2aNatYQZ9Zzrd5ZGFMQ_g_7wBCIlTM33QprZs2o0HZp7.Ab1C7qr6cIyt9FhxlV X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B8E5783.3010104@netconfcentral.com> Date: Wed, 03 Mar 2010 04:35:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Bierman , Randy Presuhn , "netmod@ietf.org" References: <20100301160234.GA43607@elstar.local> <201003020729.o227TABb092673@idle.juniper.net> <20100302084446.GA47604@elstar.local> <20100302111945.GB48768@elstar.local> <007701caba57$917ba100$6801a8c0@oemcomputer> <4B8D938A.3060309@iwl.com> <20100303070517.GA52728@elstar.local> In-Reply-To: <20100303070517.GA52728@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Mar 2010 04:52:32 -0800 Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 03 Mar 2010 12:34:57 -0000 Juergen Schoenwaelder wrote: > On Tue, Mar 02, 2010 at 11:39:06PM +0100, Andy Bierman wrote: > >> IMO, Phil has done a great job with a very vague charter. > > Nobody is criticizing Phil. It is the charter text which is not clear > and we likely all remember how this document got on the charter. > >> The WG never chimed in with any input about clarifying the >> "inputs and outputs of YANG" charter scope. Each review >> cycle, there have been lots of comments about what is in >> scope for this document. Nobody is really sure. > > Exactly. This is why I am trying to get us working towards a WG > decision what this document's scope is going to be. The current list > of things to choose from: > > 1) Overview of NETCONF and YANG, highlighting special features, > explaining how they can be used in practice > > 2) Advise to NETCONF and YANG implementors (servers and apps) > > 3) Advise to YANG data model writers > > 4) Advise to the evolution of NETCONF and YANG > > 5) Overview how NETCONF/YANG fits into the collection of IETF (network > management) protocols > > 6) Overview of how NETCONF/YANG fits into the XML landscape, > explaining in particular its relationship to the existing > schema and data modelling languages > > 7) Explain how it helps (or does not) address issues raised in > the IAB workshop oh-so-long-ago > >> Maybe if we called it an Overview document instead of the >> over-loaded 'Architecture' term? The document is Informational, >> so no future standards track documents are going to be >> constrained by any normative reference to this document. > > So you seem to vote for option 1) of the above. I don't want to change the charter. I never agreed with it in the first place. One could address many 'architectural' aspects of YANG: 1) Why doesn't YANG need to address NETCONF protocol capabilities? 2) Why doesn't YANG need any conformance mechanisms like SMIv2? (I have found the lack of a read-only conformance mechanism to be a serious lack of functionality.) 3) Why doesn't SMIv2 have an Architecture document, explaining the ins and outs of the language? Why does SNMP have a protocol architecture document instead? 4) YANG allows every vendor to add its own language statements. Why isn't the IETF concerned that there will be so many different variants of YANG in use that interoperability will be harmed? What level of readability and multi-vendor interoperability does the IETF even expect from YANG? 5) YANG is theoretically applicable to other protocols beyond NETCONF, yet the language is not written in a way that explains or even suggests that it could apply to another protocol. How does this claim in the charter impact future revisions of the YANG language? Will there ever be an attempt to make this 1 language apply to more than 1 protocol? > > /js > Andy From andyb@iwl.com Wed Mar 3 10:23:51 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 4DF7E28C1E0 for ; Wed, 3 Mar 2010 10:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcU9bioaW6Dg for ; Wed, 3 Mar 2010 10:23:48 -0800 (PST) Received: from smtp145.iad.emailsrvr.com (smtp145.iad.emailsrvr.com [207.97.245.145]) by core3.amsl.com (Postfix) with ESMTP id 2DBCA28C193 for ; Wed, 3 Mar 2010 10:23:47 -0800 (PST) Received: from relay4.r5.iad.mlsrvr.com (localhost [127.0.0.1]) by relay4.r5.iad.mlsrvr.com (SMTP Server) with ESMTP id B6D63CB59; Wed, 3 Mar 2010 13:23:46 -0500 (EST) Received: by relay4.r5.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 76674CA87; Wed, 3 Mar 2010 13:23:46 -0500 (EST) Message-ID: <4B8EA947.4000000@iwl.com> Date: Wed, 03 Mar 2010 10:24:07 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <201003020718.o227Itpj092581@idle.juniper.net> In-Reply-To: <201003020718.o227Itpj092581@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 03 Mar 2010 18:23:51 -0000 Phil Shafer wrote: > Andy Bierman writes: >> I don't think this document needs to talk about server implementation >> details, and refer to undefined transformations that the application >> developer may be able to use. > > This section tries to illustrate how YANG and NETCONF are able to > help the development of new standards while handling devices that > do not support those standards. IMHO this is an important feature, > but I will happily remove it if that is the WG concensus. > I understand your motivation. I happen to think the traditional IETF approach of defining the exact database contents that every server must support is just one tool in the box. It has never really worked in the IETF so insisting it is the only path to operational interoperability seems doomed to failure. In addition, there has always been an expectation that vendor data models will co-exist with standard data models. Usually the vendor data model is done first, and the standard followed years later. This process works OK for monitoring, but it is seriously flawed for configuration. These 'data model transformations' may end up being a viable standard mechanism for client applications to use. But now, they are just an undefined vendor-specific thing. I think this document should explain the role of vendor data models, vendor extensions to standard data models, and vendor deviations to standard data models. The text about transformations may be fine in a section like that. > Thanks, > Phil > Andy From cfinss@dial.pipex.com Thu Mar 4 10:24:23 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 A25A928C0EF for ; Thu, 4 Mar 2010 10:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZDLReCQYzOU for ; Thu, 4 Mar 2010 10:24:16 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 6D7EA3A8E1B for ; Thu, 4 Mar 2010 10:23:55 -0800 (PST) X-Trace: 188172541/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.210/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.210 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcGAFOJj0s+vGnS/2dsb2JhbACBeoVYiQ6LT7hPDYRvBA X-IronPort-AV: E=Sophos;i="4.49,582,1262563200"; d="scan'208";a="188172541" X-IP-Direction: IN Received: from 1cust210.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.210]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Mar 2010 18:23:27 +0000 Message-ID: <005901cabbbf$3df08140$0601a8c0@allison> From: "tom.petch" To: "David Partain" , References: <201002252341.02515.david.partain@ericsson.com> Date: Thu, 4 Mar 2010 16:54:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [netmod] FYI - YANG and YANG Common Types in the datatracker X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 18:24:23 -0000 David A recent post said that the write-up of yang was about to start. I have been quiet on this list lately, and although my focus has been on other things, there is also an element of giving up, because, while much is right in yang, I think that there are also fundamental errors. This is nothing new, just a reflection on the discussions that started mid-2008 when some of Andy's pointed questions elicited replies that made me realise that what the I-D 'clearly' said was not what it meant. I think that 'data cycle' is the phrase I would use, what exists where and when. As the archives show, not many people participated in this discussion, and I saw no clear consensus, but consensus was declared and looking back, that more or less coincides with the start of my quiet period. Again, as the archives show, when I was able to keep up (which wasn't as often as I would have liked), I was agreeing with Andy and Lada, although over time, I think that Andy changed his mind more than I did. I do see yang as a wasted opportunity, when the WG has come to the wrong answer, and has done so with - perhaps because of - too few participants. Sometimes IETF Last Call is a chance to test out this hypothesis but not, I think, this time; the scope is too vast, the killer details too well hidden. (Perhaps a document about the architecture of yang would make this clearer:-) So I will read the write-up with interest. My own perception of those 18 months of discusssions was that there were too few people involved, too few with experience of data models. I am not saying that I will raise again issues where consensus has been declared, although if we had a Data Model Directorate I would want to see them reviewing it and if questions do arise during LC, I might chip in with explanatory text. Tom Petch ----- Original Message ----- From: "David Partain" To: Sent: Thursday, February 25, 2010 11:41 PM Subject: [netmod] FYI - YANG and YANG Common Types in the datatracker > Hi, > > For those interested, our first two documents are in the tracker: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang/ > > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-types/ > > Cheers, > > David^2 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andyb@iwl.com Thu Mar 4 11: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 17FF228C0E2 for ; Thu, 4 Mar 2010 11:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 WwuebVzxo0hl for ; Thu, 4 Mar 2010 11:09:13 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 283A228C0DE for ; Thu, 4 Mar 2010 11:09:13 -0800 (PST) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id DC9A318005D; Thu, 4 Mar 2010 14:09:14 -0500 (EST) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8D18817FFAD; Thu, 4 Mar 2010 14:09:14 -0500 (EST) Message-ID: <4B900559.8040106@iwl.com> Date: Thu, 04 Mar 2010 11:09:13 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "tom.petch" References: <201002252341.02515.david.partain@ericsson.com> <005901cabbbf$3df08140$0601a8c0@allison> In-Reply-To: <005901cabbbf$3df08140$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] FYI - YANG and YANG Common Types in the datatracker 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, 04 Mar 2010 19:09:14 -0000 Hi Tom, > David > This is kind of a content-free complaint about YANG. What exactly was not fixed in mid-2008 that concerns you? Nobody thinks YANG is perfect. I think it is plenty good enough to be a Proposed Standard. There are companies shipping YANG, not just implementing it. I don't agree that this WG lacks the expertise for the problem space it is addressing. The archive shows that there has been a lot of participation, probably above IETF averages. Andy > A recent post said that the write-up of yang was about to start. > > I have been quiet on this list lately, and although my focus has been on other > things, there is also an element of giving up, because, while much is right in > yang, I > think that there are also fundamental errors. This is nothing new, just a > reflection on the discussions that started mid-2008 when some of Andy's pointed > questions elicited replies that made me realise that what the I-D 'clearly' said > was not what it meant. I think that 'data cycle' is the phrase I would use, > what exists > where and when. > > As the archives show, not many people participated in this discussion, and I saw > no clear consensus, but consensus was declared and looking back, that more > or less coincides with the start of my quiet period. Again, as the archives > show, when I was able to keep up (which wasn't as often as I would have liked), > I > was agreeing with Andy and Lada, although over time, I think that Andy changed > his mind more than I did. > > I do see yang as a wasted opportunity, when the WG has come to the wrong answer, > and has done so with - perhaps because of - too few participants. Sometimes > IETF Last Call is a chance to test out this hypothesis but not, I think, this > time; the scope is too vast, the killer details too well hidden. (Perhaps a > document about the architecture of yang would make this clearer:-) > > So I will read the write-up with interest. My own perception of those 18 months > of discusssions was that there were too few people involved, too few with > experience of data models. > > I am not saying that I will raise again issues where consensus has been > declared, > although if we had a Data Model Directorate I would want to see them reviewing > it and if questions do arise during LC, I might chip in with explanatory text. > > Tom Petch > > ----- Original Message ----- > From: "David Partain" > To: > Sent: Thursday, February 25, 2010 11:41 PM > Subject: [netmod] FYI - YANG and YANG Common Types in the datatracker > > >> Hi, >> >> For those interested, our first two documents are in the tracker: >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang/ >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-types/ >> >> Cheers, >> >> David^2 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@cesnet.cz Fri Mar 5 01:03: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 1EF3128C1CC for ; Fri, 5 Mar 2010 01:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oXM5DmCTe2fA for ; Fri, 5 Mar 2010 01:03:20 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id D04B73A8F2E for ; Fri, 5 Mar 2010 01:03:19 -0800 (PST) Received: from [192.168.100.104] (eduroam.cag.cz [195.113.220.184]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0625D2CDE05D for ; Fri, 5 Mar 2010 10:03:21 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group In-Reply-To: <4B900559.8040106@iwl.com> References: <201002252341.02515.david.partain@ericsson.com> <005901cabbbf$3df08140$0601a8c0@allison> <4B900559.8040106@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 05 Mar 2010 10:03:20 +0100 Message-ID: <1267779800.1847.10.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] FYI - YANG and YANG Common Types in the datatracker 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, 05 Mar 2010 09:03:21 -0000 Andy Bierman píše v Čt 04. 03. 2010 v 11:09 -0800: > Hi Tom, > > > David > > > > This is kind of a content-free complaint about YANG. > What exactly was not fixed in mid-2008 that concerns you? > > Nobody thinks YANG is perfect. I think it is plenty good > enough to be a Proposed Standard. There are companies > shipping YANG, not just implementing it. > > I don't agree that this WG lacks the expertise for > the problem space it is addressing. The archive shows that > there has been a lot of participation, probably above IETF averages. I essentially agree with Andy. True, YANG is not perfect and some of its features are maybe too powerful (and hence dangerous), but I am now convinced it is a useful formalism for the given problem space. Personally, the fact than it is still possible to map YANG data models quite closely to DSDL gives me some confidence that we haven't moved too far from the safe territory yet. Lada > > > Andy > > > > A recent post said that the write-up of yang was about to start. > > > > I have been quiet on this list lately, and although my focus has been on other > > things, there is also an element of giving up, because, while much is right in > > yang, I > > think that there are also fundamental errors. This is nothing new, just a > > reflection on the discussions that started mid-2008 when some of Andy's pointed > > questions elicited replies that made me realise that what the I-D 'clearly' said > > was not what it meant. I think that 'data cycle' is the phrase I would use, > > what exists > > where and when. > > > > As the archives show, not many people participated in this discussion, and I saw > > no clear consensus, but consensus was declared and looking back, that more > > or less coincides with the start of my quiet period. Again, as the archives > > show, when I was able to keep up (which wasn't as often as I would have liked), > > I > > was agreeing with Andy and Lada, although over time, I think that Andy changed > > his mind more than I did. > > > > I do see yang as a wasted opportunity, when the WG has come to the wrong answer, > > and has done so with - perhaps because of - too few participants. Sometimes > > IETF Last Call is a chance to test out this hypothesis but not, I think, this > > time; the scope is too vast, the killer details too well hidden. (Perhaps a > > document about the architecture of yang would make this clearer:-) > > > > So I will read the write-up with interest. My own perception of those 18 months > > of discusssions was that there were too few people involved, too few with > > experience of data models. > > > > I am not saying that I will raise again issues where consensus has been > > declared, > > although if we had a Data Model Directorate I would want to see them reviewing > > it and if questions do arise during LC, I might chip in with explanatory text. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "David Partain" > > To: > > Sent: Thursday, February 25, 2010 11:41 PM > > Subject: [netmod] FYI - YANG and YANG Common Types in the datatracker > > > > > >> Hi, > >> > >> For those interested, our first two documents are in the tracker: > >> > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang/ > >> > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-types/ > >> > >> Cheers, > >> > >> David^2 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Fri Mar 5 07:18: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 BE7EE28C14C for ; Fri, 5 Mar 2010 07:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEALXkT4mZmf for ; Fri, 5 Mar 2010 07:18:56 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B79C628C11A for ; Fri, 5 Mar 2010 07:18:55 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS5Eg2uHT/K/wz3dipepaTsfMoaLRBroN@postini.com; Fri, 05 Mar 2010 07:18:58 PST 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.1.393.1; Fri, 5 Mar 2010 07:15:05 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 07:15:04 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 07:15:04 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 07:15:04 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o25FF3D56626; Fri, 5 Mar 2010 07:15:03 -0800 (PST) (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 o25Ews0r019852; Fri, 5 Mar 2010 14:58:55 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003051458.o25Ews0r019852@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: Date: Fri, 5 Mar 2010 09:58:54 -0500 From: Phil Shafer X-OriginalArrivalTime: 05 Mar 2010 15:15:04.0440 (UTC) FILETIME=[A20CEF80:01CABC76] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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: Fri, 05 Mar 2010 15:18:58 -0000 "Romascanu, Dan (Dan)" writes: >This is fine and probably useful, but it does not meet the scope of the >work as defined (not in the best words) in the charter. My feeling is that the following need to be addressed in the arch draft: (a) why we did it // the problem domain (b) what we did // how the moving parts work (c) how you use it // what a yang-based solution looks like (d) real world issues // minor bits that need to be written down The official scope might only cover (b) but without saying what we aimed for (a) and how to use it (c), we can't call it "architecture". The (d) section may not be pretty but this material needs to be written down somewhere. Jeurgen's text on data is an example of (d). Large sections of the original (a) and (c) were removed, and this has made the document less readable. I would like to attempt to rebuild these section with less objectionable content instead of simply removing them. IMHO they are needed. Unless there are objections, I'll make another attempt. Thanks, Phil From dromasca@avaya.com Sun Mar 7 02:26: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 053AA3A8F32 for ; Sun, 7 Mar 2010 02:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 nd5-K618ffMj for ; Sun, 7 Mar 2010 02:26:19 -0800 (PST) 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 10C2F28C0CE for ; Sun, 7 Mar 2010 02:26:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,597,1262581200"; d="scan'208";a="208122387" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Mar 2010 05:26:22 -0500 X-IronPort-AV: E=Sophos;i="4.49,597,1262581200"; d="scan'208";a="452973835" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Mar 2010 05:26:21 -0500 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: Sun, 7 Mar 2010 11:25:59 +0100 Message-ID: In-Reply-To: <201003051458.o25Ews0r019852@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] js review of draft-ietf-netmod-arch-03.txt Thread-Index: Acq8dy5LUBZmzW4hSYmtK+zkVc1qqABaRRCg References: <201003051458.o25Ews0r019852@idle.juniper.net> From: "Romascanu, Dan (Dan)" To: "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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: Sun, 07 Mar 2010 10:26:20 -0000 > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net]=20 > Sent: Friday, March 05, 2010 4:59 PM > To: Romascanu, Dan (Dan) > Cc: Juergen Schoenwaelder; Andy Bierman; netmod@ietf.org > Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.txt=20 >=20 > "Romascanu, Dan (Dan)" writes: > >This is fine and probably useful, but it does not meet the=20 > scope of the=20 > >work as defined (not in the best words) in the charter. >=20 > My feeling is that the following need to be addressed in the=20 > arch draft: >=20 > (a) why we did it // the problem domain > (b) what we did // how the moving parts work > (c) how you use it // what a yang-based solution looks like > (d) real world issues // minor bits that need to be written down >=20 > The official scope might only cover (b) but without saying=20 > what we aimed for (a) and how to use it (c), we can't call it=20 > "architecture". >=20 > The (d) section may not be pretty but this material needs to=20 > be written down somewhere. Jeurgen's text on data is an=20 > example of (d). >=20 > Large sections of the original (a) and (c) were removed, and=20 > this has made the document less readable. I would like to=20 > attempt to rebuild these section with less objectionable=20 > content instead of simply removing them. IMHO they are needed. >=20 > Unless there are objections, I'll make another attempt. >=20 > Thanks, > Phil >=20 Ok with me, as long as the goals we had in mind when we started this work are covered.=20 Dan From david.partain@ericsson.com Mon Mar 8 00:50:17 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 14B213A6784 for ; Mon, 8 Mar 2010 00:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 P8gYOplxeWBF for ; Mon, 8 Mar 2010 00:50:11 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7FB473A63EB for ; Mon, 8 Mar 2010 00:50:11 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-e3-4b94ba466c12 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C3.47.01038.64AB49B4; Mon, 8 Mar 2010 09:50:14 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:50:12 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:50:13 +0100 Content-Language: en-US From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Mon, 8 Mar 2010 09:50:11 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003080950.11921.david.partain@ericsson.com> X-OriginalArrivalTime: 08 Mar 2010 08:50:13.0137 (UTC) FILETIME=[5DCCF810:01CABE9C] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: Guidelines for Authors and Reviewers of YANG Data Model Documents 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, 08 Mar 2010 08:50:17 -0000 Greetings, This is a 14-day working group last call on the current working group document: - Guidelines for Authors and Reviewers of YANG Data Model Documents http://www.ietf.org/draft-ietf-netmod-yang-usage-03.txt This WGLC will end on March 22, 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. Thanks. David^2 From tmikolajczyk@goahead.com Mon Mar 8 00:53:17 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 395D03A6784 for ; Mon, 8 Mar 2010 00:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMB9VMP31oMV for ; Mon, 8 Mar 2010 00:53:16 -0800 (PST) Received: from west.smtp.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by core3.amsl.com (Postfix) with ESMTP id 925933A63EB for ; Mon, 8 Mar 2010 00:53:16 -0800 (PST) Received: from [192.168.85.99] (78.8.254.195) by west.exch021.serverdata.net (10.254.4.40) with Microsoft SMTP Server (TLS) id 14.0.682.2; Mon, 8 Mar 2010 00:53:19 -0800 Message-ID: <4B94BB38.90605@goahead.com> Date: Mon, 8 Mar 2010 09:54:16 +0100 From: Tomasz Mikolajczyk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: David Partain References: <201003080950.11921.david.partain@ericsson.com> In-Reply-To: <201003080950.11921.david.partain@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Guidelines for Authors and Reviewers of YANG Data Model Documents 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, 08 Mar 2010 08:53:17 -0000 Hi, Seems that the link doesn't work. Regards, Tomasz Mikolajczyk On 03/08/2010 09:50 AM, David Partain wrote: > Greetings, > > This is a 14-day working group last call on the current working group > document: > > - Guidelines for Authors and Reviewers of YANG Data Model Documents > http://www.ietf.org/draft-ietf-netmod-yang-usage-03.txt > > This WGLC will end on March 22, 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. > > Thanks. > > David^2 From david.partain@ericsson.com Mon Mar 8 01:09: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 ABFB13A67A5 for ; Mon, 8 Mar 2010 01:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 XeAZ1zn3ckQd for ; Mon, 8 Mar 2010 01:09:11 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2157E3A67B1 for ; Mon, 8 Mar 2010 01:09:10 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-42-4b94beb9b6e5 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C5.E2.31641.9BEB49B4; Mon, 8 Mar 2010 10:09:13 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 10:09:13 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 10:09:13 +0100 From: David Partain Organization: Ericsson AB To: Tomasz Mikolajczyk Date: Mon, 8 Mar 2010 10:09:12 +0100 User-Agent: KMail/1.9.10 References: <201003080950.11921.david.partain@ericsson.com> <4B94BB38.90605@goahead.com> In-Reply-To: <4B94BB38.90605@goahead.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003081009.12820.david.partain@ericsson.com> X-OriginalArrivalTime: 08 Mar 2010 09:09:13.0119 (UTC) FILETIME=[05486AF0:01CABE9F] X-Brightmail-Tracker: AAAAAA== Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: Guidelines for Authors and Reviewers of YANG Data Model Documents 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, 08 Mar 2010 09:09:12 -0000 Greetings, My fault, sorry. Cut & paste silliness. The correct link is of course: http://www.ietf.org/id/draft-ietf-netmod-yang-usage-03.txt Cheers, David On Monday 08 March 2010 09.54.16 Tomasz Mikolajczyk wrote: > Hi, > > Seems that the link doesn't work. > > Regards, > Tomasz Mikolajczyk > > On 03/08/2010 09:50 AM, David Partain wrote: > > Greetings, > > > > This is a 14-day working group last call on the current working group > > document: > > > > - Guidelines for Authors and Reviewers of YANG Data Model Documents > > http://www.ietf.org/draft-ietf-netmod-yang-usage-03.txt > > > > This WGLC will end on March 22, 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. > > > > Thanks. > > > > David^2 From phil@juniper.net Mon Mar 8 15:21:17 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 C02FA3A6A5A for ; Mon, 8 Mar 2010 15:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWBQsPLXrI04 for ; Mon, 8 Mar 2010 15:21:16 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 264E83A6A20 for ; Mon, 8 Mar 2010 15:21:11 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS5WGadnUxQl7H9qxxLgqh39gBFXZEQal@postini.com; Mon, 08 Mar 2010 15:21:15 PST 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.1.393.1; Mon, 8 Mar 2010 15:17:05 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 15:17:05 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 15:17:04 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 15:17:04 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o28NH3D61248; Mon, 8 Mar 2010 15:17:03 -0800 (PST) (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 o28N0r1F057967; Mon, 8 Mar 2010 23:00:53 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003082300.o28N0r1F057967@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: <201003051458.o25Ews0r019852@idle.juniper.net> Date: Mon, 8 Mar 2010 18:00:53 -0500 From: Phil Shafer X-OriginalArrivalTime: 08 Mar 2010 23:17:04.0412 (UTC) FILETIME=[76EFB5C0:01CABF15] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 08 Mar 2010 23:21:17 -0000 Phil Shafer writes: >Unless there are objections, I'll make another attempt. >Filename: draft-ietf-netmod-arch >Revision: 04 >Title: An NETCONF- and NETMOD-based Architecture for Network Management >Creation_date: 2010-03-08 >WG ID: netmod >Number_of_pages: 27 Please read and give feedback. Thanks, Phil From root@core3.amsl.com Mon Mar 8 15:30: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 B36F83A6767; Mon, 8 Mar 2010 15:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308233001.B36F83A6767@core3.amsl.com> Date: Mon, 8 Mar 2010 15:30:01 -0800 (PST) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-04.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, 08 Mar 2010 23:30: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 : An NETCONF- and NETMOD-based Architecture for Network Management Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-04.txt Pages : 27 Date : 2010-03-08 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08151513.I-D@ietf.org> --NextPart-- From andyb@iwl.com Mon Mar 8 16:14: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 A46F33A6A8F for ; Mon, 8 Mar 2010 16:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 T37xzhH98hBe for ; Mon, 8 Mar 2010 16:14:30 -0800 (PST) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 079783A677E for ; Mon, 8 Mar 2010 16:14:30 -0800 (PST) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 89A8817FE89; Mon, 8 Mar 2010 19:14:33 -0500 (EST) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1A00B17FC09; Mon, 8 Mar 2010 19:14:30 -0500 (EST) Message-ID: <4B9592E3.60509@iwl.com> Date: Mon, 08 Mar 2010 16:14:27 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <201003082300.o28N0r1F057967@idle.juniper.net> In-Reply-To: <201003082300.o28N0r1F057967@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-ietf-netmod-arch-03.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, 09 Mar 2010 00:14:30 -0000 Phil Shafer wrote: > Phil Shafer writes: >> Unless there are objections, I'll make another attempt. > >> Filename: draft-ietf-netmod-arch >> Revision: 04 >> Title: An NETCONF- and NETMOD-based Architecture for Network Management >> Creation_date: 2010-03-08 >> WG ID: netmod >> Number_of_pages: 27 > > Please read and give feedback. > I really like it! That assumes I am allowed to just read the document without any preconceived ideas about what an ARCH spec contains. The empty security considerations section is probably not going to make the IESG happy. (We'll see) > Thanks, > Phil Andy From dromasca@avaya.com Wed Mar 10 02:00: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 6B4F23A67CF; Wed, 10 Mar 2010 02:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 w7E65A2C3mS1; Wed, 10 Mar 2010 02:00:03 -0800 (PST) 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 4F5723A67A5; Wed, 10 Mar 2010 02:00:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,613,1262581200"; d="scan'208";a="208598590" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Mar 2010 05:00:07 -0500 X-IronPort-AV: E=Sophos;i="4.49,613,1262581200"; d="scan'208";a="440346053" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Mar 2010 05:00:06 -0500 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, 10 Mar 2010 10:59:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Considerations sections of YANG modules documents Thread-Index: AcrAOG6dwWRSMRw/S3WbXSldD8d9Rw== From: "Romascanu, Dan (Dan)" To: , Subject: [netmod] Security Considerations sections of YANG modules documents 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, 10 Mar 2010 10:00:04 -0000 While reading draft-ietf-netconf-monitoring-12.txt in preparation for the AD review I observed that the Security Considerations section is pretty 'thin', containing much less that can be found in the similar sections of documents that include MIB modules. The security experts will almost certainly consider that important information is missing and the document will not pass the SEC-DIR and Security AD reviews. This being the first document with a YANG module in the normative section, it will also set kind of a model to be followed by other. I suggest that we prepare a set of guidelines similar to the ones we have for MIB documents at http://www.ops.ietf.org/mib-security.html and we run them with the Security Directorate and AD's.=20 Comments? Volunteers?=20 Dan From david.partain@ericsson.com Wed Mar 10 04:05:18 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 0D37D3A6887 for ; Wed, 10 Mar 2010 04:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 X5bDJqWAUAHO for ; Wed, 10 Mar 2010 04:05:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 00D013A6826 for ; Wed, 10 Mar 2010 04:05:16 -0800 (PST) X-AuditID: c1b4fb3d-b7bf6ae000005bec-93-4b978b007b6d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 1C.A4.23532.00B879B4; Wed, 10 Mar 2010 13:05:20 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 13:05:19 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 13:05:19 +0100 From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Wed, 10 Mar 2010 13:05:18 +0100 User-Agent: KMail/1.9.10 References: <201002281659.24506.david.partain@ericsson.com> In-Reply-To: <201002281659.24506.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003101305.19003.david.partain@ericsson.com> X-OriginalArrivalTime: 10 Mar 2010 12:05:19.0354 (UTC) FILETIME=[F4136DA0:01CAC049] X-Brightmail-Tracker: AAAAAA== Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 10 Mar 2010 12:05:18 -0000 On Sunday 28 February 2010 16.59.24 David Partain wrote: > Dear all, > > This is a 10-day working group last call on the current working group > document: > > - An NETCONF- and NETMOD-based Architecture for Network Management > http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-03.txt > > This WGLC will end on March 10, 2010. Please review the document and post > your comments on the mailing list. Hi, The Last Call ends today. Please get your comments in, even if it's just to say "I've read it and it's fine". Cheers, David From j.schoenwaelder@jacobs-university.de Wed Mar 10 04:22: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 CAA193A6838 for ; Wed, 10 Mar 2010 04:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 EcKSJimeBEcV for ; Wed, 10 Mar 2010 04:22:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6130E3A68BD for ; Wed, 10 Mar 2010 04:21:49 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 147C7C0007; Wed, 10 Mar 2010 13:21:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IZGymjwAVOCn; Wed, 10 Mar 2010 13:21:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7158C0002; Wed, 10 Mar 2010 13:21:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 121E810C788D; Wed, 10 Mar 2010 13:21:51 +0100 (CET) Date: Wed, 10 Mar 2010 13:21:51 +0100 From: Juergen Schoenwaelder To: David Partain Message-ID: <20100310122150.GA9134@elstar.local> Mail-Followup-To: David Partain , "netmod@ietf.org" References: <201002281659.24506.david.partain@ericsson.com> <201003101305.19003.david.partain@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003101305.19003.david.partain@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 10 Mar 2010 12:22:07 -0000 On Wed, Mar 10, 2010 at 01:05:18PM +0100, David Partain wrote: > On Sunday 28 February 2010 16.59.24 David Partain wrote: > > Dear all, > > > > This is a 10-day working group last call on the current working group > > document: > > > > - An NETCONF- and NETMOD-based Architecture for Network Management > > http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-03.txt > > > > This WGLC will end on March 10, 2010. Please review the document and post > > your comments on the mailing list. > > Hi, > > The Last Call ends today. Please get your comments in, even if it's > just to say "I've read it and it's fine". I assume there is going to be another LC since we already have a new version in place - or how do you plan to deal with that? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Mar 10 11:33:25 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 A2D763A68F6 for ; Wed, 10 Mar 2010 11:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcutxjuNO0k9 for ; Wed, 10 Mar 2010 11:33:24 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id C79BC3A692B for ; Wed, 10 Mar 2010 11:33:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS5f0B9NbI1WgQBwaVlBKiYpT0sYTmueK@postini.com; Wed, 10 Mar 2010 11:33:28 PST 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.1.393.1; Wed, 10 Mar 2010 11:31:46 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 11:31:45 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 11:31:45 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 11:31:45 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o2AJViD65080 for ; Wed, 10 Mar 2010 11:31:44 -0800 (PST) (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 o2AJFWRt074138 for ; Wed, 10 Mar 2010 19:15:32 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003101915.o2AJFWRt074138@idle.juniper.net> To: Date: Wed, 10 Mar 2010 14:15:32 -0500 From: Phil Shafer X-OriginalArrivalTime: 10 Mar 2010 19:31:45.0301 (UTC) FILETIME=[51BE9450:01CAC088] MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] defaults 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, 10 Mar 2010 19:33:25 -0000 Not that I want to touch the "third rail" of YANG, but... The YANG draft says: A NETCONF server that replies to a or request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an for a or request, MUST be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value. Do we expect new RPCs to have this same behavior WRT defaults? I would expect this is what we want. So should we s/ or //? This should also be the behavior for notifications. Thanks, Phil From mbj@tail-f.com Wed Mar 10 11:40:51 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 01AD43A68F1 for ; Wed, 10 Mar 2010 11:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[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 aqx2V6sd4CVD for ; Wed, 10 Mar 2010 11:40:50 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 232EE3A683D for ; Wed, 10 Mar 2010 11:40:50 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2EF06616007; Wed, 10 Mar 2010 20:40:54 +0100 (CET) Date: Wed, 10 Mar 2010 20:40:53 +0100 (CET) Message-Id: <20100310.204053.99272869.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201003101915.o2AJFWRt074138@idle.juniper.net> References: <201003101915.o2AJFWRt074138@idle.juniper.net> X-Mailer: Mew version 6.2.51 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] defaults 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, 10 Mar 2010 19:40:51 -0000 Phil Shafer wrote: > Not that I want to touch the "third rail" of YANG, but... > > The YANG draft says: > > A NETCONF server that replies to a or request MAY > choose not to send the leaf element if its value is the default > value. Thus, a client that receives an for a or > request, MUST be prepared to handle the case that a leaf > node with a default value is not present in the XML. In this case, > the value used by the server is known to be the default value. > > Do we expect new RPCs to have this same behavior WRT defaults? I > would expect this is what we want. > > So should we s/ or //? > > This should also be the behavior for notifications. It also says, in the text on notification (same for rpc output): If a leaf in the notification tree has a default value, the NETCONF client MUST use this value in the same cases as described in ^leaf-default-value^. In these cases, the client MUST operationally behave as if the leaf was present in the NETCONF notification with the default value as its value. So I think it is covered. /martin From wwwrun@core3.amsl.com Wed Mar 10 11:34:39 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 107403A6926; Wed, 10 Mar 2010 11:34:38 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100310193439.107403A6926@core3.amsl.com> Date: Wed, 10 Mar 2010 11:34:39 -0800 (PST) X-Mailman-Approved-At: Wed, 10 Mar 2010 11:42:21 -0800 Cc: netmod@ietf.org Subject: [netmod] Last Call: draft-ietf-netmod-yang (YANG - A data modeling language for NETCONF) to Proposed Standard 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: Wed, 10 Mar 2010 19:34:39 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'YANG - A data modeling language for NETCONF ' as a Proposed Standard 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-04-09. 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-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17247&rfc_flag=0 From wwwrun@core3.amsl.com Wed Mar 10 11:35:13 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 EAA1D3A6963; Wed, 10 Mar 2010 11:35:13 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100310193513.EAA1D3A6963@core3.amsl.com> Date: Wed, 10 Mar 2010 11:35:13 -0800 (PST) X-Mailman-Approved-At: Wed, 10 Mar 2010 11:42:21 -0800 Cc: netmod@ietf.org Subject: [netmod] Last Call: draft-ietf-netmod-yang-types (Common YANG Data Types) to Proposed Standard 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: Wed, 10 Mar 2010 19:35:14 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Common YANG Data Types ' as a Proposed Standard 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-04-09. 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-types-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17680&rfc_flag=0 From phil@juniper.net Wed Mar 10 12:04:09 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 261D03A6915 for ; Wed, 10 Mar 2010 12:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIU+T8543k-H for ; Wed, 10 Mar 2010 12:04:08 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 1D24D3A68E7 for ; Wed, 10 Mar 2010 12:04:08 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKS5f7PPhDQPs/mKk2a/ilCbhwXYkcc6Wj@postini.com; Wed, 10 Mar 2010 12:04:13 PST 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.1.393.1; Wed, 10 Mar 2010 12:01:44 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 12:01:43 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 12:01:43 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 12:01:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o2AK1gD80248 for ; Wed, 10 Mar 2010 12:01:42 -0800 (PST) (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 o2AJjUmb074378 for ; Wed, 10 Mar 2010 19:45:30 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003101945.o2AJjUmb074378@idle.juniper.net> To: Date: Wed, 10 Mar 2010 14:45:30 -0500 From: Phil Shafer X-OriginalArrivalTime: 10 Mar 2010 20:01:43.0575 (UTC) FILETIME=[81996A70:01CAC08C] MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] missing sections 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, 10 Mar 2010 20:04:09 -0000 There were two sections in the last arch draft that were missing. See the attached delta for the new text. Unfortunately I cannot post a new draft. Thanks, Phil ------ ** Modeler -(No clue what needs said here; lots to say, but what's important?) +The modeler's role constructing a model based on their in-depth +knowledge of the problem domain being modeled. This model should +be as simple as possible, but should balance complexity with +expressiveness. The organization of the model should target not only +the current model, but should allow for extensibility from other +modules and for adaptability to future changes. Additional modeling issues are discussed in ^modeling^. @@ -680,8 +684,50 @@ ** Default Values -(With all the discussion on this point, it needs to be mentioned here.) +The concept of default values is simple, but their details, +representation, and interaction with configuration data can be +difficult issues. NETCONF leaves default values as a data model +issue, and YANG gives flexibility to the device implementation in +terms of how default values are handled. The requirement is that the +device "MUST operationally behave as is if the leaf was present in the +data tree with the default value as its value". This gives the device +implementation choices in how default values are handled. +One choice is to view the configuration as a set of instructions for +how the device should be configured. If a data value is given as part +of those instructions is the default value, then it should be retained +as part of the configuration, but if it not explicitly given, then the +value is not considered to be part of configuration. + +Another choice is to trim values that are identical to the default +values, implicitly removing them from the configuration database. +The act of setting a leaf to it's default value effectively deletes +that leaf. + +The device could also choose to report all default values, regardless +of whether they were explicitly set. This choice eases the work of +a client that needs default values, but may significantly increase the +size of the configuration data. + +These choices reflect the default handling schemes of widely deployed +networking devices and supporting them allows YANG to reduce +implementation and deployment costs of YANG-based models. + +When the client retrieves data from the device, it must be prepared to +handle the absence of leaf nodes with the default value, since the +server is not required to send such leaf elements. This permits the +device to implement either of the first two default handling schemes +given above. + +Regardless of the implementation choice, the device can support the +"with-defaults" capability (^RFCWITHDEFAULTS^) and give the client the +ability to select the desired handling of default values. + +When evaluating the XPath expressions for constraints like "must" and +"when", the evaluation context for the expressions will include any +appropriate default values, so the modeler can depend on consistent +behavior from all devices. + From david.partain@ericsson.com Wed Mar 10 12:05:51 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 EF9BA3A69AE for ; Wed, 10 Mar 2010 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=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 HeD-x4O2WkSh for ; Wed, 10 Mar 2010 12:05:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F09B23A6982 for ; Wed, 10 Mar 2010 12:05:50 -0800 (PST) X-AuditID: c1b4fb39-b7b85ae000005cbc-7f-4b97fba207a6 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 55.23.23740.2ABF79B4; Wed, 10 Mar 2010 21:05:54 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 21:05:54 +0100 Received: from 153-88-16-79.rvi.sw.ericsson.se ([153.88.16.79]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 21:05:53 +0100 From: David Partain Organization: Ericsson AB To: Juergen Schoenwaelder Date: Wed, 10 Mar 2010 21:05:53 +0100 User-Agent: KMail/1.9.10 References: <201002281659.24506.david.partain@ericsson.com> <201003101305.19003.david.partain@ericsson.com> <20100310122150.GA9134@elstar.local> In-Reply-To: <20100310122150.GA9134@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003102105.53784.david.partain@ericsson.com> X-OriginalArrivalTime: 10 Mar 2010 20:05:53.0604 (UTC) FILETIME=[16A0D040:01CAC08D] X-Brightmail-Tracker: AAAAAA== Cc: "netmod@ietf.org" Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 10 Mar 2010 20:05:52 -0000 On Wednesday 10 March 2010 13.21.51 Juergen Schoenwaelder wrote: > On Wed, Mar 10, 2010 at 01:05:18PM +0100, David Partain wrote: > > On Sunday 28 February 2010 16.59.24 David Partain wrote: > > > Dear all, > > > > > > This is a 10-day working group last call on the current working group > > > document: > > > > > > - An NETCONF- and NETMOD-based Architecture for Network Management > > > http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-03.txt > > > > > > This WGLC will end on March 10, 2010. Please review the document and > > > post your comments on the mailing list. > > > > Hi, > > > > The Last Call ends today. Please get your comments in, even if it's > > just to say "I've read it and it's fine". > > I assume there is going to be another LC since we already have a new > version in place - or how do you plan to deal with that? Hi, Yes, I think we're going to have another. First we need to work out the issues that have all been raised, and Anaheim will be used for that (along with other issues that come up on the other last calls). I suspect that we'll have a draft post-IETF that will be WGLC'ed. Cheers, David From phil@juniper.net Wed Mar 10 12:08: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 7AA403A69D1 for ; Wed, 10 Mar 2010 12:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7rMx5iT-U+3 for ; Wed, 10 Mar 2010 12:08:00 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 683583A6963 for ; Wed, 10 Mar 2010 12:07:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS5f8HRC9WIIdyEA91dInbs1/UMIheIAU@postini.com; Wed, 10 Mar 2010 12:08:02 PST 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.1.393.1; Wed, 10 Mar 2010 12:06:26 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 12:06:25 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 12:06:26 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 12:06:25 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o2AK6OD82146; Wed, 10 Mar 2010 12:06:25 -0800 (PST) (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 o2AJoCKb074450; Wed, 10 Mar 2010 19:50:12 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003101950.o2AJoCKb074450@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100310.204053.99272869.mbj@tail-f.com> Date: Wed, 10 Mar 2010 14:50:12 -0500 From: Phil Shafer X-OriginalArrivalTime: 10 Mar 2010 20:06:25.0712 (UTC) FILETIME=[29C41B00:01CAC08D] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] defaults 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, 10 Mar 2010 20:08:01 -0000 Martin Bjorklund writes: >> A NETCONF server that replies to a or request MAY >> choose not to send the leaf element if its value is the default >> value. Thus, a client that receives an for a or >> request, MUST be prepared to handle the case that a leaf >> node with a default value is not present in the XML. In this case, >> the value used by the server is known to be the default value. >It also says, in the text on notification (same for rpc output): >So I think it is covered. Okay, but if the rules are relaxed elsewhere, why make the rule so specific in the first place? Would you object to having the real rule more fully described in ^leaf-default-value^? Thanks, Phil From andyb@iwl.com Wed Mar 10 13:00: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 47C7A3A6963 for ; Wed, 10 Mar 2010 13:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 qPk3zgljJsnO for ; Wed, 10 Mar 2010 13:00:25 -0800 (PST) Received: from smtp165.dfw.emailsrvr.com (smtp165.dfw.emailsrvr.com [67.192.241.165]) by core3.amsl.com (Postfix) with ESMTP id 90F773A68EE for ; Wed, 10 Mar 2010 13:00:25 -0800 (PST) Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 2C30130617; Wed, 10 Mar 2010 16:00:30 -0500 (EST) Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id AC35D2FFC5; Wed, 10 Mar 2010 16:00:29 -0500 (EST) Message-ID: <4B98085C.2050305@iwl.com> Date: Wed, 10 Mar 2010 13:00:12 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <201003101950.o2AJoCKb074450@idle.juniper.net> In-Reply-To: <201003101950.o2AJoCKb074450@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults 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, 10 Mar 2010 21:00:26 -0000 Phil Shafer wrote: > Martin Bjorklund writes: >>> A NETCONF server that replies to a or request MAY >>> choose not to send the leaf element if its value is the default >>> value. Thus, a client that receives an for a or >>> request, MUST be prepared to handle the case that a leaf >>> node with a default value is not present in the XML. In this case, >>> the value used by the server is known to be the default value. >> It also says, in the text on notification (same for rpc output): >> So I think it is covered. > > Okay, but if the rules are relaxed elsewhere, why make the rule > so specific in the first place? Would you object to having the > real rule more fully described in ^leaf-default-value^? > I changed the with-defaults draft to align with YANG. Please check the latest draft to see if I got it right. Are you suggesting that the defaults behavior of the server MAY affect other RPC operations? And we do not want to spin the YANG RFC later if we decide defaultst apply to more than the 3 specific operations mentioned? I think the with-defaults draft should say how specific NETCONF operations deal with defaults. The YANG draft should be more future-proof. (Sometimes just the addition of 'e.g.,' can be the difference. I don't think Lada ever got a clear answer to his original question about the nc:operation='create' or 'delete' for a default leaf. This needs to be the same on every server, no matter what notion of defaults the server uses. 1) Does a create operation on a YANG default leaf succeed or fail with a 'data-exists' error? 2) Does a delete operation succeed (and then the server creates the leaf again) or does it fail with a 'data-missing' error? 3) Is the 'explicit' notion of a default affect the create/delete operations at all? > Thanks, > Phil Andy From phil@juniper.net Wed Mar 10 14:26: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 3B17F3A6830 for ; Wed, 10 Mar 2010 14:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F9oX3OwteLo for ; Wed, 10 Mar 2010 14:26:37 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id C9FB93A69BD for ; Wed, 10 Mar 2010 14:26:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS5gclHWmY8avKkbKxzi22AGQC8DhXhmY@postini.com; Wed, 10 Mar 2010 14:26:42 PST 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.1.393.1; Wed, 10 Mar 2010 14:24:00 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 14:24:00 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 14:24:00 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 14:24:00 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o2AMNxD38532; Wed, 10 Mar 2010 14:23:59 -0800 (PST) (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 o2AM7krG075746; Wed, 10 Mar 2010 22:07:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003102207.o2AM7krG075746@idle.juniper.net> To: In-Reply-To: <4B98085C.2050305@iwl.com> Date: Wed, 10 Mar 2010 17:07:46 -0500 From: Phil Shafer X-OriginalArrivalTime: 10 Mar 2010 22:24:00.0354 (UTC) FILETIME=[61EA8420:01CAC0A0] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] defaults 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, 10 Mar 2010 22:26:38 -0000 Andy Bierman writes: >Are you suggesting that the defaults behavior of the server >MAY affect other RPC operations? Yes, it affect rpc input, output, and notifications. >I think the with-defaults draft should say how specific >NETCONF operations deal with defaults. with-defaults is not the place to address this, since it's optional. > 1) Does a create operation on a YANG default leaf succeed or fail > with a 'data-exists' error? succeed; otherwise success must be defined as (not(error) || error/tag == 'data-exists') > 2) Does a delete operation succeed (and then the server creates the > leaf again) or does it fail with a 'data-missing' error? fail; otherwise similar issue (where success is not trivial to discover) > 3) Is the 'explicit' notion of a default affect the create/delete > operations at all? yes. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Mar 10 23:10: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 EE1B83A67E1 for ; Wed, 10 Mar 2010 23:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 HvtOp5H0g2nX for ; Wed, 10 Mar 2010 23:10:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 429DF3A67D9 for ; Wed, 10 Mar 2010 23:10:35 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A006C000D; Thu, 11 Mar 2010 08:10:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3t+mg6u7x5ZI; Thu, 11 Mar 2010 08:10:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85547C0007; Thu, 11 Mar 2010 08:10:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C223D10C924C; Thu, 11 Mar 2010 08:10:36 +0100 (CET) Date: Thu, 11 Mar 2010 08:10:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100311071036.GA12246@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <201003101950.o2AJoCKb074450@idle.juniper.net> <4B98085C.2050305@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B98085C.2050305@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] defaults X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 07:10:38 -0000 On Wed, Mar 10, 2010 at 10:00:12PM +0100, Andy Bierman wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > >>> A NETCONF server that replies to a or request MAY > >>> choose not to send the leaf element if its value is the default > >>> value. Thus, a client that receives an for a or > >>> request, MUST be prepared to handle the case that a leaf > >>> node with a default value is not present in the XML. In this case, > >>> the value used by the server is known to be the default value. > >> It also says, in the text on notification (same for rpc output): > >> So I think it is covered. > I think the with-defaults draft should say how specific > NETCONF operations deal with defaults. The YANG draft should > be more future-proof. (Sometimes just the addition of 'e.g.,' > can be the difference. I like the e.g. solution, that is mention and as examples to future proof this definition. /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 Thu Mar 11 00:13: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 6EBAE3A6B72 for ; Thu, 11 Mar 2010 00:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_48=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 NINJHzl+qYb0 for ; Thu, 11 Mar 2010 00:13:37 -0800 (PST) Received: from smtp185.dfw.emailsrvr.com (smtp185.dfw.emailsrvr.com [67.192.241.185]) by core3.amsl.com (Postfix) with ESMTP id 982783A6916 for ; Thu, 11 Mar 2010 00:13:36 -0800 (PST) Received: from relay18.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id D357416F1F56; Thu, 11 Mar 2010 03:13:41 -0500 (EST) Received: by relay18.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 91B6316F1E69; Thu, 11 Mar 2010 03:13:41 -0500 (EST) Message-ID: <4B98A620.4060506@iwl.com> Date: Thu, 11 Mar 2010 00:13:20 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <201003102207.o2AM7krG075746@idle.juniper.net> In-Reply-To: <201003102207.o2AM7krG075746@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] defaults 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, 11 Mar 2010 08:13:40 -0000 Phil Shafer wrote: > Andy Bierman writes: >> Are you suggesting that the defaults behavior of the server >> MAY affect other RPC operations? > > Yes, it affect rpc input, output, and notifications. > >> I think the with-defaults draft should say how specific >> NETCONF operations deal with defaults. > > with-defaults is not the place to address this, since it's > optional. > >> 1) Does a create operation on a YANG default leaf succeed or fail >> with a 'data-exists' error? > > succeed; otherwise success must be defined as (not(error) || error/tag == 'data-exists') > >> 2) Does a delete operation succeed (and then the server creates the >> leaf again) or does it fail with a 'data-missing' error? > > fail; otherwise similar issue (where success is not trivial to discover) > >> 3) Is the 'explicit' notion of a default affect the create/delete >> operations at all? > This is why the client needs to know how the server treats defaults. This is why implementing with0defaults is a SHOULD, not an optional MAY. leaf foo { type int32; default 42; } 42 Is the server returning 'report-all' or 'explicit'? Yes. Will a create operation succeed or not? Who knows? The client has no idea. If another client set the value to '42', then the create will fail, but if the server set it to '42', then it will succeed. Weak. > yes. > > Thanks, > Phil > Andy From dromasca@avaya.com Thu Mar 11 05:36: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 E12F13A672E for ; Thu, 11 Mar 2010 05:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 kaLW3qWZfINq for ; Thu, 11 Mar 2010 05:36:06 -0800 (PST) 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 757CC3A690F for ; Thu, 11 Mar 2010 05:36:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,620,1262581200"; d="scan'208";a="208812432" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Mar 2010 08:36:05 -0500 X-IronPort-AV: E=Sophos;i="4.49,620,1262581200"; d="scan'208";a="440833625" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Mar 2010 08:36:05 -0500 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, 11 Mar 2010 14:35:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard Thread-Index: AcrBH21NA8oiGk5wRiOpPjrs9+n1cQAAFJDw From: "Romascanu, Dan (Dan)" To: Subject: [netmod] FW: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor 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, 11 Mar 2010 13:36:08 -0000 =20 -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Thursday, March 11, 2010 3:33 PM To: Romascanu, Dan (Dan) Cc: xml-dir@ietf.org; apps-discuss@ietf.org Subject: Re: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard On 11.03.2010 14:13, Romascanu, Dan (Dan) wrote: > XML and APPS Experts, > > I would like to draw you attention on the IETF Last Call for the YANG=20 > data modeling language for NETCONF that started yesterday and will=20 > last for about one month. > > Your comments and reviews will be appreciated. > > Thanks and Regards, > > Dan > ... Isolated comment: > 5.3. XML Namespaces > > All YANG definitions are specified within a module that is bound to a > particular XML Namespace [XML-NAMES], which is a globally unique URI > [RFC3986]. A NETCONF client or server uses the namespace during XML > encoding of data. > > Namespaces for modules published in RFC streams [RFC4844] MUST be > assigned by IANA, see Section 14. I don't see why this is a requirement. The whole point of using URIs as XML namespace identifiers is that you don't *need* a central authority for assignment. > Namespaces for private modules are assigned by the organization > owning the module without a central registry. Namespace URIs MUST be > chosen so they cannot collide with standard or other enterprise > namespaces, for example by using the enterprise or organization name > in the namespace. That's true, but IMHO just repeats best XML practice. > The "namespace" statement is covered in Section 7.1.3. Best regards, Julian From wjhns1@hardakers.net Thu Mar 11 07:01: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 7AA933A6BD4; Thu, 11 Mar 2010 07:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h+jNMvBb0lmt; Thu, 11 Mar 2010 07:01:35 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 9C2C93A6BEA; Thu, 11 Mar 2010 06:58:08 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 910CBA0CA7; Thu, 11 Mar 2010 06:58:12 -0800 (PST) From: Wes Hardaker To: "Romascanu\, Dan \(Dan\)" Organization: Sparta References: Date: Thu, 11 Mar 2010 06:58:12 -0800 In-Reply-To: (Dan Romascanu's message of "Wed, 10 Mar 2010 10:59:53 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 11 Mar 2010 15:01:36 -0000 >>>>> On Wed, 10 Mar 2010 10:59:53 +0100, "Romascanu, Dan (Dan)" said: DR> I suggest that we prepare a set of guidelines similar to the ones we DR> have for MIB documents at http://www.ops.ietf.org/mib-security.html DR> and we run them with the Security Directorate and AD's. You're talking about two different things here though. For the security guidelines for the yang language, shouldn't it be similar to what smiv2 has in it's document? And for new yang modules, yes a template would be good but that wouldn't go into the yang base? -- Wes Hardaker Cobham Analytic Solutions From mbj@tail-f.com Thu Mar 11 07:23: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 B4CC13A6BA8; Thu, 11 Mar 2010 07:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnRbrZzBniq2; Thu, 11 Mar 2010 07:23:57 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 042833A6BCC; Thu, 11 Mar 2010 07:22:19 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 33747616002; Thu, 11 Mar 2010 16:22:12 +0100 (CET) Date: Thu, 11 Mar 2010 16:22:11 +0100 (CET) Message-Id: <20100311.162211.146341507.mbj@tail-f.com> To: wjhns1@hardakers.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 11 Mar 2010 15:23:59 -0000 Wes Hardaker wrote: > >>>>> On Wed, 10 Mar 2010 10:59:53 +0100, "Romascanu, Dan (Dan)" > >>>>> said: > > DR> I suggest that we prepare a set of guidelines similar to the ones we > DR> have for MIB documents at http://www.ops.ietf.org/mib-security.html > DR> and we run them with the Security Directorate and AD's. > > You're talking about two different things here though. > > For the security guidelines for the yang language, shouldn't it be > similar to what smiv2 has in it's document? Isn't it pretty similar? SMIv2: This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet. YANG: This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet. Data modeled in YANG might contain sensitive information. RPCs or notifications defined in YANG might transfer sensitive information. Security issues are related to the usage of data modeled in YANG. Such issues shall be dealt with in documents describing the data models and documents about the interfaces used to manipulate the data e.g., the NETCONF documents. Data modeled in YANG is dependent upon: - the security of the transmission infrastructure used to send sensitive information - the security of applications which store or release such sensitive information. - adequate authentication and access control mechanisms to restrict the usage of sensitive data. /martin From wjhns1@hardakers.net Thu Mar 11 10:27:47 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 C61923A6F00; Thu, 11 Mar 2010 10:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 QKSIJsZwpGb4; Thu, 11 Mar 2010 10:27:47 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id B08523A6F07; Thu, 11 Mar 2010 09:56:45 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id F286E9E7BD; Thu, 11 Mar 2010 09:56:50 -0800 (PST) From: Wes Hardaker To: Martin Bjorklund Organization: Sparta References: <20100311.162211.146341507.mbj@tail-f.com> Date: Thu, 11 Mar 2010 09:56:51 -0800 In-Reply-To: <20100311.162211.146341507.mbj@tail-f.com> (Martin Bjorklund's message of "Thu, 11 Mar 2010 16:22:11 +0100 (CET)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 11 Mar 2010 18:27:47 -0000 >>>>> On Thu, 11 Mar 2010 16:22:11 +0100 (CET), Martin Bjorklund said: MB> SMIv2: MB> This document defines a language with which to write and read MB> descriptions of management information. The language itself has no MB> security impact on the Internet. Yeah, that should be rewritten ;-) If I were writing a clause, I'd be tempted to at least mention the fairly obvious: "Exposing any configuration objects to the network invariably offers an avenue for attack and must be mitigated through good network access policies and software robustness" or something like that. -- Wes Hardaker Cobham Analytic Solutions From mehmet.ersue@nsn.com Thu Mar 11 10:46:25 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 83B0A3A6D14; Thu, 11 Mar 2010 10:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 m2mfxTkD8yUg; Thu, 11 Mar 2010 10:46:24 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 9386E3A6D9B; Thu, 11 Mar 2010 10:16:23 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2BIGGL2018904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 19:16:16 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2BIGEI0030621; Thu, 11 Mar 2010 19:16:16 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 19:16:13 +0100 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, 11 Mar 2010 19:16:13 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A645A8B1C@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Security Considerations sections of YANG modules documents Thread-Index: AcrAOG6dwWRSMRw/S3WbXSldD8d9RwBDP8DQ References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , , X-OriginalArrivalTime: 11 Mar 2010 18:16:13.0945 (UTC) FILETIME=[EF424690:01CAC146] Cc: ext Gerhard Muenz , n.brownlee@auckland.ac.nz, quittek@neclab.eu Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 11 Mar 2010 18:46:25 -0000 Hi Dan, yes, we need to get it right. I hope we can get=20 some help from MIB security experts. Isn't the best place to give such a template and=20 guidance the document draft-ietf-netmod-yang-usage ? BTW: The first and much bigger YANG module we=20 have is in draft-ietf-ipfix-configuration-model, which has also a somewhat limited security=20 considerations section. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu,=20 > Dan (Dan) > Sent: Wednesday, March 10, 2010 11:00 AM > To: netconf@ietf.org; netmod@ietf.org > Subject: [Netconf] Security Considerations sections of YANG=20 > modules documents >=20 > While reading draft-ietf-netconf-monitoring-12.txt in preparation for > the AD review I observed that the Security Considerations section is > pretty 'thin', containing much less that can be found in the similar > sections of documents that include MIB modules. The security experts > will almost certainly consider that important information is=20 > missing and > the document will not pass the SEC-DIR and Security AD reviews. This > being the first document with a YANG module in the normative=20 > section, it > will also set kind of a model to be followed by other. I=20 > suggest that we > prepare a set of guidelines similar to the ones we have for MIB > documents at http://www.ops.ietf.org/mib-security.html and we run them > with the Security Directorate and AD's.=20 >=20 > Comments? Volunteers?=20 >=20 > Dan > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From andyb@iwl.com Thu Mar 11 11:00: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 EF7A63A6F0C for ; Thu, 11 Mar 2010 11:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 rVe50+eDee9R for ; Thu, 11 Mar 2010 11:00:06 -0800 (PST) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 0E1693A6F9E for ; Thu, 11 Mar 2010 10:34:42 -0800 (PST) Received: from relay19.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 3A03F27490C2; Thu, 11 Mar 2010 13:34:46 -0500 (EST) Received: by relay19.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D5A452748E91; Thu, 11 Mar 2010 13:34:45 -0500 (EST) Message-ID: <4B9937AD.1010108@iwl.com> Date: Thu, 11 Mar 2010 10:34:21 -0800 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Wes Hardaker References: <20100311.162211.146341507.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 11 Mar 2010 19:00:07 -0000 Wes Hardaker wrote: >>>>>> On Thu, 11 Mar 2010 16:22:11 +0100 (CET), Martin Bjorklund said: > > MB> SMIv2: > > MB> This document defines a language with which to write and read > MB> descriptions of management information. The language itself has no > MB> security impact on the Internet. > > Yeah, that should be rewritten ;-) > > If I were writing a clause, I'd be tempted to at least mention the > fairly obvious: "Exposing any configuration objects to the network > invariably offers an avenue for attack and must be mitigated through > good network access policies and software robustness" or something like that. The YANG Usage draft has this text, which might be appropriate for the YANG draft instead. 3.4. Security Considerations Section Each specification that defines one or more 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 module objects that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out; similarly, readable module objects 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. There aren't any specific security concerns with the data modeling language, but the YANG spec also contains normative mappings between the YANG syntax and NETCONF protocol behavior, and that certainly is within scope of the SC section. Andy From david.kessens@nsn.com Thu Mar 11 15:34: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 A719E3A68B2 for ; Thu, 11 Mar 2010 15:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Lmy9bPRyCD for ; Thu, 11 Mar 2010 15:34:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6CCE33A6802 for ; Thu, 11 Mar 2010 15:34:45 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2BNYnae005016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Mar 2010 00:34:49 +0100 Received: from localhost.localdomain ([10.138.51.158]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2BNYmdp016286 for ; Fri, 12 Mar 2010 00:34:48 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o2BNYl0g021765 for ; Thu, 11 Mar 2010 15:34:47 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o2BNYkkC021763 for netmod@ietf.org; Thu, 11 Mar 2010 15:34:46 -0800 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Thu, 11 Mar 2010 15:34:46 -0800 From: David Kessens To: NETMOD Working Group Message-ID: <20100311233445.GO3573@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] Draft agenda (v1) & call for agenda items 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, 11 Mar 2010 23:34:46 -0000 Please see below for our draft agenda. Please let us know whether you have any additional items that you would like to add to the agenda. David & David --- Draft Agenda (v1): NETMOD WG Meeting: IETF 77 Location: Hilton Anaheim, Anaheim, CA, USA WG Chairs: David Kessens (david.kessens@nsn.com) David Partain (david.partain@ericsson.com) Jabber: xmpp:netmod@jabber.ietf.org WG URL: http://tools.ietf.org/wg/netmod/ TUESDAY, March 23, 2010, 0900-1130, Huntington Room 1) Administrivia [chairs][ 5 min ] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min ] - How we're doing against the charter 3) Active Drafts For each draft: current status, delta from previous draft, open issues, and discussion. 3.1 Common YANG Data Types http://tools.ietf.org/html/draft-ietf-netmod-yang-types-07 Status: IETF Last Call (Juergen Schoenwaelder) 3.2 YANG - A data modeling language for NETCONF http://tools.ietf.org/html/draft-ietf-netmod-yang-11 Status: IETF Last Call (Martin Bjorklund) 3.3 YANG Usage Guidelines http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-03 Status: WG Last Call completed when meeting takes place (Andy Bierman) 3.4 NETMOD Architecture http://tools.ietf.org/html/draft-ietf-netmod-arch-04 Status: WG Last Call completed (Phil Shafer) 3.5 Mapping of YANG to DSDL http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-05 Status: will be in WG Last Call (Ladislav Lhotka) 4) Other (non WG) Internet-Drafts, for feedback and discussion [chairs, we will only spend time on these items if we have time] 5) I/O with other WGs (NETCONF/IPFIX/others ?), activities this week [chairs] 6) Plans post IETF77 and after completion of charter 7) A.O.B. and open mike [N.N.] {please identify issues in advance} --- From bernd.linowski.ext@nsn.com Fri Mar 12 06:27:48 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 AAE393A6B3F for ; Fri, 12 Mar 2010 06:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0-dSxv-B3ao for ; Fri, 12 Mar 2010 06:27:48 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A279A3A6CA5 for ; Fri, 12 Mar 2010 06:08:47 -0800 (PST) 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 o2CE8mNe004485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Mar 2010 15:08:49 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2CE8m0U020897 for ; Fri, 12 Mar 2010 15:08:48 +0100 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:08:47 +0100 Received: from FIESEXC030.nsn-intra.net ([10.135.48.16]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:08:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Mar 2010 16:08:44 +0200 Message-ID: <2E23AE0E4AED07418C26486630C852A08C516E@FIESEXC030.nsn-intra.net> In-Reply-To: <20100311233445.GO3573@nsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-linowski-netmod-yang-abstract Thread-Index: AcrBc3dUVXPzWWQKQc2LTpo1fK5yqgAedNNg References: <20100311233445.GO3573@nsn.com> From: "Linowski, Bernd (EXT-Other - DE)" To: "NETMOD Working Group" X-OriginalArrivalTime: 12 Mar 2010 14:08:47.0403 (UTC) FILETIME=[88717FB0:01CAC1ED] Subject: [netmod] New version of draft-linowski-netmod-yang-abstract 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, 12 Mar 2010 14:27:48 -0000 Hi All, we revised our draft on "Extending YANG with Language Abstractions" with a new co-author Siarhei Kuryla from Jacobs University Bremen. After review and comments from different parties we introduced changes which we hope get the draft round and more stable. We also started two implementations based on existing open source packages for the proposed YANG extensions (pyang and libsmi).=20 Pyang part will be hopefully available parallel to the IETF week. libsmi is going to come end of April. Please send your comments and suggestions to Netmod list.=20 Regards, Bernd From mehmet.ersue@nsn.com Fri Mar 12 06:54: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 481883A68D3 for ; Fri, 12 Mar 2010 06:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 jEU8JUnao+RG for ; Fri, 12 Mar 2010 06:54:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 9035E3A6A50 for ; Fri, 12 Mar 2010 06:36:06 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2CEa9jv006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Mar 2010 15:36:10 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2CEa9rZ001555 for ; Fri, 12 Mar 2010 15:36:09 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:36:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Mar 2010 15:36:08 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A645A8E2B@DEMUEXC006.nsn-intra.net> In-Reply-To: <2E23AE0E4AED07418C26486630C852A08C516E@FIESEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] New version of draft-linowski-netmod-yang-abstract Thread-Index: AcrBc3dUVXPzWWQKQc2LTpo1fK5yqgAedNNgAADm/vA= References: <20100311233445.GO3573@nsn.com> <2E23AE0E4AED07418C26486630C852A08C516E@FIESEXC030.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "NETMOD Working Group" X-OriginalArrivalTime: 12 Mar 2010 14:36:09.0358 (UTC) FILETIME=[5B1FF2E0:01CAC1F1] Subject: Re: [netmod] New version of draft-linowski-netmod-yang-abstract 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, 12 Mar 2010 14:54:55 -0000 Please find the draft at: http://tools.ietf.org/html/draft-linowski-netmod-yang-abstract-02 Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Linowski,=20 > Bernd (EXT-Other - DE) > Sent: Friday, March 12, 2010 3:09 PM > To: NETMOD Working Group > Subject: [netmod] New version of draft-linowski-netmod-yang-abstract >=20 > Hi All, >=20 > we revised our draft on "Extending YANG with Language=20 > Abstractions" with > a new co-author Siarhei Kuryla from Jacobs University Bremen. >=20 > After review and comments from different parties we introduced changes > which we hope get the draft round and more stable. >=20 > We also started two implementations based on existing open source > packages for the proposed YANG extensions (pyang and libsmi).=20 > Pyang part will be hopefully available parallel to the IETF=20 > week. libsmi > is going to come end of April. > Please send your comments and suggestions to Netmod list.=20 >=20 > Regards, > Bernd > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Sun Mar 14 16:55:58 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 4F44B3A6801; Sun, 14 Mar 2010 16:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 al5NUIRWug8n; Sun, 14 Mar 2010 16:55:57 -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 482DE3A6897; Sun, 14 Mar 2010 16:55:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.49,639,1262581200"; d="scan'208";a="7504315" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 14 Mar 2010 19:56:01 -0400 X-IronPort-AV: E=Sophos;i="4.49,639,1262581200"; d="scan'208";a="455219670" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Mar 2010 19:56:00 -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: Mon, 15 Mar 2010 00:55:41 +0100 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A645A8B1C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Security Considerations sections of YANG modules documents Thread-Index: AcrAOG6dwWRSMRw/S3WbXSldD8d9RwBDP8DQAKMWcYA= References: <80A0822C5E9A4440A5117C2F4CD36A645A8B1C@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , , Cc: ext Gerhard Muenz , n.brownlee@auckland.ac.nz, quittek@neclab.eu Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 14 Mar 2010 23:55:58 -0000 =20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 >=20 > BTW: The first and much bigger YANG module we have is in=20 > draft-ietf-ipfix-configuration-model, > which has also a somewhat limited security considerations section. >=20 > Cheers, > Mehmet >=20 The IPFIX document was not yet submitted to the IESG.=20 Dan From wjhns1@hardakers.net Mon Mar 15 07:01: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 9CFBE3A688F; Mon, 15 Mar 2010 07:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 4vdoMfqPTC+C; Mon, 15 Mar 2010 07:01:24 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A893E3A67A7; Mon, 15 Mar 2010 07:01:24 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 23F1E991F4; Mon, 15 Mar 2010 07:01:31 -0700 (PDT) From: Wes Hardaker To: andyb@iwl.com Organization: Sparta References: <20100311.162211.146341507.mbj@tail-f.com> <4B9937AD.1010108@iwl.com> Date: Mon, 15 Mar 2010 07:01:30 -0700 In-Reply-To: <4B9937AD.1010108@iwl.com> (Andy Bierman's message of "Thu, 11 Mar 2010 10:34:21 -0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Security Considerations sections of YANG modules documents 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, 15 Mar 2010 14:01:28 -0000 >>>>> On Thu, 11 Mar 2010 10:34:21 -0800, Andy Bierman said: AB> The YANG Usage draft has this text, which might be appropriate AB> for the YANG draft instead. I think that'd be good text to include. -- Wes Hardaker Cobham Analytic Solutions From david.partain@ericsson.com Tue Mar 16 03:08: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 DC85E3A6859 for ; Tue, 16 Mar 2010 03:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 ShMUNboJuTe7 for ; Tue, 16 Mar 2010 03:08:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4E0293A6358 for ; Tue, 16 Mar 2010 03:08:32 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-31-4b9f58a7c237 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CB.51.23740.7A85F9B4; Tue, 16 Mar 2010 11:08:39 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 11:08:39 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 11:08:39 +0100 Content-Language: en-US Content-Disposition: inline From: David Partain Organization: Ericsson AB To: netmod@ietf.org Date: Tue, 16 Mar 2010 11:08:38 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003161108.38711.david.partain@ericsson.com> X-OriginalArrivalTime: 16 Mar 2010 10:08:39.0331 (UTC) FILETIME=[A6372F30:01CAC4F0] X-Brightmail-Tracker: AAAAAA== Subject: [netmod] Working Group Last Call: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content 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, 16 Mar 2010 10:08:34 -0000 Greetings, This is a 21-day (note! 3 weeks) working group last call on the current working group document: - Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content - http://www.ietf.org/id/draft-ietf-netmod-dsdl-map-05.txt This WGLC will end on 2010-04-06. 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. Thanks. David^2 (ps. all docs now in WGLC or IETF LC!) From mbj@tail-f.com Wed Mar 17 04:35: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 A72263A6859 for ; Wed, 17 Mar 2010 04:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.026 X-Spam-Level: * X-Spam-Status: No, score=1.026 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Bh20JirtCoKw for ; Wed, 17 Mar 2010 04:35:54 -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 2A76E3A6358 for ; Wed, 17 Mar 2010 04:35:53 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C4DF5616009 for ; Wed, 17 Mar 2010 12:36:02 +0100 (CET) Date: Wed, 17 Mar 2010 12:36:02 +0100 (CET) Message-Id: <20100317.123602.54287723.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <201003080950.11921.david.partain@ericsson.com> References: <201003080950.11921.david.partain@ericsson.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Working Group Last Call: Guidelines for Authors and Reviewers of YANG Data Model Documents 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, 17 Mar 2010 11:35:55 -0000 Hi, I have reviewed this document, and here are my comments: sec 2.2. -------- The term 'application' is not used (at least not in the 4741 sense) sec 4.1. -------- The text says: Modules contained in standards track documents SHOULD be named with the prefix 'ietf-'. Other types of modules MUST NOT use the 'ietf-' prefix string. But the YANG spec has a different text in its IANA Considerations: The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844] while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams must have a similar suitable prefix. The prefix 'iana-' is reserved for modules maintained by IANA. I suggest the text in this document is removed, or aligned with the YANG text, or replaced with a pointer to the YANG text. sec 4.4. -------- The text says: All 'must' and 'when' statements MUST contain valid XPath. If any name tests are present, they MUST contain valid module prefixes and data node names. References to non-existent nodes are considered invalid in YANG, even though they are permitted in XPath. The last sentence is not correct and should be removed. sec 4.5. -------- The text says: The module namespace URI value SHOULD NOT be changed, once the document containing the module is published. The YANG spec says, in sec 10: Furthermore, the "namespace" statement MUST NOT be changed, Either s/SHOULD NOT/MUST NOT/ or remove the sentence (since it is redundant). sec 4.6. -------- The text says: The reference statement MUST be present. It MUST identify the published document which contains the module. [...] A revision statement MUST be present for each published version of the module. This is not what we're currently using in yang-types and netconf monitoring. I suggest the first quoted paragraph is removed, and the second is extended with: The revision statement MUST have a reference substatement. It MUST identify the published document which contains the module. sec 4.7 ------- o allows early implementors to use the modules without picking a random value for this field. ^^^^^^^^^^ which field? It seems some intro sentence is missing in this section. Appendix A. ----------- There are quite a few TBD and missing links here. Do we have a plan for fixing them? /martin From phil@juniper.net Wed Mar 17 04:57: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 5F66D3A68B4 for ; Wed, 17 Mar 2010 04:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 SGo4NnT+4RMq for ; Wed, 17 Mar 2010 04:57:13 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 6B1513A67FD for ; Wed, 17 Mar 2010 04:57:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS6DDoJ+Gz/Kb1Tg1mJuJrAo4SjnAMaF5@postini.com; Wed, 17 Mar 2010 04:57:23 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.1.393.1; Wed, 17 Mar 2010 04:54:42 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 04:54:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 04:54:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 04:54:41 -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 o2HBseD29150; Wed, 17 Mar 2010 04:54:40 -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 o2HBcMUR030093; Wed, 17 Mar 2010 11:38:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003171138.o2HBcMUR030093@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20100317.123602.54287723.mbj@tail-f.com> Date: Wed, 17 Mar 2010 07:38:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Mar 2010 11:54:41.0424 (UTC) FILETIME=[A0BB4900:01CAC5C8] MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Working Group Last Call: Guidelines for Authors and Reviewers of YANG Data Model Documents 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, 17 Mar 2010 11:57:14 -0000 Martin Bjorklund writes: >sec 4.4. >-------- > The text says: > > All 'must' and 'when' statements MUST contain valid XPath. If any > name tests are present, they MUST contain valid module prefixes and > data node names. References to non-existent nodes are considered > invalid in YANG, even though they are permitted in XPath. > > > The last sentence is not correct and should be removed. The first sentence is redundant (since YANG already requires valid xpath expressions) and should be removed. The second is also redundant, since valid prefixes and node names are required for valid xpath expressions (in the sense that a node name must follow the rules of what is a valid node name, not that the node must match a node defined in the YANG module). Thanks, Phil From calle@tail-f.com Wed Mar 17 05:26: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 ACB273A67FD; Wed, 17 Mar 2010 05:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2, 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 pgXlugdxQpB4; Wed, 17 Mar 2010 05:26: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 710D53A659A; Wed, 17 Mar 2010 05:26:46 -0700 (PDT) Received: from [192.168.1.143] (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 11A42616009; Wed, 17 Mar 2010 13:26:56 +0100 (CET) Message-ID: <4BA0CA8F.3010805@tail-f.com> Date: Wed, 17 Mar 2010 13:26:55 +0100 From: Carl Moberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: NETCONF WG , NETMOD WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 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, 17 Mar 2010 12:26:46 -0000 This is an open invitation for sharing and discussing implementation and operational experiences of NETCONF and YANG on Sunday, March 21 2010 from 12:00noon to 3:00pm in the Carmel room at the Anaheim Hilton. We are particularily looking for input to the following open questions: - Any experience from implementing NETCONF and YANG? - What can be expected from NETCONF and YANG implementations? - Any operational pros and cons of NETCONF and YANG? - What can be done to make NETCONF and YANG more useful in operator environments? - Any additional ideas or thoughts on where NETCONF and YANG could be applicable to address configuration management issues? Refreshments will be available. Regards, -- Carl Moberg mailto:calle@tail-f.com http://www.tail-f.com From mehmet.ersue@nsn.com Wed Mar 17 08:51:15 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 4969C3A68C6; Wed, 17 Mar 2010 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2] 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 0N0nDEEZmVVS; Wed, 17 Mar 2010 08:51:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EF2093A6896; Wed, 17 Mar 2010 08:51:13 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFpLJk018533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 16:51:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFpL2N016738; Wed, 17 Mar 2010 16:51:21 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 16:51:20 +0100 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, 17 Mar 2010 16:51:17 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A645DAECB@DEMUEXC006.nsn-intra.net> In-Reply-To: <4BA0CA8F.3010805@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 Thread-Index: AcrFzSTXdecsW1wqQxuESOlfYGbdLAAG6fUQ References: <4BA0CA8F.3010805@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Carl Moberg" , "NETCONF WG" , "NETMOD WG" X-OriginalArrivalTime: 17 Mar 2010 15:51:20.0936 (UTC) FILETIME=[B04CDE80:01CAC5E9] Subject: Re: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 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, 17 Mar 2010 15:51:15 -0000 Dear Carl, thank you for orbaizing this valuable discussion. There is the IEPG meeting until noon. I assume=20 Bert and David K will be also in the IEPG meeting. Would it make sense to start the discussion at 12:30=20 to catch some food beforehand? Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Carl Moberg > Sent: Wednesday, March 17, 2010 1:27 PM > To: NETCONF WG; NETMOD WG > Subject: [netmod] Invitation to NETCONF and YANG=20 > discussions,Sunday @ IETF 77 >=20 > This is an open invitation for sharing and discussing implementation > and operational experiences of NETCONF and YANG on Sunday, March 21 > 2010 from 12:00noon to 3:00pm in the Carmel room at the=20 > Anaheim Hilton. >=20 > We are particularily looking for input to the following open=20 > questions: > - Any experience from implementing NETCONF and YANG? > - What can be expected from NETCONF and YANG implementations? > - Any operational pros and cons of NETCONF and YANG? > - What can be done to make NETCONF and YANG more useful in > operator environments? > - Any additional ideas or thoughts on where NETCONF and YANG could be > applicable to address configuration management issues? >=20 > Refreshments will be available. >=20 > Regards, > --=20 > Carl Moberg > mailto:calle@tail-f.com > http://www.tail-f.com > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mehmet.ersue@nsn.com Wed Mar 17 08:53: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 786FF28C0E8; Wed, 17 Mar 2010 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2] 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 joAluqRobE6o; Wed, 17 Mar 2010 08:53:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 58AA928C0E6; Wed, 17 Mar 2010 08:53:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFrX1w015946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 16:53:33 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFrVAN022286; Wed, 17 Mar 2010 16:53:32 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 16:53:32 +0100 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, 17 Mar 2010 16:53:21 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A645DAECF@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 Thread-Index: AcrFzSTXdecsW1wqQxuESOlfYGbdLAAG6fUQAABAlkA= References: <4BA0CA8F.3010805@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Carl Moberg" , "NETCONF WG" , "NETMOD WG" X-OriginalArrivalTime: 17 Mar 2010 15:53:32.0312 (UTC) FILETIME=[FE9B4180:01CAC5E9] Subject: Re: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 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, 17 Mar 2010 15:53:26 -0000 s/ba/gan/ =20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich)=20 > Sent: Wednesday, March 17, 2010 4:51 PM > To: 'ext Carl Moberg'; NETCONF WG; NETMOD WG > Subject: RE: [netmod] Invitation to NETCONF and YANG=20 > discussions,Sunday @ IETF 77 >=20 >=20 > Dear Carl, >=20 > thank you for orbaizing this valuable discussion. >=20 > There is the IEPG meeting until noon. I assume=20 > Bert and David K will be also in the IEPG meeting. >=20 > Would it make sense to start the discussion at 12:30=20 > to catch some food beforehand? >=20 > Cheers, > Mehmet >=20 > =20 >=20 > > -----Original Message----- > > From: netmod-bounces@ietf.org=20 > > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Carl Moberg > > Sent: Wednesday, March 17, 2010 1:27 PM > > To: NETCONF WG; NETMOD WG > > Subject: [netmod] Invitation to NETCONF and YANG=20 > > discussions,Sunday @ IETF 77 > >=20 > > This is an open invitation for sharing and discussing implementation > > and operational experiences of NETCONF and YANG on Sunday, March 21 > > 2010 from 12:00noon to 3:00pm in the Carmel room at the=20 > > Anaheim Hilton. > >=20 > > We are particularily looking for input to the following open=20 > > questions: > > - Any experience from implementing NETCONF and YANG? > > - What can be expected from NETCONF and YANG implementations? > > - Any operational pros and cons of NETCONF and YANG? > > - What can be done to make NETCONF and YANG more useful in > > operator environments? > > - Any additional ideas or thoughts on where NETCONF and=20 > YANG could be > > applicable to address configuration management issues? > >=20 > > Refreshments will be available. > >=20 > > Regards, > > --=20 > > Carl Moberg > > mailto:calle@tail-f.com > > http://www.tail-f.com > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >=20 From calle@tail-f.com Wed Mar 17 10:03: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 AA4AC3A6A3A; Wed, 17 Mar 2010 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2, 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 7y4cqZC56x1T; Wed, 17 Mar 2010 10:03:18 -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 55CD43A67A3; Wed, 17 Mar 2010 10:03:18 -0700 (PDT) Received: from calle-macbook.local (c83-250-192-57.bredband.comhem.se [83.250.192.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D130E61600A; Wed, 17 Mar 2010 18:03:26 +0100 (CET) Message-ID: <4BA10B5D.40209@tail-f.com> Date: Wed, 17 Mar 2010 18:03:25 +0100 From: Carl Moberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4BA0CA8F.3010805@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A645DAECB@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A645DAECB@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF WG , NETMOD WG Subject: Re: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 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, 17 Mar 2010 17:03:19 -0000 Mehmet, We are arranging for food to be available in the room (TBA exactly what, but something like pizza). On 2010-03-17 16:51 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear Carl, > > thank you for orbaizing this valuable discussion. > > There is the IEPG meeting until noon. I assume > Bert and David K will be also in the IEPG meeting. > > Would it make sense to start the discussion at 12:30 > to catch some food beforehand? > > Cheers, > Mehmet > > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of ext Carl Moberg >> Sent: Wednesday, March 17, 2010 1:27 PM >> To: NETCONF WG; NETMOD WG >> Subject: [netmod] Invitation to NETCONF and YANG >> discussions,Sunday @ IETF 77 >> >> This is an open invitation for sharing and discussing implementation >> and operational experiences of NETCONF and YANG on Sunday, March 21 >> 2010 from 12:00noon to 3:00pm in the Carmel room at the >> Anaheim Hilton. >> >> We are particularily looking for input to the following open >> questions: >> - Any experience from implementing NETCONF and YANG? >> - What can be expected from NETCONF and YANG implementations? >> - Any operational pros and cons of NETCONF and YANG? >> - What can be done to make NETCONF and YANG more useful in >> operator environments? >> - Any additional ideas or thoughts on where NETCONF and YANG could be >> applicable to address configuration management issues? >> >> Refreshments will be available. >> >> Regards, >> -- >> Carl Moberg >> mailto:calle@tail-f.com >> http://www.tail-f.com >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From j.schoenwaelder@jacobs-university.de Fri Mar 19 08:34: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 253DC3A6A75 for ; Fri, 19 Mar 2010 08:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 IjBOITaGNjW5 for ; Fri, 19 Mar 2010 08:34:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5FF383A6860 for ; Fri, 19 Mar 2010 08:34:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2148AC0010 for ; Fri, 19 Mar 2010 16:34:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D835uo+EC1Zu; Fri, 19 Mar 2010 16:34:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19D09C000F; Fri, 19 Mar 2010 16:34:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EEE4410E641B; Fri, 19 Mar 2010 16:34:29 +0100 (CET) Date: Fri, 19 Mar 2010 16:34:29 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20100319153429.GA6270@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [netmod] js review of draft-ietf-netmod-yang-usage-03 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: Fri, 19 Mar 2010 15:34:21 -0000 Hi, here is my review of draft-ietf-netmod-yang-usage-03. a) RFC 4741 (and also 4741bis) state that "client" and "application" mean the same. Given this, I suggest to only use one term and I think this should be "client". b) RFC 4741 and YANG have confusion concerning the terms "operation" and RPC. I suggest we use "operation" when we talk about definitions of "operations" using the "rpc" keyword, this not even importing the definition of "RPC" (see also h) below). c) Section 3.1 is confusing: This section MUST contain a verbatim copy of the latest approved Internet-Standard Management Framework boilerplate, which is available on-line, in section 4 of the Trust Legal Provisions (TLP) document, at: http://trustee.ietf.org/license-info/ I assume the "Internet-Standard Management Framework boilerplate" is this here and hardly applicable to YANG modules. Will there be a new one? That said, the quoted sentence then starts talking about the TLP stuff, which is clearly confusing two separate things. d) s/Internet Draft or RPC MUST/Internet Draft or RFC MUST/ e) Do we really have to mention NETCONF capabilities? A module may be conceptually partitioned in several ways, using the 'if-feature' and/or 'when' statements. In addition, NETCONF capabilities are designed to identify optional functionality. I suggest the last sentence to be removed. Also in the light of this text: Objects SHOULD NOT directly reference NETCONF capabilities, in order to specify optional behavior. Instead, a 'feature' statement SHOULD be defined to represent the NETCONF capability, and the 'if-feature' statement SHOULD be used within the object definition. f) Section 4.6. requires this: The description statement MUST be present. If the module is contained in an unpublished document, then the file name of this document SHOULD be identified in the description statement. This text MUST be removed when the document is published. It turns out that the sample module in Appendix B has this wrong and I also checked the YANG data types modules - they also have this wrong. So my conclusion is that the requirement to list the filename is a good idea in principle but since authors are lazy, the rule will do more harm than being useful. So I suggest to remove the requirement to list the file name. g) Section 4.7 defines a requirement how to choose namespaces for unpublished YANG modules. Again, the goals behind this idea are good ones, but both the YANG usage guidelines document and the YANG data types document fail to comply - they both have an old version number in the namespace. Again, I am concerned that we introduce rules that would be nice to have but will likely not work in practice. I suggest that all text starting with "An unpublished module namespace ..." until the end of the section gets removed since I doubt these rules will work in practice. (The only way to make these rules work would be to completely automate this so that xml2rfc ensures the right values are put in place.) If the text is not removed, s/RPC/RFC/ in 4.7. h) Rewrite of 4.12 to avoid "RPC": 4.12. Operation Definitions The description statement MUST be present in 'rpc' statements defining new operations. If the operation semantics are defined in an external document, then a reference statement SHOULD be present. If the operation impacts system behavior in some way, it SHOULD be mentioned in the description statement. If the operation is potentially harmful to system behavior in some way, it MUST be mentioned in the Security Considerations section of the document. i) Appendix A: SNMP boilerplate The text says: 3. YANG Module Boilerplate -- verify that the draft contains the latest approved SNMP Network Management Framework boilerplate from the OPS area web site (http://www.ops.ietf.org/mib-boilerplate.html). [ed: real URL TBD] This is related to issue c) above. I doubt we need the SNMP boilerplate. j) Appendix A: MIB security boilerplate 4. Security Considerations Section -- verify that the draft uses the latest approved template from the OPS area web site (http://www.ops.ietf.org/mib-security.html) and that the guidelines therein have been followed. Again, we might need our own text instead of refering to the MIB security boilerplate. k) Appendix A: Copyright / IPR notices 7. Copyright Notices -- verify that the draft contains an abbreviated copyright notice in the description statement of each YANG module or sub-module, and that it contains the full copyright notice and disclaimer specified in Sections 5.4 and 5.5 of RFC 3978 at the end of the document. Make sure that the correct year is used in all copyright dates. 8. IPR Notice -- if the draft does not contains a verbatim copy of the IPR notice specified in Section 5 of RFC 3979, recommend that the IPR notice be included. I think both items need updates to recognize the trust. I have no clue what the replacement text should be though. ;-) l) Appendix B: copyright notice I believe we can use a shorter copyright statement but I leave it to TLP experts to figure out which one is the right template to use. done :) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Sun Mar 21 11:48: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 D248C3A68DC for ; Sun, 21 Mar 2010 11:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 bqYOGWSUaPe0 for ; Sun, 21 Mar 2010 11:48:59 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E95733A6784 for ; Sun, 21 Mar 2010 11:48:58 -0700 (PDT) Received: from [130.129.25.190] (unknown [130.129.25.190]) by office2.cesnet.cz (Postfix) with ESMTPSA id 5B9BF2CDE058 for ; Sun, 21 Mar 2010 19:49:13 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Sun, 21 Mar 2010 11:49:10 -0700 Message-ID: <1269197350.3534.100.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] LL review of draft-ietf-netmod-yang-usage-03 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, 21 Mar 2010 18:48:59 -0000 Hi, here are my comments to YANG Usage Guidelines: The text provides useful information for YANG module writers, users and reviewer. Clearly, the guidelines are based on Andy's extensive practical experience with YANG. Specific comments: Sec. 3.5.2: Why must the IANA record for the *existing* module be updated if a new submodule belonging to that module is published? The IANA registry as defined in Sec. 14 of [YANG] doesn't keep the list of submodules for a module. Sec. 4.2: If the identifier length restriction is meant only for standard-track modules, it should be clearly stated. Sec. 4.4: Fifth paragraph seems to indicate that all node names in XPath expressions must carry namespace prefixes. It should mention the special convention for the default namespace that YANG uses. 7th paragraph: There are valid reasons for using position() and last() for the items of an "ordered-by user" list. 10th paragraph: This is a significant restriction. What are these misbehaving boundary conditions? Sec. 4.6: Paragraph 3: s/documented/document/ Sec. 4.7: I suggest to rewrite the first paragraph as follows: It is desirable to include only valid YANG modules in documents, whether they are published yet or not. This allows o the module to compile correctly instead of generating disruptive fatal errors. o early implementors to use the modules without picking a random value for this field. o early interoperability testing since independent implementations will use the same namespace value. Paragraph 4: s/RPC/RFC/ Sec. 4.8: First paragraph: The second sentence with MAY should be removed - the definition of SHOULD in RFC 2119 says exactly this. Paragraph 4: I don't want to re-ignite the discussion on mandatory, but this is not how YANG spec defines mandatory nodes. Sec. 4.11: I am against having a description statement as a MUST. If the YANG code is sufficiently clear, a description statement is just a nuisance. It may lead to trivial descriptions like "This grouping contains two nodes." Paragraph 4: Is the restriction on "anyxml" necessary? I can imagine a "banner" configuration statement which is allowed to contain HTML - it may be defined as "anyxml". Paragraph 6: I don't understand "max-elements" statement in this way. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bernd.linowski.ext@nsn.com Mon Mar 22 14:08:18 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 EEFB728C0DE for ; Mon, 22 Mar 2010 14:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 iqnsFvjXJef8 for ; Mon, 22 Mar 2010 14:08:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C82FD28C1E4 for ; Mon, 22 Mar 2010 14:01:44 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2ML20SG030965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Mar 2010 22:02:00 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2ML1xI2013364; Mon, 22 Mar 2010 22:01:59 +0100 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 22:01:59 +0100 Received: from FIESEXC030.nsn-intra.net ([10.135.48.16]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 23:01:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2010 23:01:57 +0200 Message-ID: <2E23AE0E4AED07418C26486630C852A092E19B@FIESEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Complex types plug-in for pyang Thread-Index: AcrBc3dUVXPzWWQKQc2LTpo1fK5yqgAedNNgAgS31j4= References: <20100311233445.GO3573@nsn.com> <57A19A7D2A67344997226E702D897CC4BD4B0D6B@FIESEXC030.nsn-intra.net> From: "Linowski, Bernd (EXT-Other - DE)" To: "NETMOD Working Group" X-OriginalArrivalTime: 22 Mar 2010 21:01:59.0123 (UTC) FILETIME=[E9974230:01CACA02] Cc: s.kuryla@jacobs-university.de Subject: [netmod] Complex types plug-in for pyang 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, 22 Mar 2010 21:08:18 -0000 Hi, The complex type plug-in for pyang that implements the YANG extensions = described in draft-linowski-netmod-yang-abstract-02 can be downloaded from=20 http://code.google.com/p/pyang-ct/ In case you have questions or comments concerning the plug-in, please = send=20 them to Siarhei and me. Regards, Bernd From bertietf@bwijnen.net Tue Mar 23 13:07: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 477903A659A for ; Tue, 23 Mar 2010 13:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.781 X-Spam-Level: * X-Spam-Status: No, score=1.781 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 f9sWos9tMYZL for ; Tue, 23 Mar 2010 13:07:03 -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 8D6E83A6BF0 for ; Tue, 23 Mar 2010 13:06:56 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NuANR-0003MA-RG for netmod@ietf.org; Tue, 23 Mar 2010 21:07:12 +0100 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=dhcp-wireless-open-abg-24-67.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NuANR-0008K9-HB for netmod@ietf.org; Tue, 23 Mar 2010 21:07:01 +0100 Message-ID: <4BA91F64.70801@bwijnen.net> Date: Tue, 23 Mar 2010 13:07:00 -0700 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: 86ab03e524994f79ca2c75a176445dd4848aae82b737a142b196da79900302ad X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4848aae82b737a142b196da79900302ad Subject: [netmod] first 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, 23 Mar 2010 20:07:04 -0000 This is the text I presented this morning at the end of the netmod session. Comments to the netmod mailing list pls Bert --- first draft -----> X. Security Considerations -- 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 -- unathorized 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: From phil@juniper.net Tue Mar 23 13:59: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 99D7F3A688F for ; Tue, 23 Mar 2010 13:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 rKNvVmkKAxCt for ; Tue, 23 Mar 2010 13:59:28 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 8F54A3A6784 for ; Tue, 23 Mar 2010 13:59:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKS6krw20GmOEjWeW6eNEJgXQ9cpAv6882@postini.com; Tue, 23 Mar 2010 13:59:48 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.1.393.1; Tue, 23 Mar 2010 13:57:03 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 13:57:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 13:57:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 13:57:02 -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 o2NKv1D07414 for ; Tue, 23 Mar 2010 13:57:01 -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 o2NKebhj078719 for ; Tue, 23 Mar 2010 20:40:37 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003232040.o2NKebhj078719@idle.juniper.net> To: Date: Tue, 23 Mar 2010 16:40:37 -0400 From: Phil Shafer X-OriginalArrivalTime: 23 Mar 2010 20:57:02.0790 (UTC) FILETIME=[63602E60:01CACACB] MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] Additional text for the architecture draft 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, 23 Mar 2010 20:59:29 -0000 Here is the additional text based on this morning's comments from Andy and Dan. Please review and provide feedback. This text will assumably be added to the post-IETF revision of the draft. Thanks, Phil -------- +** Building YANG-based Solutions + +In the typical YANG-based solution, the client and server are driven +by the content of YANG modules. The server includes the definitions +of the modules as meta-data that is available to the NETCONF engine. +This engine processes incoming requests, uses the meta-data to parse +and verify the request, performs the requested operation, and returns +the results to the client. + + +----------------------------+ + |Server (device) | + | +--------------------+ | + | | configuration | | + +----+ | | ---------------| | + |YANG|+ | | m d state data | | + |mods||+ | | e a ---------------| | + +----+|| -----> | t t notifications | | + +----+| | | a a ---------------| | + +----+ | | operations | | + | +--------------------+ | + | ^ | + | | | + | v | + +------+ | +-------------+ | + | | -------------> | | | + |Client| | | NETCONF | | + | (app)| | | engine | | + | | <------------ | | | + +------+ +-------------+ | + | / \ | + | / \ | + | / \ | + | +--------+ +---------+ | + | | config | |system |+ | + | | data- | |software ||+ | + | | base | |component||| | + | +--------+ +---------+|| | + | +---------+| | + | +---------+ | + +----------------------------+ + +To use YANG, YANG modules must be defined to model the specific +problem domain. These modules are then loaded, compiled, or coded +into the server. + +The sequence of events for the typical client/server interaction is as +follows: + +- A client application ([C]) opens a NETCONF session to the server +(device) ([S]) +- [C] and [S] exchange messages containing the list of +capabilities supported by each side, allowing [C] to learn the modules +supported by [S] +- [C] builds and sends an operation defined in the YANG module, +encoded in XML, within NETCONF's element +- [S] receives and parses the element +- [S] verifies the contents of the request against the data defined in +the YANG module +- [S] performs the requested operation, possibly changing the +configuration database +- [S] builds the response, containing the response, any requested +data, and any errors +- [S] sends the response, encoded in XML, within NETCONF's +element +- [C] receives and parses the element +- [C] inspects the response and processes it as needed + +Note that there is no requirement for the client or server to process +the YANG modules in this way. The server may hard code the contents +of the data model, rather than handle the content via a generic +engine. Or the client may be targeted at the specific YANG model, +rather than being driven generically. Such a client might be a simple +shell script that stuffs arguments into an XML payload and sends it to +the server. From ray@iijlab.net Tue Mar 23 15:18: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 1163F3A69BB for ; Tue, 23 Mar 2010 15:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.454 X-Spam-Level: *** X-Spam-Status: No, score=3.454 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 1sV8C3XppUOf for ; Tue, 23 Mar 2010 15:18:19 -0700 (PDT) Received: from omgo.iij.ad.jp (mo00.iij.ad.jp [202.232.30.145]) by core3.amsl.com (Postfix) with ESMTP id 7F9483A695D for ; Tue, 23 Mar 2010 15:18:18 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iijlab.net;h=Message-ID: Date:From:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; i=ray@iijlab.net; s=omgo1; t=1269382714; x=1270592314; bh=AvoqiB2nX40/wM+rwK4Fj5Vb8QHdRiCxAcT0BGRQJ3U=; b=jBGiIRLJC+lTNnJDnWnpg6qhcQ7 cUT/E9ggbZgqLlllJ4V4Dph+sk6601u4VE4V9agH0IAOrgIZBUTgz0BGsBduXTJ/FtZcVya8OdkFz tdQczMXs+Lp+MqvGBDeLZZvjEBLzQnknzfUf36Ft1Un2EsTFcVSGSYPTgkryOnzcYQs=; Received: by omgo.iij.ad.jp (mo00) id o2NMIYWZ003667; Wed, 24 Mar 2010 07:18:34 +0900 Message-ID: <4BA93E43.2020606@iijlab.net> Date: Wed, 24 Mar 2010 07:18:43 +0900 From: "Ray S. Atarashi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <201002281659.24506.david.partain@ericsson.com> <201003101305.19003.david.partain@ericsson.com> <20100310122150.GA9134@elstar.local> In-Reply-To: <20100310122150.GA9134@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management 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, 23 Mar 2010 22:18:37 -0000 Hi, I read the draft but didn't send comments because I thought LC was finished. Could you give me a chance? In Section 1, I prefer to be describe "why datamodel language is needed for NETCONF" first. In first four paragraphs, the reason was described already. After that, "why we defined YANG though there ware other datamodel languages" should be described. Could you consider to separate section 1 into 2 parts? And could you add a description about "who is a user of YANG?" Thanks! Ray (2010/03/10 21:21), Juergen Schoenwaelder wrote: > On Wed, Mar 10, 2010 at 01:05:18PM +0100, David Partain wrote: >> On Sunday 28 February 2010 16.59.24 David Partain wrote: >>> Dear all, >>> >>> This is a 10-day working group last call on the current working group >>> document: >>> >>> - An NETCONF- and NETMOD-based Architecture for Network Management >>> http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-03.txt >>> >>> This WGLC will end on March 10, 2010. Please review the document and post >>> your comments on the mailing list. >> >> Hi, >> >> The Last Call ends today. Please get your comments in, even if it's >> just to say "I've read it and it's fine". > > I assume there is going to be another LC since we already have a new > version in place - or how do you plan to deal with that? > > /js > From lhotka@cesnet.cz Thu Mar 25 11:10: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 03F403A6967; Thu, 25 Mar 2010 11:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.08 X-Spam-Level: *** X-Spam-Status: No, score=3.08 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=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 VexP7jBytA2E; Thu, 25 Mar 2010 11:10:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5B3B63A68D1; Thu, 25 Mar 2010 11:10:22 -0700 (PDT) Received: from [130.129.29.167] (dhcp-wireless-open-abg-29-167.meeting.ietf.org [130.129.29.167]) by office2.cesnet.cz (Postfix) with ESMTPSA id 601112CDE05A; Thu, 25 Mar 2010 19:10:42 +0100 (CET) From: Ladislav Lhotka To: NETCONF WG , NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 25 Mar 2010 11:09:36 -0700 Message-ID: <1269540576.1965.79.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] notes from informal meeting 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, 25 Mar 2010 18:10:34 -0000 Hi, here are my cursory notes from the informal NETCONF/NETMOD meeting on Tuesday. I'd like to ask other participants to add other points/views that I may have missed. Issue #1: base 1.1 capability ----------------------------- No consensus was reached, but 4741bis must say what each NETCONF party is supposed to do with the hello message. Four possible solutions were suggested: 1. Both server and client may advertize 1.1 capability in addition to 1.0, and they have to negotiate the version to be used in the session. XML elements in PDUs are in any case in 1.0 namespace. 2. Advertize only 1.0 and define a new RPC that allows to turn 1.1 features on (en block or one by one). 3. Add subelement to . 4. Treat 1.0 and 1.1 as two independent versions of the protocol (with XML elements in different namespaces). Both parties may advertize either version or both. If the request uses namespace X, response must be compliant to version X and use namespace X as well. Issue #2: capabilities versus YANG features ------------------------------------------- A consensus was reached (I hope) that capabilities for optional functions will be considered pre-YANG legacy. New versions of the existing capabilities should be defined as features in YANG modules. Notification "capability-changed" should be defined in system.yang. Issue #3: access control ------------------------ I am not aware of any conclusions concerning this issue above those of the official meeting. Issue #4: initial work on YANG modules -------------------------------------- Two goals should be pursued: 1. Create modules that everybody needs - system.yang, interfaces.yang and device.yang. 2. Create higher-level modules for demonstrating the power of YANG. Few alternatives were discussed: - OSPF, both device view and network view - VPNs/VLANs - metro network - stateless firewall Cheers, Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Mar 25 13:49: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 72BC73A6A92; Thu, 25 Mar 2010 13:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.591 X-Spam-Level: * X-Spam-Status: No, score=1.591 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 8SMxU2BESlO6; Thu, 25 Mar 2010 13:49:42 -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 DF6F93A6895; Thu, 25 Mar 2010 13:49:40 -0700 (PDT) Received: from localhost (207.88.181.2.ptr.us.xo.net [207.88.181.2]) by mail.tail-f.com (Postfix) with ESMTPSA id D306F616004; Thu, 25 Mar 2010 21:50:00 +0100 (CET) Date: Thu, 25 Mar 2010 13:49:58 -0700 (PDT) Message-Id: <20100325.134958.152022203.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1269540576.1965.79.camel@nomad> References: <1269540576.1965.79.camel@nomad> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] notes from informal meeting 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, 25 Mar 2010 20:49:43 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > here are my cursory notes from the informal NETCONF/NETMOD meeting on > Tuesday. I'd like to ask other participants to add other points/views > that I may have missed. > > Issue #1: base 1.1 capability > ----------------------------- > > No consensus was reached, but 4741bis must say what each NETCONF party > is supposed to do with the hello message. > > Four possible solutions were suggested: > > 1. Both server and client may advertize 1.1 capability in addition to > 1.0, and they have to negotiate the version to be used in the session. > XML elements in PDUs are in any case in 1.0 namespace. > > 2. Advertize only 1.0 and define a new RPC that allows to turn 1.1 > features on (en block or one by one). > > 3. Add subelement to . > > 4. Treat 1.0 and 1.1 as two independent versions of the protocol (with > XML elements in different namespaces). Both parties may advertize either > version or both. If the request uses namespace X, response must be > compliant to version X and use namespace X as well. I'd like to add to this that version negotiation only becomes an issue if the server behaves differently in 1.1 as compared to 1.0. In the current proposal, there is one such difference, and that is how capability changes are handled. An alternative solution is to avoid version negotiation by solving the capability change problem in a different way. Phil did not like the current proposal (server MUST send capability-changed error, client MAY resync) since it forces a behavior that some clients want onto even the simplest client. Instead it was suggested that we add a new operation with the base:1.1 capability, which the client can use if it wants the server to inform him about capability changes. If the client uses this operation, the server behaves as we proposed (sends capability-changed error-tag). > Issue #2: capabilities versus YANG features > ------------------------------------------- > > A consensus was reached (I hope) that capabilities for optional > functions will be considered pre-YANG legacy. New versions of the > existing capabilities should be defined as features in YANG modules. IIRC we said that all the capabilities in 4741bis will still be capabilities, including new versions of the old ones. However, we should remove the capability template section, and instead state that YANG modules should be used to add new operations etc. /martin From j.schoenwaelder@jacobs-university.de Thu Mar 25 13:55: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 5B3CF3A6874; Thu, 25 Mar 2010 13:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 bBni41E4oRd8; Thu, 25 Mar 2010 13:55:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5B0543A6358; Thu, 25 Mar 2010 13:55:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 751A0C000A; Thu, 25 Mar 2010 21:56:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8FdJ0Yh1REl2; Thu, 25 Mar 2010 21:56:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C6EBC0002; Thu, 25 Mar 2010 21:56:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5007D10FABDA; Thu, 25 Mar 2010 21:56:03 +0100 (CET) Date: Thu, 25 Mar 2010 21:56:03 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100325205603.GA33071@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" , "netmod@ietf.org" References: <1269540576.1965.79.camel@nomad> <20100325.134958.152022203.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100325.134958.152022203.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] notes from informal meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:55:55 -0000 On Thu, Mar 25, 2010 at 09:49:58PM +0100, Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: > > Hi, > > > > here are my cursory notes from the informal NETCONF/NETMOD meeting on > > Tuesday. I'd like to ask other participants to add other points/views > > that I may have missed. > > > > Issue #1: base 1.1 capability > > ----------------------------- > > > > No consensus was reached, but 4741bis must say what each NETCONF party > > is supposed to do with the hello message. > > > > Four possible solutions were suggested: > > > > 1. Both server and client may advertize 1.1 capability in addition to > > 1.0, and they have to negotiate the version to be used in the session. > > XML elements in PDUs are in any case in 1.0 namespace. > > > > 2. Advertize only 1.0 and define a new RPC that allows to turn 1.1 > > features on (en block or one by one). > > > > 3. Add subelement to . > > > > 4. Treat 1.0 and 1.1 as two independent versions of the protocol (with > > XML elements in different namespaces). Both parties may advertize either > > version or both. If the request uses namespace X, response must be > > compliant to version X and use namespace X as well. > > I'd like to add to this that version negotiation only becomes an issue > if the server behaves differently in 1.1 as compared to 1.0. In the > current proposal, there is one such difference, and that is how > capability changes are handled. Depends on an implementor's interpretation of RFC 4741 I would say. ;-) > An alternative solution is to avoid version negotiation by solving the > capability change problem in a different way. Phil did not like the > current proposal (server MUST send capability-changed error, client > MAY resync) since it forces a behavior that some clients want onto > even the simplest client. Instead it was suggested that we add a new > operation with the base:1.1 capability, which the client can use if it > wants the server to inform him about capability changes. If the > client uses this operation, the server behaves as we proposed (sends > capability-changed error-tag). We should separate these things. Dealing with version information is one thing, whether capability changes always lead to errors or whether this can be enabled/disabled is IMHO a different topic. > > Issue #2: capabilities versus YANG features > > ------------------------------------------- > > > > A consensus was reached (I hope) that capabilities for optional > > functions will be considered pre-YANG legacy. New versions of the > > existing capabilities should be defined as features in YANG modules. > > IIRC we said that all the capabilities in 4741bis will still be > capabilities, including new versions of the old ones. > > However, we should remove the capability template section, and instead > state that YANG modules should be used to add new operations etc. I guess this is engineering reality. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Thu Mar 25 14:06:48 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 B3BC43A699F; Thu, 25 Mar 2010 14:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_64=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 4BOdADZNb-z7; Thu, 25 Mar 2010 14:06:46 -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 C0B403A6B96; Thu, 25 Mar 2010 14:06:44 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NuuGX-0008W9-Pm; Thu, 25 Mar 2010 22:07:03 +0100 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=dhcp-wireless-open-abg-24-67.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NuuGX-0001iO-G7; Thu, 25 Mar 2010 22:06:57 +0100 Message-ID: <4BABD06F.2020307@bwijnen.net> Date: Thu, 25 Mar 2010 14:06:55 -0700 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ladislav Lhotka References: <1269540576.1965.79.camel@nomad> In-Reply-To: <1269540576.1965.79.camel@nomad> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42acefaa733901d16b2c4c5a25a29a2d8 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42acefaa733901d16b2c4c5a25a29a2d8 Cc: NETCONF WG , NETMOD Working Group Subject: Re: [netmod] notes from informal meeting 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, 25 Mar 2010 21:06:49 -0000 Many thanks, Lada! Bert Ladislav Lhotka wrote: > Hi, > > here are my cursory notes from the informal NETCONF/NETMOD meeting on > Tuesday. I'd like to ask other participants to add other points/views > that I may have missed. > > Issue #1: base 1.1 capability > ----------------------------- > > No consensus was reached, but 4741bis must say what each NETCONF party > is supposed to do with the hello message. > > Four possible solutions were suggested: > > 1. Both server and client may advertize 1.1 capability in addition to > 1.0, and they have to negotiate the version to be used in the session. > XML elements in PDUs are in any case in 1.0 namespace. > > 2. Advertize only 1.0 and define a new RPC that allows to turn 1.1 > features on (en block or one by one). > > 3. Add subelement to . > > 4. Treat 1.0 and 1.1 as two independent versions of the protocol (with > XML elements in different namespaces). Both parties may advertize either > version or both. If the request uses namespace X, response must be > compliant to version X and use namespace X as well. > > Issue #2: capabilities versus YANG features > ------------------------------------------- > > A consensus was reached (I hope) that capabilities for optional > functions will be considered pre-YANG legacy. New versions of the > existing capabilities should be defined as features in YANG modules. > > Notification "capability-changed" should be defined in system.yang. > > Issue #3: access control > ------------------------ > > I am not aware of any conclusions concerning this issue above those of > the official meeting. > > Issue #4: initial work on YANG modules > -------------------------------------- > > Two goals should be pursued: > > 1. Create modules that everybody needs - system.yang, interfaces.yang > and device.yang. > > 2. Create higher-level modules for demonstrating the power of YANG. Few > alternatives were discussed: > - OSPF, both device view and network view > - VPNs/VLANs > - metro network > - stateless firewall > > Cheers, Lada > > From andyb@iwl.com Thu Mar 25 15:45: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 A3CE53A68C8 for ; Thu, 25 Mar 2010 15:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[AWL=2.550, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 VL0o6RLy7iaK for ; Thu, 25 Mar 2010 15:45:27 -0700 (PDT) Received: from smtp205.iad.emailsrvr.com (smtp205.iad.emailsrvr.com [207.97.245.205]) by core3.amsl.com (Postfix) with ESMTP id 876BC3A685E for ; Thu, 25 Mar 2010 15:45:27 -0700 (PDT) Received: from relay30.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay30.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id BEE051B40A9; Thu, 25 Mar 2010 18:45:49 -0400 (EDT) Received: by relay30.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 311861B40C5; Thu, 25 Mar 2010 18:45:49 -0400 (EDT) Message-ID: <4BABE79C.2090105@iwl.com> Date: Thu, 25 Mar 2010 15:45:48 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Bjorklund References: <1269540576.1965.79.camel@nomad> <20100325.134958.152022203.mbj@tail-f.com> In-Reply-To: <20100325.134958.152022203.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] notes from informal meeting 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, 25 Mar 2010 22:45:28 -0000 Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: >> Hi, >> >> here are my cursory notes from the informal NETCONF/NETMOD meeting on >> Tuesday. I'd like to ask other participants to add other points/views >> that I may have missed. >> >> Issue #1: base 1.1 capability >> ----------------------------- >> >> No consensus was reached, but 4741bis must say what each NETCONF party >> is supposed to do with the hello message. >> >> Four possible solutions were suggested: >> >> 1. Both server and client may advertize 1.1 capability in addition to >> 1.0, and they have to negotiate the version to be used in the session. >> XML elements in PDUs are in any case in 1.0 namespace. >> >> 2. Advertize only 1.0 and define a new RPC that allows to turn 1.1 >> features on (en block or one by one). >> >> 3. Add subelement to . >> >> 4. Treat 1.0 and 1.1 as two independent versions of the protocol (with >> XML elements in different namespaces). Both parties may advertize either >> version or both. If the request uses namespace X, response must be >> compliant to version X and use namespace X as well. > > I'd like to add to this that version negotiation only becomes an issue > if the server behaves differently in 1.1 as compared to 1.0. In the > current proposal, there is one such difference, and that is how > capability changes are handled. I do not accept the premise that under-specified behavior in RFC 4741 can be constrained in any way in 4741bis, and this is somehow not supposed to affect an old client. We spent hours on this issue at the Juniper interim, and we ended up with the Bonica Principle (remember?) It is OK to make the new version less constrained. It is never OK to make the new version more constrained. This breaks old clients that still think they are using the older version (because they are), and do not know about the new version. I came up with a based solution that works to differentiate 4741 servers from 4741bis servers, and make sure only 4741bis clients get more constrained behavior than before. If the WG doesn't like that solution, then come up with a new one. Please explain why we do not want an easy way to tell server versions apart. > > An alternative solution is to avoid version negotiation by solving the > capability change problem in a different way. Phil did not like the > current proposal (server MUST send capability-changed error, client > MAY resync) since it forces a behavior that some clients want onto > even the simplest client. Instead it was suggested that we add a new > operation with the base:1.1 capability, which the client can use if it > wants the server to inform him about capability changes. If the > client uses this operation, the server behaves as we proposed (sends > capability-changed error-tag). Keep in mind that if the new client does not opt-in, then the server is free to use whatever behavior it wants when a capability changes, including dropping the active sessions. (Using a proposal in which there is no indication to both peers what protocol version is in use.) It seems to me that a 4741bis client would want to have clear behavior, even if it doesn't want to opt-in for capability-changed errors. The protocol will clearly be more operationally robust if both peers know exactly what version of the protocol is being used. That seems obvious to me. Andy > >> Issue #2: capabilities versus YANG features >> ------------------------------------------- >> >> A consensus was reached (I hope) that capabilities for optional >> functions will be considered pre-YANG legacy. New versions of the >> existing capabilities should be defined as features in YANG modules. > > IIRC we said that all the capabilities in 4741bis will still be > capabilities, including new versions of the old ones. > > However, we should remove the capability template section, and instead > state that YANG modules should be used to add new operations etc. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Fri Mar 26 09:21: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 00DC23A6B85; Fri, 26 Mar 2010 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.637 X-Spam-Level: * X-Spam-Status: No, score=1.637 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 ItJoE2qOaYuV; Fri, 26 Mar 2010 09:21:19 -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 919993A6A20; Fri, 26 Mar 2010 09:18:00 -0700 (PDT) Received: from localhost (207.88.181.2.ptr.us.xo.net [207.88.181.2]) by mail.tail-f.com (Postfix) with ESMTPSA id 68644616012; Fri, 26 Mar 2010 17:18:21 +0100 (CET) Date: Fri, 26 Mar 2010 09:18:19 -0700 (PDT) Message-Id: <20100326.091819.104012705.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BABE79C.2090105@iwl.com> References: <1269540576.1965.79.camel@nomad> <20100325.134958.152022203.mbj@tail-f.com> <4BABE79C.2090105@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] notes from informal meeting 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, 26 Mar 2010 16:21:20 -0000 Andy Bierman wrote: > I do not accept the premise that under-specified behavior in > RFC 4741 can be constrained in any way in 4741bis, and this is somehow > not supposed to affect an old client. > > We spent hours on this issue at the Juniper interim, > and we ended up with the Bonica Principle (remember?) > > It is OK to make the new version less constrained. > It is never OK to make the new version more constrained. > This breaks old clients that still think they are using > the older version (because they are), and do not know > about the new version. > > I came up with a based solution that works to differentiate > 4741 servers from 4741bis servers, and make sure only > 4741bis clients get more constrained behavior than before. You are right. I agree with you that the hello-based mechanism is good solution to the version negotiation problem. As part of base:1.1, we can still introduce a new operation to let the client decide how it wants capability changes to behave. (Or should that be part of the client's hello message? Like with-defaults, but from the client. urn:...:base:1.1?capability-change="detect") /martin From andyb@iwl.com Fri Mar 26 13:17:22 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 9AD3F3A680A for ; Fri, 26 Mar 2010 13:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 oRCMi9Zq8hi2 for ; Fri, 26 Mar 2010 13:17:21 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id 1A07E3A67E3 for ; Fri, 26 Mar 2010 13:17:12 -0700 (PDT) Received: from relay22.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id CDB23C083CE for ; Fri, 26 Mar 2010 16:17:35 -0400 (EDT) Received: by relay22.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8E676C0839B for ; Fri, 26 Mar 2010 16:17:35 -0400 (EDT) Message-ID: <4BAD165E.3070907@iwl.com> Date: Fri, 26 Mar 2010 13:17:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. 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 Subject: [netmod] ab comments on draft-linowski-netmod-yang-abstract-02 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, 26 Mar 2010 20:17:22 -0000 Hi, I am interested in this sort of work, but as an Experimental RFC. I don't have any comments on the specific mechanisms, because I do not really agree with the focus and motivation in section 1.2. I like the concept of constraining an instance-identifier (instance-type extension), but not complex types. It is too much like XSD and RelaxNG. My use-case is to create tools that allow Python programmers to work with constructs they understand, which are classes. There could be a 'standard' set of CRUD operations with a mapping to HTTPS/REST, a mapping to NETCONF, etc. Also, I think this should not be done as YANG extension statements, but using a new module type instead. Any YANG keyword is allowed and has the same meaning, except rpc --> def and notification --> event. There should be a 1-way mapping to convert the syntax to YANG. The following is on-the-fly -- not documented yet (sorry). It is just to give an idea of an abstraction layer on top of plain YANG that would address my use case. class YangNode { abstract true; leaf id { public true; type instance-identifier; } def get { input { ... } output { ... } } if-config { def create { input { ... } } def update { input { ... } } def delete { input { ... } } } } class ManagedHardware { parent-class YangNode; abstract true; // not the default // add fault detected notification event fault { ... } if-config { // add config-changed notification event config-changed { ... } } def reset { // adding optional reset method for all managed hw mandatory false; // the default } leaf serial-number { ... } // normal data if-defined reset { leaf last-reset-time { type yang:date-and-time; } } } Andy From andyb@iwl.com Sat Mar 27 10:31:47 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 029EF3A6847 for ; Sat, 27 Mar 2010 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 8SMhsW7aw0Dl for ; Sat, 27 Mar 2010 10:31:46 -0700 (PDT) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by core3.amsl.com (Postfix) with ESMTP id 4C3323A6807 for ; Sat, 27 Mar 2010 10:31:46 -0700 (PDT) Received: from relay22.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 2E7B2C08136 for ; Sat, 27 Mar 2010 13:32:11 -0400 (EDT) Received: by relay22.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0EDB6C080F7 for ; Sat, 27 Mar 2010 13:32:10 -0400 (EDT) Message-ID: <4BAE411A.4050602@iwl.com> Date: Sat, 27 Mar 2010 10:32:10 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. 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 Subject: [netmod] xinclude 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: Sat, 27 Mar 2010 17:31:47 -0000 Hi, Are file representations of NETCONF databases, or YIN representations of YANG modules, allowed to contain the 'xinclude' directive? Does the YANG spec say anywhere? http://www.w3.org/TR/xinclude/ thanks, Andy From mbj@tail-f.com Sun Mar 28 11:46:13 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 12BF13A697C for ; Sun, 28 Mar 2010 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.684 X-Spam-Level: * X-Spam-Status: No, score=1.684 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 RS63JLARcSya for ; Sun, 28 Mar 2010 11:46:12 -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 123703A690E for ; Sun, 28 Mar 2010 11:46:11 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A6D2616006; Sun, 28 Mar 2010 20:46:37 +0200 (CEST) Date: Sun, 28 Mar 2010 20:46:36 +0200 (CEST) Message-Id: <20100328.204636.51603294.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BAE411A.4050602@iwl.com> References: <4BAE411A.4050602@iwl.com> X-Mailer: Mew version 6.2.51 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] xinclude 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, 28 Mar 2010 18:46:13 -0000 Andy Bierman wrote: > Hi, > > Are file representations of NETCONF databases, or YIN representations > of YANG modules, allowed to contain the 'xinclude' directive? > Does the YANG spec say anywhere? The YIN representation cannot contain this attribute, since YIN is just a different syntax for YANG, and no xinclude can occur in YANG. A NETCONF db in general can contain any XML, but if you're using YANG, there is no YANG construct that would allow xinclude, except for anyxml. /martin From lhotka@cesnet.cz Sun Mar 28 22:27: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 E0ABF3A6818 for ; Sun, 28 Mar 2010 22:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 8xexKB-dhSx6 for ; Sun, 28 Mar 2010 22:27:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B289E3A67E1 for ; Sun, 28 Mar 2010 22:26:47 -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 8D4C82CDE059; Mon, 29 Mar 2010 07:27:13 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100328.204636.51603294.mbj@tail-f.com> References: <4BAE411A.4050602@iwl.com> <20100328.204636.51603294.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 29 Mar 2010 07:27:12 +0200 Message-ID: <1269840432.1835.0.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] xinclude 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, 29 Mar 2010 05:27:37 -0000 Martin Bjorklund píše v Ne 28. 03. 2010 v 20:46 +0200: > Andy Bierman wrote: > > Hi, > > > > Are file representations of NETCONF databases, or YIN representations > > of YANG modules, allowed to contain the 'xinclude' directive? > > Does the YANG spec say anywhere? > > The YIN representation cannot contain this attribute, since YIN is > just a different syntax for YANG, and no xinclude can occur in YANG. > > A NETCONF db in general can contain any XML, but if you're using YANG, > there is no YANG construct that would allow xinclude, except for > anyxml. One could define it as an extension, right? Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Tue Mar 30 01:51: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 5ED513A69BE for ; Tue, 30 Mar 2010 01:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Kf4ysliPSNro for ; Tue, 30 Mar 2010 01:51:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id ACBA23A69D5 for ; Tue, 30 Mar 2010 01:51:04 -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 369A42CDE05C for ; Tue, 30 Mar 2010 10:51:32 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 30 Mar 2010 10:51:31 +0200 Message-ID: <1269939091.9310.18.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] element order in augmented rpc 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, 30 Mar 2010 08:51:07 -0000 Hi, sec. 7.15.2 of the YANG draft says: When a node is augmented, the augmenting child nodes are encoded as subelements to the augmented node, in any order. I wonder if this is the intended behaviour for augmented RPCs. In the specific example of ietf-netconf-with-defaults, this would mean that could precede in . Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From remi.scavenius@wanadoo.fr Wed Mar 31 00:22:00 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 E2BD93A6922; Wed, 31 Mar 2010 00:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.125 X-Spam-Level: *** X-Spam-Status: No, score=3.125 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_NJABL_PROXY=1.643, STOX_REPLY_TYPE=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 LehLygKibKIm; Wed, 31 Mar 2010 00:21:58 -0700 (PDT) Received: from smtp2e.orange.fr (smtp2e.orange.fr [80.12.242.111]) by core3.amsl.com (Postfix) with ESMTP id D93803A6978; Wed, 31 Mar 2010 00:21:55 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2e01.orange.fr (SMTP Server) with ESMTP id 32DB48000BE8; Wed, 31 Mar 2010 09:22:15 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2e01.orange.fr (SMTP Server) with ESMTP id 24C588000CE5; Wed, 31 Mar 2010 09:22:15 +0200 (CEST) Received: from PCdeMonOrdina (ABordeaux-205-1-3-42.w80-15.abo.wanadoo.fr [80.15.32.42]) by mwinf2e01.orange.fr (SMTP Server) with SMTP id 857F380001F6; Wed, 31 Mar 2010 09:22:14 +0200 (CEST) X-ME-UUID: 20100331072214546.857F380001F6@mwinf2e01.orange.fr Message-ID: <66DE2F0F89DB41E7A0CEFF192D6EA950@PCdeMonOrdina> From: "Remi Scavenius" To: , "Martin Bjorklund" References: <1269540576.1965.79.camel@nomad> <20100325.134958.152022203.mbj@tail-f.com> In-Reply-To: <20100325.134958.152022203.mbj@tail-f.com> Date: Wed, 31 Mar 2010 09:22:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] notes from informal meeting 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, 31 Mar 2010 07:22:01 -0000 Hello, The Network Automation conference programme (Paris, une 01/03) is online at: http://www.upperside.fr/networkautomation2010/networkautomation2010program.htm Remi Scavenius, agenda manager From kwatsen@juniper.net Wed Mar 31 19:14:24 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 E50DF3A6890 for ; Wed, 31 Mar 2010 19:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.155 X-Spam-Level: X-Spam-Status: No, score=-5.155 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 bx5jHzR+l1xO for ; Wed, 31 Mar 2010 19:14:23 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id BCDEB3A6835 for ; Wed, 31 Mar 2010 19:14:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS7QBndGgV6ZfQz4EtVWdxNl5VIsheLmu@postini.com; Wed, 31 Mar 2010 19:14:54 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 31 Mar 2010 19:13:40 -0700 From: Kent Watsen To: "'netmod@ietf.org'" Date: Wed, 31 Mar 2010 19:13:40 -0700 Thread-Topic: comments on draft-ietf-netmod-yang-11 Thread-Index: AcrRQPHLMGlszDTMSGacoyLYwiBpLQ== Message-ID: <84600D05C20FF943918238042D7670FD368B467DE7@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netmod] comments on draft-ietf-netmod-yang-11 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, 01 Apr 2010 02:14:24 -0000 Two concerns: 1. In section 5.6.4, why is the module-parameter included in the capability= -string? My understanding is that each module has a unique namespace, so i= s listing its name in the capability string really needed? In many examples= it seems redundant (e.g. http://example.com/syslog?module=3Dsyslog) 2. Section 6.3.1 says YANG compilers MAY ignore unknown extensions. This b= ehavior may not be OK in all cases. Can the modeler be provided syntax to = indicate if it's OK to ignore an extension? And a few editorial comments: 5.6.4.[2-3]: (both) - example missing revision=3D in capability string 6.1.3.1: - would be good if the "first line\n" + " second line" examples could be indented similarly - also, it's not clear if there should be 2 or 3 spaces in the second example. The text says "up to the column of the double quote character". The example has 2 spaces, but I'd rather not leave it to an example. How about=20 using XSD's "token" type as an example? Token: "A string that does not contain line feeds, carriage returns, tabs, leading or trailing spaces, or multiple spaces" Thanks, Kent