From mbj@tail-f.com Thu Apr 1 00:56: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 19D8F3A699C for ; Thu, 1 Apr 2010 00:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=-1.236, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=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 GqgIZvApTynQ for ; Thu, 1 Apr 2010 00:56:11 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B75323A677E for ; Thu, 1 Apr 2010 00:56:10 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4AD2261600F; Thu, 1 Apr 2010 09:56:42 +0200 (CEST) Date: Thu, 01 Apr 2010 09:56:41 +0200 (CEST) Message-Id: <20100401.095641.61086989.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD368B467DE7@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD368B467DE7@EMBX01-HQ.jnpr.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] 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 07:56:12 -0000 Hi Kent, Kent Watsen wrote: > > 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 is listing its name in the capability string really needed? In > many examples it seems redundant (e.g. http://example.com/syslog?module=syslog) If you specify a deviation, you specify it with the module name: http://example.com/syslog?module=syslog&deviations=my-devs In this case 'my-devs' is the name of the module with the deviations. Since the module name is specified in the capability string, the client can find out which module/namespace/revision it refers to. > 2. Section 6.3.1 says YANG compilers MAY ignore unknown extensions. This > behavior may not be OK in all cases. Can the modeler be provided syntax to > indicate if it's OK to ignore an extension? No. This would be something like "must-understand true;". Such a statement would be useful if the extension changed the semantics of existing statements. But I don't think we want to allow that. The YANG statements have their meaning, and compliant implementations must follow this. > And a few editorial comments: > > 5.6.4.[2-3]: (both) > - example missing revision= in capability string Well, the revision statement is optional, so it is strictly speaking not a bug. Also, it makes the example easier to read... > 6.1.3.1: > - would be good if the "first line\n" + " second line" > examples could be indented similarly The point is that regardless of indentation, these strings are equal. > - 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". How about "up to and including the column of the double quote character"? > The example has 2 spaces, > but I'd rather not leave it to an example. How about > 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" I'm not sure I understand how that relates to this? These two strings are equal in YANG: "foo bar" 'foo bar' An xsd:token interpretation of the first of these is 'foo bar'. /martin From j.schoenwaelder@jacobs-university.de Thu Apr 1 01:10:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551AF3A6A4B for ; Thu, 1 Apr 2010 01:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=0.316, 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 mpuk3ihgW8aV for ; Thu, 1 Apr 2010 01:10:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4BED13A6A4A for ; Thu, 1 Apr 2010 01:10:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15526C0006; Thu, 1 Apr 2010 10:11:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4sJrkD63YwVt; Thu, 1 Apr 2010 10:11:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93011C0016; Thu, 1 Apr 2010 10:11:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D1B2112F886; Thu, 1 Apr 2010 10:11:07 +0200 (CEST) Date: Thu, 1 Apr 2010 10:11:07 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20100401081107.GA59636@elstar.local> Mail-Followup-To: Kent Watsen , "'netmod@ietf.org'" References: <84600D05C20FF943918238042D7670FD368B467DE7@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD368B467DE7@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "'netmod@ietf.org'" Subject: Re: [netmod] comments on draft-ietf-netmod-yang-11 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, 01 Apr 2010 08:10:49 -0000 On Thu, Apr 01, 2010 at 04:13:40AM +0200, Kent Watsen wrote: > > 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 is listing its name in the capability string really needed? In many examples it seems redundant (e.g. http://example.com/syslog?module=syslog) One reason is that the module-parameter tells you unambiguously what the module name is; guessing the modulename by picking something out of the namespace URI can lead to errors are requires that we define CLRs how the namespace URI is formed. > 2. Section 6.3.1 says YANG compilers MAY ignore unknown extensions. This behavior may not be OK in all cases. Can the modeler be provided syntax to indicate if it's OK to ignore an extension? I think this was discussed in the past and we concluded that extensions that change the semantics of the core of the language are bad for interoperability. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Thu Apr 1 12:31:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3416C3A6A7D for ; Thu, 1 Apr 2010 12:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_35=0.6, 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 HynffsCNWAxa for ; Thu, 1 Apr 2010 12:31:31 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 1B0483A6836 for ; Thu, 1 Apr 2010 12:31:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS7T0o7uC8trHLBLD83UutYuA36geDFVM@postini.com; Thu, 01 Apr 2010 12:31:52 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; Thu, 1 Apr 2010 12:28:52 -0700 From: Kent Watsen To: 'Martin Bjorklund' Date: Thu, 1 Apr 2010 12:28:51 -0700 Thread-Topic: [netmod] comments on draft-ietf-netmod-yang-11 Thread-Index: AcrRcN9RU6yud87BTYK9CLIrhB/O7wAURpeQ Message-ID: <84600D05C20FF943918238042D7670FD368B467DF1@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD368B467DE7@EMBX01-HQ.jnpr.net> <20100401.095641.61086989.mbj@tail-f.com> In-Reply-To: <20100401.095641.61086989.mbj@tail-f.com> 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 Cc: "netmod@ietf.org" Subject: Re: [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 19:31:32 -0000 > If you specify a deviation, you specify it with the module name: >=20 > http://example.com/syslog?module=3Dsyslog&deviations=3Dmy-devs >=20 > In this case 'my-devs' is the name of the module with the deviations. > Since the module name is specified in the capability string, the > client can find out which module/namespace/revision it refers to. I see, good point. =20 > This would be something like "must-understand true;". >=20 > Such a statement would be useful if the extension changed the > semantics of existing statements. But I don't think we want to allow > that. The YANG statements have their meaning, and compliant > implementations must follow this. Right, features are always additive. It's the deviations that can modify p= reviously defined behavior and deviations are ignore-at-your-own-risk, so t= hat works out... > > And a few editorial comments: > > > > 5.6.4.[2-3]: (both) > > - example missing revision=3D in capability string >=20 > Well, the revision statement is optional, so it is strictly speaking > not a bug. Also, it makes the example easier to read... Then perhaps the statement in 5.6.4.1 is wrong? "A server MUST advertise al= l revisions of all modules it implements" > > 6.1.3.1: > > - would be good if the "first line\n" + " second line" > > examples could be indented similarly >=20 > The point is that regardless of indentation, these strings are equal. That was on purpose? - wow, you might want to make that more clear... > > - 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". >=20 > How about "up to and including the column of the double quote > character"? Yup, that resolves it, thanks > > The example has 2 spaces, > > but I'd rather not leave it to an example. How about > > 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" >=20 > I'm not sure I understand how that relates to this? These two strings > are equal in YANG: >=20 > "foo bar" > 'foo bar' >=20 > An xsd:token interpretation of the first of these is 'foo bar'. I see, you want to preserve internal whitespace as well, which is a good. S= o for instance: description "paragraph1 paragraph2 * bullet1 * sub-bullet1 * sub-bullet2 * bullet2 "; Would preserve the layout. Cool. Thanks, Kent From bertietf@bwijnen.net Tue Apr 6 08:33: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 40F923A6808 for ; Tue, 6 Apr 2010 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqHkWnlHsRNY for ; Tue, 6 Apr 2010 08:33:33 -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 01CA43A677E for ; Tue, 6 Apr 2010 08:33:32 -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 1NzAmJ-0007xP-9k for netmod@ietf.org; Tue, 06 Apr 2010 17:33:28 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NzAmJ-00046c-4T for netmod@ietf.org; Tue, 06 Apr 2010 17:33:23 +0200 Message-ID: <4BBB5442.5030206@bwijnen.net> Date: Tue, 06 Apr 2010 17:33:22 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4052440b35c54c9f8cd5046f98298bcda X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4052440b35c54c9f8cd5046f98298bcda Subject: [netmod] [Fwd: Re: [Fwd: 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, 06 Apr 2010 15:33:34 -0000 I asked Martin for some suggested text w.r.t. security considerations for RPX. Below is what he has suggested. I think it is best if we have this discussion on this mailing list. Bert -------- Original Message -------- Subject: Re: [Fwd: first draft for yang module security considerations] Date: Tue, 06 Apr 2010 14:59:29 +0200 (CEST) From: Martin Bjorklund To: bertietf@bwijnen.net CC: andyb@iwl.com References: <4BBB1041.1080402@bwijnen.net> Hi, [Cc:ing Andy as well, since this somewhat touches the nacm work] "Bert (IETF) Wijnen" wrote: > MArtin, you had some remarks about the need to say something > about RPC and/or operations? Can you suggest text and the location where > to put it? Yes, I think we need to mention rpc as well: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: > -- 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: > > I wonder if it is correct to treat notifications like this. The problem is that the text seems to suggest that if one of the nodes in a notification is sensitive, it should be listed. This, in turn, seems to imply that an access control solution for NETCONF should be able to filter on nodes in notification content. The NACM draft by Andy (which I agree with) does not support this level of detail. /martin From andyb@iwl.com Tue Apr 6 09:24:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69DC3A6811 for ; Tue, 6 Apr 2010 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=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 DEKJyYpTI323 for ; Tue, 6 Apr 2010 09:24:31 -0700 (PDT) Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com [67.192.241.205]) by core3.amsl.com (Postfix) with ESMTP id 2C1FF3A69B6 for ; Tue, 6 Apr 2010 09:24:23 -0700 (PDT) Received: from relay20.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay20.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BDABD21290DB; Tue, 6 Apr 2010 12:24:20 -0400 (EDT) Received: by relay20.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A09262128341; Tue, 6 Apr 2010 12:24:18 -0400 (EDT) Message-ID: <4BBB604F.7090702@iwl.com> Date: Tue, 06 Apr 2010 09:24:47 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <4BBB5442.5030206@bwijnen.net> In-Reply-To: <4BBB5442.5030206@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] [Fwd: Re: [Fwd: first draft for yang module security considerations]] 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, 06 Apr 2010 16:24:32 -0000 Bert (IETF) Wijnen wrote: > I asked Martin for some suggested text w.r.t. security considerations > for RPX. Below is what he has suggested. I think it is best if we > have this discussion on this mailing list. > > Bert > > -------- Original Message -------- > Subject: Re: [Fwd: first draft for yang module security considerations] > Date: Tue, 06 Apr 2010 14:59:29 +0200 (CEST) > From: Martin Bjorklund > To: bertietf@bwijnen.net > CC: andyb@iwl.com > References: <4BBB1041.1080402@bwijnen.net> > > > > Hi, > > [Cc:ing Andy as well, since this somewhat touches the nacm work] > > "Bert (IETF) Wijnen" wrote: >> MArtin, you had some remarks about the need to say something >> about RPC and/or operations? Can you suggest text and the location where >> to put it? > > Yes, I think we need to mention rpc as well: > > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. > This is especially important since NETCONF supports arbitrary actions like 'rebooot', that have obvious DoS issues. > Some of the RPC operations in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control access to these operations. These are the > operations and their sensitivity/vulnerability: > > >> -- 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: >> >> > > I wonder if it is correct to treat notifications like this. The > problem is that the text seems to suggest that if one of the nodes in > a notification is sensitive, it should be listed. This, in turn, > seems to imply that an access control solution for NETCONF should be > able to filter on nodes in notification content. The NACM draft by > Andy (which I agree with) does not support this level of detail. > IMO, the current security considerations are still relevant. An author should list 'newval' as a security risk (see below). That doesn't mean NACM must support subtree pruning though. Part of the concern is that enforcing detailed access control for read operations is too expensive, and slows down the server. Then there is the assumption that operators actually want to configure detailed access control rules for notification content. A data model designer should be careful about defining notification payloads that are 'risky', like Sharon's early 'config-change' notifications that included all the config values that were affected (not just a name in an instance-identifier). The WG needs to decide if the server MUST, SHOULD, MAY provide configurable access control mechanisms for arbitrary sub-trees within NETCONF messages, and what that really means. For example, the nacm:secure extension theoretically could apply to notification nodes: notification create-event { description "Dumb config-change for create event"; leaf username { description "User who made the config change."; type string; } leaf node { description "Node that was created."; type instance-identifier; } anyxml newval { nacm:secure; description "The new value node"; } } But this would require the server to support data-rules for notification content, so some behavior other than the default could ever be achieved. IMO, it is OK if NACM requires the operator to secure the entire 'event-type' message, and not prune-to-order ACLs. > > > /martin Andy From bertietf@bwijnen.net Fri Apr 9 00:49:56 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 D10053A69CF for ; Fri, 9 Apr 2010 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, J_CHICKENPOX_46=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 N1fgmNKidxZF for ; Fri, 9 Apr 2010 00:49:56 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id A27223A69CA for ; Fri, 9 Apr 2010 00:49:51 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O08yC-0001cW-KO; Fri, 09 Apr 2010 09:49:46 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-43.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O08yC-0006Da-FJ; Fri, 09 Apr 2010 09:49:40 +0200 Message-ID: <4BBEDC14.7020404@bwijnen.net> Date: Fri, 09 Apr 2010 09:49:40 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: andyb@iwl.com References: <4BBB5442.5030206@bwijnen.net> <4BBB604F.7090702@iwl.com> In-Reply-To: <4BBB604F.7090702@iwl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44d80ca725dcd128fd6b2fce3705041f2 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd44d80ca725dcd128fd6b2fce3705041f2 Cc: NETMOD Working Group Subject: Re: [netmod] [Fwd: Re: [Fwd: 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: Fri, 09 Apr 2010 07:49:56 -0000 I agree with Andy here in that it IS important to list the vulnerabilities/privacy issues for anobject that could be read/seen via a notification. The fact that such is listed does not mean that NACM MUST provide a mechanism to filter out one (or some) specific nodes/objects from a notification. If the WG decides that in such a case the wholenotification must not be sent, that is up to the WG. Martin, thanks for the input. I my next posting I will send a renewed complete security considerations template. Bert Andy Bierman wrote: > Bert (IETF) Wijnen wrote: > >> I asked Martin for some suggested text w.r.t. security considerations >> for RPX. Below is what he has suggested. I think it is best if we >> have this discussion on this mailing list. >> >> Bert >> >> -------- Original Message -------- >> Subject: Re: [Fwd: first draft for yang module security considerations] >> Date: Tue, 06 Apr 2010 14:59:29 +0200 (CEST) >> From: Martin Bjorklund >> To: bertietf@bwijnen.net >> CC: andyb@iwl.com >> References: <4BBB1041.1080402@bwijnen.net> >> >> >> >> Hi, >> >> [Cc:ing Andy as well, since this somewhat touches the nacm work] >> >> "Bert (IETF) Wijnen" wrote: >> >>> MArtin, you had some remarks about the need to say something >>> about RPC and/or operations? Can you suggest text and the location where >>> to put it? >>> >> Yes, I think we need to mention rpc as well: >> >> -- if your YANG module has defined any rpc operations >> -- describe their specific sensitivity or vulnerability. >> >> > > This is especially important since NETCONF supports arbitrary > actions like 'rebooot', that have obvious DoS issues. > > > >> Some of the RPC operations in this YANG module may be considered >> sensitive or vulnerable in some network environments. It is thus >> important to control access to these operations. These are the >> operations and their sensitivity/vulnerability: >> >> >> >>> -- 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: >>> >>> >>> >> I wonder if it is correct to treat notifications like this. The >> problem is that the text seems to suggest that if one of the nodes in >> a notification is sensitive, it should be listed. This, in turn, >> seems to imply that an access control solution for NETCONF should be >> able to filter on nodes in notification content. The NACM draft by >> Andy (which I agree with) does not support this level of detail. >> >> > > > > IMO, the current security considerations are still relevant. > An author should list 'newval' as a security risk (see below). > That doesn't mean NACM must support subtree pruning though. > > Part of the concern is that enforcing detailed access control > for read operations is too expensive, and slows down the server. > Then there is the assumption that operators actually > want to configure detailed access control rules for notification content. > > A data model designer should be careful about defining > notification payloads that are 'risky', like Sharon's > early 'config-change' notifications that included all the config > values that were affected (not just a name in an instance-identifier). > > The WG needs to decide if the server MUST, SHOULD, MAY provide > configurable access control mechanisms for arbitrary sub-trees > within NETCONF messages, and what that really means. > > For example, the nacm:secure extension theoretically could > apply to notification nodes: > > notification create-event { > description "Dumb config-change for create event"; > > leaf username { > description "User who made the config change."; > type string; > } > leaf node { > description "Node that was created."; > type instance-identifier; > } > anyxml newval { > nacm:secure; > description "The new value node"; > } > } > > > But this would require the server to support data-rules for > notification content, so some behavior other than the > default could ever be achieved. > > IMO, it is OK if NACM requires the operator to secure > the entire 'event-type' message, and not prune-to-order ACLs. > > > >> /martin >> > > Andy > > From bertietf@bwijnen.net Fri Apr 9 00:54: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 B48573A67FB for ; Fri, 9 Apr 2010 00:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HuvWPQgG5Et for ; Fri, 9 Apr 2010 00:54:45 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 797A63A67EB for ; Fri, 9 Apr 2010 00:54:45 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O092x-0001iL-8w for netmod@ietf.org; Fri, 09 Apr 2010 09:54:40 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-43.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O092x-0004co-5z for netmod@ietf.org; Fri, 09 Apr 2010 09:54:35 +0200 Message-ID: <4BBEDD3B.90902@bwijnen.net> Date: Fri, 09 Apr 2010 09:54:35 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: NETMOD Working Group References: <4BA91F64.70801@bwijnen.net> In-Reply-To: <4BA91F64.70801@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42f47057261f58c4532831682f35494a6 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd42f47057261f58c4532831682f35494a6 Subject: [netmod] second 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: Fri, 09 Apr 2010 07:54:46 -0000 WG chairs, are we ready for a WG LC on this? Thanks for comments and review sofar. The first part (that follows here) is text that I have modified based on text from the YANG usage draft. Maybe ANdy can look at that and see if it should be changed accordingly in that draft as well. It can also be used as a preface on the web page (URL TBD) that we will setup for this. Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable 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. Further, if new RPC operations have been defined, then it the security considerations of each new RPC operation MUST be explained. And the following is the template: 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: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: Bert From lhotka@cesnet.cz Fri Apr 9 01:44: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 483DE3A697B for ; Fri, 9 Apr 2010 01:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 SVSDFElrJyG3 for ; Fri, 9 Apr 2010 01:44:46 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 6B5EF3A6891 for ; Fri, 9 Apr 2010 01:44:45 -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 14EA92CDE05B for ; Fri, 9 Apr 2010 10:44:41 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <201003161108.38711.david.partain@ericsson.com> References: <201003161108.38711.david.partain@ericsson.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 09 Apr 2010 10:44:40 +0200 Message-ID: <1270802680.6878.13.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [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: Fri, 09 Apr 2010 08:44:47 -0000 Hi, this WGLC is over but I haven't received any comments (yet). I also asked folks on the dsdl-comment mailing list for reviewing the document, and specifically Jirka Kosek, who is a renowned XML guru and already provided some input. I hope to get at least some comments from them, but these will certainly be oriented on the XML & DSDL side of the work. So what shall we do now? I have a few pending (non-critical) fixes that should go into the next revision of the draft - does it make sense to do it anytime soon? Thanks, Lada David Partain píše v Út 16. 03. 2010 v 11:08 +0100: > 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!) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Apr 9 13:04:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D593B3A69BC for ; Fri, 9 Apr 2010 13:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQVDD-59Iwe3 for ; Fri, 9 Apr 2010 13:04:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 007E23A699F for ; Fri, 9 Apr 2010 13:04:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 028AAC000D; Fri, 9 Apr 2010 22:04:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Trp-freY8uPJ; Fri, 9 Apr 2010 22:04:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 512B7C0007; Fri, 9 Apr 2010 22:04:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 33D37117AA68; Fri, 9 Apr 2010 22:04:22 +0200 (CEST) Date: Fri, 9 Apr 2010 22:04:22 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100409200422.GA6303@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , NETMOD Working Group References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBEDD3B.90902@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] second draft for yang module security considerations 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, 09 Apr 2010 20:04:32 -0000 On Fri, Apr 09, 2010 at 09:54:35AM +0200, Bert (IETF) Wijnen wrote: > The first part (that follows here) is text that I have modified based on > text > from the YANG usage draft. Maybe ANdy can look at that and see if it > should be changed accordingly in that draft as well. > It can also be used as a preface on the web page (URL TBD) that > we will setup for this. > > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). > > In particular, writable 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. > > Further, if new RPC operations have been defined, > then it the security considerations of each new > RPC operation MUST be explained. Not sure what "module objects" are - I think we should stick to YANG terminology and s/module objects/data nodes/ above > And the following is the template: > > 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: > > > > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. > > Some of the RPC operations in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control access to these operations. These are the > operations and their sensitivity/vulnerability: > > Seems to be a reasonable template. /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 Fri Apr 9 13:07:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B032C3A6999 for ; Fri, 9 Apr 2010 13:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Wd0YYfcuqkgA for ; Fri, 9 Apr 2010 13:07:31 -0700 (PDT) Received: from smtp185.dfw.emailsrvr.com (smtp185.dfw.emailsrvr.com [67.192.241.185]) by core3.amsl.com (Postfix) with ESMTP id 26FCB3A6941 for ; Fri, 9 Apr 2010 13:07:31 -0700 (PDT) Received: from relay8.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 3B75D40314; Fri, 9 Apr 2010 16:07:27 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id DFE034002B; Fri, 9 Apr 2010 16:07:26 -0400 (EDT) Message-ID: <4BBF88E7.1050207@iwl.com> Date: Fri, 09 Apr 2010 13:07:03 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , NETMOD Working Group References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> <20100409200422.GA6303@elstar.local> In-Reply-To: <20100409200422.GA6303@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] second draft for yang module security considerations 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, 09 Apr 2010 20:07:32 -0000 Juergen Schoenwaelder wrote: > On Fri, Apr 09, 2010 at 09:54:35AM +0200, Bert (IETF) Wijnen wrote: > >> The first part (that follows here) is text that I have modified based on >> text >> from the YANG usage draft. Maybe ANdy can look at that and see if it >> should be changed accordingly in that draft as well. >> It can also be used as a preface on the web page (URL TBD) that >> we will setup for this. >> >> Each specification that defines one or more YANG >> modules MUST contain a section that discusses >> security considerations relevant to those modules. >> This section MUST be patterned after the latest >> approved template (available at [ed: URL TBD]). >> >> In particular, writable 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. >> >> Further, if new RPC operations have been defined, >> then it the security considerations of each new >> RPC operation MUST be explained. > > Not sure what "module objects" are - I think we should stick > to YANG terminology and s/module objects/data nodes/ above > >> And the following is the template: >> >> 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: >> >> >> >> -- if your YANG module has defined any rpc operations >> -- describe their specific sensitivity or vulnerability. >> >> Some of the RPC operations in this YANG module may be considered >> sensitive or vulnerable in some network environments. It is thus >> important to control access to these operations. These are the >> operations and their sensitivity/vulnerability: >> >> > > Seems to be a reasonable template. > +1 I plan to update the YANG usage I-D when the text is finalized. > /js > Andy From bertietf@bwijnen.net Mon Apr 12 00:29:41 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37B43A67B3 for ; Mon, 12 Apr 2010 00:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0hH3ww43Bpn for ; Mon, 12 Apr 2010 00:29:41 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 69A583A68D1 for ; Mon, 12 Apr 2010 00:29:37 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O1E5F-0003PZ-2d for netmod@ietf.org; Mon, 12 Apr 2010 09:29:30 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-43.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O1E5E-0005lA-VN for netmod@ietf.org; Mon, 12 Apr 2010 09:29:25 +0200 Message-ID: <4BC2CBD4.5060601@bwijnen.net> Date: Mon, 12 Apr 2010 09:29:24 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: NETMOD Working Group References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> In-Reply-To: <4BBEDD3B.90902@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e85e3237dc0c9b35b52d1d6657c28592 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e85e3237dc0c9b35b52d1d6657c28592 Subject: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 07:29:42 -0000 Third revision, based on comments from Juergen and a typo reported by Mark. Bert ---- Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then it the security considerations of each new RPC operation MUST be explained. 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 -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: From dromasca@avaya.com Mon Apr 12 03:00: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 2285C3A6963 for ; Mon, 12 Apr 2010 03:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.744, 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 WJjNwmBtGBN3 for ; Mon, 12 Apr 2010 03:00:57 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 4B7933A6885 for ; Mon, 12 Apr 2010 03:00:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,189,1270440000"; d="scan'208";a="213048560" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Apr 2010 06:00:51 -0400 X-IronPort-AV: E=Sophos;i="4.52,189,1270440000"; d="scan'208";a="450688759" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Apr 2010 06:00:51 -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, 12 Apr 2010 12:00:42 +0200 Message-ID: In-Reply-To: <4BC2CBD4.5060601@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcraEercpiJAUwDoRmOUdKMFU8woXAAFB4bA References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> <4BC2CBD4.5060601@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert (IETF) Wijnen" , "NETMOD Working Group" Subject: Re: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 10:00:58 -0000 I apologize for commenting only now, but I was on vacation for the two weeks after Anaheim. I did not yet read all mail and if the issue was already raised please point me to the relevant thread.=20 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. >=20 > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. >=20 It looks to me that the optional mode language used here 'data nodes that could be especially disruptive' and especially the word 'especially' :-) contradict the MUST and allow for the security considerations section to not document nodes that are not considered *especially* disruptive if abused. The practice with MIB objects is I think to document all writeable objects. Do we want to depart from this practice?=20 I am more indulgent concerning readable only nodes.=20 Dan From bertietf@bwijnen.net Mon Apr 12 03:22:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BFC3A6955 for ; Mon, 12 Apr 2010 03:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[AWL=1.004, 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 MRO7jRIQkU6n for ; Mon, 12 Apr 2010 03:22:30 -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 6F12C3A62C1 for ; Mon, 12 Apr 2010 03:21:59 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O1Gm3-0001Jr-8E; Mon, 12 Apr 2010 12:21:52 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-43.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O1Gm3-0003DO-28; Mon, 12 Apr 2010 12:21:47 +0200 Message-ID: <4BC2F43A.1030402@bwijnen.net> Date: Mon, 12 Apr 2010 12:21:46 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> <4BC2CBD4.5060601@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4793e8e5803433a12eea0232518970e3d X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4793e8e5803433a12eea0232518970e3d Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 10:22:32 -0000 Romascanu, Dan (Dan) wrote: > I apologize for commenting only now, but I was on vacation for the two > weeks after Anaheim. I did not yet read all mail and if the issue was > already raised please point me to the relevant thread. > > > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen >> > > >> In particular, writable data nodes that could >> be especially disruptive if abused MUST be >> explicitly listed by name and the associated >> security risks MUST be spelled out. >> >> Similarly, readable data nodes that contain >> especially sensitive information or that raise >> significant privacy concerns MUST be explicitly >> listed by name and the reasons for the >> sensitivity/privacy concerns MUST be explained. >> >> > > It looks to me that the optional mode language used here 'data nodes > that could be especially disruptive' and especially the word > 'especially' :-) contradict the MUST and allow for the security > considerations section to not document nodes that are not considered > *especially* disruptive if abused. The practice with MIB objects is I > think to document all writeable objects. Do we want to depart from this > practice? > > I am more indulgent concerning readable only nodes. > > Dan > > I don't think it was discussed yet. I am OK with taking out the word "especially", and in fact I think it would be good to take it out in both cases. Other opinions or supporting opinions? Bert From dromasca@avaya.com Mon Apr 12 05:15: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 04DFB3A6830 for ; Mon, 12 Apr 2010 05:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.595, 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 ZMLqhEBHgKoj for ; Mon, 12 Apr 2010 05:15:17 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D344D3A6827 for ; Mon, 12 Apr 2010 05:15:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,190,1270440000"; d="scan'208";a="213065088" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Apr 2010 08:15:11 -0400 X-IronPort-AV: E=Sophos;i="4.52,190,1270440000"; d="scan'208";a="463653390" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Apr 2010 08:15:10 -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, 12 Apr 2010 14:14:48 +0200 Message-ID: In-Reply-To: <4BC2F43A.1030402@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcraKfq3D8x9mTQ6SkKlinMG0wmeEQAD0/1g References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> <4BC2CBD4.5060601@bwijnen.net> <4BC2F43A.1030402@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert (IETF) Wijnen" Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 12:15:18 -0000 I would actually prefer to take out all the conditional language from the writeable nodes text.=20 OLD:=20 In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. NEW:=20 In particular, writable data nodes MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain 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. > -----Original Message----- > From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net]=20 > Sent: Monday, April 12, 2010 1:22 PM > To: Romascanu, Dan (Dan) > Cc: NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Romascanu, Dan (Dan) wrote: > > I apologize for commenting only now, but I was on vacation=20 > for the two=20 > > weeks after Anaheim. I did not yet read all mail and if the=20 > issue was=20 > > already raised please point me to the relevant thread. > > > > =20 > > > > =20 > >> -----Original Message----- > >> From: netmod-bounces@ietf.org > >> [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen > >> =20 > > > > =20 > >> In particular, writable data nodes that could > >> be especially disruptive if abused MUST be > >> explicitly listed by name and the associated > >> security risks MUST be spelled out. > >> > >> Similarly, readable data nodes that contain > >> especially sensitive information or that raise > >> significant privacy concerns MUST be explicitly > >> listed by name and the reasons for the > >> sensitivity/privacy concerns MUST be explained. > >> > >> =20 > > > > It looks to me that the optional mode language used here=20 > 'data nodes=20 > > that could be especially disruptive' and especially the word=20 > > 'especially' :-) contradict the MUST and allow for the security=20 > > considerations section to not document nodes that are not considered > > *especially* disruptive if abused. The practice with MIB=20 > objects is I=20 > > think to document all writeable objects. Do we want to depart from=20 > > this practice? > > > > I am more indulgent concerning readable only nodes.=20 > > > > Dan > > > > =20 >=20 > I don't think it was discussed yet. > I am OK with taking out the word "especially", and in fact I=20 > think it would be good to take it out in both cases. >=20 > Other opinions or supporting opinions? >=20 > Bert >=20 >=20 I would actually prefer to take out all the conditional language from the writeable nodes text.=20 OLD:=20 In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. NEW:=20 In particular, writable data nodes MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain 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. Dan From bertietf@bwijnen.net Mon Apr 12 06:13:02 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 CE4E13A69C1 for ; Mon, 12 Apr 2010 06:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.803, 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 SL3A0Px8M46R for ; Mon, 12 Apr 2010 06:13:01 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id EBA053A69A0 for ; Mon, 12 Apr 2010 06:12:58 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O1JRV-0008LD-R3; Mon, 12 Apr 2010 15:12:51 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-43.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O1JRV-0001yy-Li; Mon, 12 Apr 2010 15:12:45 +0200 Message-ID: <4BC31C4D.5050203@bwijnen.net> Date: Mon, 12 Apr 2010 15:12:45 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> <4BC2CBD4.5060601@bwijnen.net> <4BC2F43A.1030402@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46c8fc55dde99f849af1ea65ac6d6e6cb X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46c8fc55dde99f849af1ea65ac6d6e6cb Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:13:02 -0000 Wow.... I thought in the MIB template, we assumed that any objects that are not mentioned are not vulnerable. Your approachof course make it easier, for reviewers at least, because they would have to list all data nodes, and for the ones that do not have any security risks, they would need to say: security risk abcd no vulenrability risk, but sensitive for privacy because of defg no security or privacy risks or some such That is sort of fine with me... but I am sure others may have different opinions Bert Romascanu, Dan (Dan) wrote: > I would actually prefer to take out all the conditional language from > the writeable nodes text. > > OLD: > > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. > > NEW: > > In particular, writable data nodes MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > 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. > > >> -----Original Message----- >> From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net] >> Sent: Monday, April 12, 2010 1:22 PM >> To: Romascanu, Dan (Dan) >> Cc: NETMOD Working Group >> Subject: Re: [netmod] third draft for yang module security >> considerations >> >> Romascanu, Dan (Dan) wrote: >> >>> I apologize for commenting only now, but I was on vacation >>> >> for the two >> >>> weeks after Anaheim. I did not yet read all mail and if the >>> >> issue was >> >>> already raised please point me to the relevant thread. >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: netmod-bounces@ietf.org >>>> [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen >>>> >>>> >>> >>> >>>> In particular, writable data nodes that could >>>> be especially disruptive if abused MUST be >>>> explicitly listed by name and the associated >>>> security risks MUST be spelled out. >>>> >>>> Similarly, readable data nodes that contain >>>> especially sensitive information or that raise >>>> significant privacy concerns MUST be explicitly >>>> listed by name and the reasons for the >>>> sensitivity/privacy concerns MUST be explained. >>>> >>>> >>>> >>> It looks to me that the optional mode language used here >>> >> 'data nodes >> >>> that could be especially disruptive' and especially the word >>> 'especially' :-) contradict the MUST and allow for the security >>> considerations section to not document nodes that are not considered >>> *especially* disruptive if abused. The practice with MIB >>> >> objects is I >> >>> think to document all writeable objects. Do we want to depart from >>> this practice? >>> >>> I am more indulgent concerning readable only nodes. >>> >>> Dan >>> >>> >>> >> I don't think it was discussed yet. >> I am OK with taking out the word "especially", and in fact I >> think it would be good to take it out in both cases. >> >> Other opinions or supporting opinions? >> >> Bert >> >> >> > > I would actually prefer to take out all the conditional language from > the writeable nodes text. > > OLD: > > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. > > NEW: > > In particular, writable data nodes MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > 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. > > Dan > > From dromasca@avaya.com Mon Apr 12 06:23: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 45AD83A67E2 for ; Mon, 12 Apr 2010 06:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, 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 N4hvZtwcvRuK for ; Mon, 12 Apr 2010 06:23:41 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 60F7B3A6A43 for ; Mon, 12 Apr 2010 06:23:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,190,1270440000"; d="scan'208";a="183905309" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Apr 2010 09:23:33 -0400 X-IronPort-AV: E=Sophos;i="4.52,190,1270440000"; d="scan'208";a="450749700" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Apr 2010 09:23:31 -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, 12 Apr 2010 15:23:15 +0200 Message-ID: In-Reply-To: <4BC31C4D.5050203@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcraQd1pYtJRIFMpTgqDm2JdzYw7ZgAASgCQ References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net> <4BC2CBD4.5060601@bwijnen.net> <4BC2F43A.1030402@bwijnen.net> <4BC31C4D.5050203@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert (IETF) Wijnen" Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:23:43 -0000 Actually the text in the guidelines for the security considerations in MIB documents does not seem to leave the option to not mention writeable objects. Here is the text. -- if you have any read-write and/or read-create objects, please -- describe their specific sensitivity or vulnerability. -- RFC 2669 has a very good example. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: This text was exactly the reason that triggered my input, because what is now described in the 'third draft' seems to lower the bar.=20 Dan =20 > -----Original Message----- > From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net]=20 > Sent: Monday, April 12, 2010 4:13 PM > To: Romascanu, Dan (Dan) > Cc: NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Wow.... >=20 > I thought in the MIB template, we assumed that any objects=20 > that are not mentioned are not vulnerable. Your approachof=20 > course make it easier, for reviewers at least, because they=20 > would have to list all data nodes, and for the ones that do=20 > not have any security risks, they would need to say: > security risk abcd > no vulenrability risk, but sensitive for=20 > privacy because of defg > no security or privacy risks or some such >=20 > That is sort of fine with me... but I am sure others may have=20 > different opinions >=20 > Bert >=20 > Romascanu, Dan (Dan) wrote: > > I would actually prefer to take out all the conditional=20 > language from=20 > > the writeable nodes text. > > > > OLD:=20 > > > > In particular, writable data nodes that could be especially=20 > disruptive=20 > > if abused MUST be explicitly listed by name and the associated=20 > > security risks MUST be spelled out. > > > > Similarly, readable data nodes that contain especially sensitive=20 > > information or that raise significant privacy concerns MUST be=20 > > explicitly listed by name and the reasons for the=20 > sensitivity/privacy=20 > > concerns MUST be explained. > > > > NEW:=20 > > > > In particular, writable data nodes MUST be explicitly=20 > listed by name=20 > > and the associated security risks MUST be spelled out. > > > > Similarly, readable data nodes that contain sensitive=20 > information or=20 > > that raise significant privacy concerns MUST be explicitly=20 > listed by=20 > > name and the reasons for the sensitivity/privacy concerns MUST be=20 > > explained. > > > > =20 > >> -----Original Message----- > >> From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net] > >> Sent: Monday, April 12, 2010 1:22 PM > >> To: Romascanu, Dan (Dan) > >> Cc: NETMOD Working Group > >> Subject: Re: [netmod] third draft for yang module security=20 > >> considerations > >> > >> Romascanu, Dan (Dan) wrote: > >> =20 > >>> I apologize for commenting only now, but I was on vacation > >>> =20 > >> for the two > >> =20 > >>> weeks after Anaheim. I did not yet read all mail and if the > >>> =20 > >> issue was > >> =20 > >>> already raised please point me to the relevant thread. > >>> > >>> =20 > >>> > >>> =20 > >>> =20 > >>>> -----Original Message----- > >>>> From: netmod-bounces@ietf.org > >>>> [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen > >>>> =20 > >>>> =20 > >>> =20 > >>> =20 > >>>> In particular, writable data nodes that could > >>>> be especially disruptive if abused MUST be > >>>> explicitly listed by name and the associated > >>>> security risks MUST be spelled out. > >>>> > >>>> Similarly, readable data nodes that contain > >>>> especially sensitive information or that raise > >>>> significant privacy concerns MUST be explicitly > >>>> listed by name and the reasons for the > >>>> sensitivity/privacy concerns MUST be explained. > >>>> > >>>> =20 > >>>> =20 > >>> It looks to me that the optional mode language used here > >>> =20 > >> 'data nodes > >> =20 > >>> that could be especially disruptive' and especially the word=20 > >>> 'especially' :-) contradict the MUST and allow for the security=20 > >>> considerations section to not document nodes that are not=20 > considered > >>> *especially* disruptive if abused. The practice with MIB > >>> =20 > >> objects is I > >> =20 > >>> think to document all writeable objects. Do we want to=20 > depart from=20 > >>> this practice? > >>> > >>> I am more indulgent concerning readable only nodes.=20 > >>> > >>> Dan > >>> > >>> =20 > >>> =20 > >> I don't think it was discussed yet. > >> I am OK with taking out the word "especially", and in fact=20 > I think it=20 > >> would be good to take it out in both cases. > >> > >> Other opinions or supporting opinions? > >> > >> Bert > >> > >> > >> =20 > > > > I would actually prefer to take out all the conditional=20 > language from=20 > > the writeable nodes text. > > > > OLD:=20 > > > > In particular, writable data nodes that could be especially=20 > disruptive=20 > > if abused MUST be explicitly listed by name and the associated=20 > > security risks MUST be spelled out. > > > > Similarly, readable data nodes that contain especially sensitive=20 > > information or that raise significant privacy concerns MUST be=20 > > explicitly listed by name and the reasons for the=20 > sensitivity/privacy=20 > > concerns MUST be explained. > > > > NEW:=20 > > > > In particular, writable data nodes MUST be explicitly=20 > listed by name=20 > > and the associated security risks MUST be spelled out. > > > > Similarly, readable data nodes that contain sensitive=20 > information or=20 > > that raise significant privacy concerns MUST be explicitly=20 > listed by=20 > > name and the reasons for the sensitivity/privacy concerns MUST be=20 > > explained. > > > > Dan > > > > =20 >=20 >=20 From dromasca@avaya.com Tue Apr 13 03:21: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 A7AA53A6804 for ; Tue, 13 Apr 2010 03:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, 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 Oz0AYEdz2QoA for ; Tue, 13 Apr 2010 03:21:05 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 554173A6A16 for ; Tue, 13 Apr 2010 03:19:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,196,1270440000"; d="scan'208";a="11339351" 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; 13 Apr 2010 06:19:09 -0400 X-IronPort-AV: E=Sophos;i="4.52,196,1270440000"; d="scan'208";a="451087263" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Apr 2010 06:18:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 12:18:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of YANG documents Thread-Index: Acra8qIUNfFxWxqZRj6O9u3GPqr8Xw== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] Status of YANG 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: Tue, 13 Apr 2010 10:21:09 -0000 WG chairs, As the two YANG documents completed IETF Last Call - what is your assessment about their status? Note that in order for the documents to be included on the agenda of the 4/22 telechat you need to resolve all IETFLC comments and submit revised versions of the document until this Thursday 4/15 the latest.=20 Thanks and Regards, Dan From j.schoenwaelder@jacobs-university.de Tue Apr 13 04: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 CF48F3A68BA; Tue, 13 Apr 2010 04:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLgjldPDIbW1; Tue, 13 Apr 2010 04:55:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 292623A683B; Tue, 13 Apr 2010 04:55:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A21FC0016; Tue, 13 Apr 2010 13:55:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YP9L0JCVbrMQ; Tue, 13 Apr 2010 13:55:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4546C000A; Tue, 13 Apr 2010 13:55:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5848B1183198; Tue, 13 Apr 2010 13:55:32 +0200 (CEST) Date: Tue, 13 Apr 2010 13:55:31 +0200 From: Juergen Schoenwaelder To: Ben Campbell Message-ID: <20100413115531.GA16774@elstar.local> Mail-Followup-To: Ben Campbell , General Area Review Team , "bertietf@bwijnen.net" , "mehmet.ersue@nsn.com" , "Dan (Dan) ext Romascanu" , "david.partain@ericsson.com" , IETF-Discussion list , netmod@ietf.org References: <202F3E8C-0803-4DD3-838C-313629D9A83B@estacado.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202F3E8C-0803-4DD3-838C-313629D9A83B@estacado.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF-Discussion list , netmod@ietf.org, General Area Review Team Subject: Re: [netmod] Gen-ART LC review of draft-ietf-netmod-yang-types-07 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, 13 Apr 2010 11:55:55 -0000 On Tue, Apr 06, 2010 at 10:59:36PM +0200, Ben Campbell wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Thanks for your review. I will followup on your comments below, CCing the WG mailing list so that the WG sees the exchange between us. > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-netmod-yang-types-07 > Reviewer: Ben Campbell > Review Date: 2010-04-06 > IETF LC End Date: 2010-04-09 > IESG Telechat date: (if known) > > Summary: This draft is almost ready for publication as a proposed standard. There are a few minor issues that might should be considered prior to publication. > > Major issues: None. > > Minor issues: > > -- Section 3, model namespace definition: > > (Same comment for section 4) > > Will the registered namespace really include "DRAFT-06"? Should this be replaced with the RFC number? No, this will be removed. (This was an attempt to ensure that names used in Internet drafts do not conflict with the name used by the final RFC version of a document, but we meanwhile concluded that this does not work well and has a tendency to increase confusion.) > -- description for counter32: "A default statement should not be used for > attributes with a type value of counter32." > > Should that be a normative SHOULD NOT? I think SHOULD NOT is the intention here, so I will make the change. Since the word 'attribute' is not a defined term, I suggest to rewrite this to: A default statement SHOULD NOT be used in combination with the type counter32. And likewise for counter64. > -- object-identifier description, 3rd paragraph: > > Does this imply a normative requirement that one SHOULD NOT use this > to model an SMIv2 OI? (and SHOULD instead use > object-identifier-128)? I can add a clarifying sentence so that the paragraph becomes: This type is a superset of the SMIv2 OBJECT IDENTIFIER type since it is not restricted to 128 sub-identifiers. Hence, this type SHOULD NOT be used to represent the SMIv2 OBJECT IDENTIFIER type, the object-identifier-128 type SHOULD be used instead. > -- Section 4, domain-name, description, paragraph 2: "...systems that want to store host names in > schema nodes using the domain-name type are recommended to > adhere to this stricter standard to ensure interoperability." > > should "recommended" be normative? I think I would leave it lowercase unless someone can provide a reference where a normative version of the recommendation to follow RFC 952 rules is written down. Our goal in general is to represent what the underlying technology (DNS in this case) specifies, it is not our goal to be more strict than the underlying specifications. > Nits/editorial comments: > > -- Section 2, 1st paragraph: > > Can you provide a reference for SMIv2 (I assume RFC 2578)? Also, > please expand it on first mention. Added a reference to RFC2578 and RFC2579 and expanded the acronym. > -- zero-based-counter32 description, 2nd paragraph: > > Plurality mismatch between "nodes" and "it". Suggest s/"Schema > nodes"/"A Schema node" fixed > -- date-and-time, pattern and description: > > Which is the normative description for date-and-time? The ABNF in > the description, or the pattern attribute? I assume the second, but > fear the presence of ABNF will make others assume the first. Ideally, they should be consistent - and I hope they are. The ABNF is more detailed - if you read the comments - and copied from RFC 3339. If we make a change, we should completely remove the ABNF from the description and simply leave the pointer to RFC 3339, e.g. For a more detailed description, see section 5.6 of RFC 3336. Since the ABNF is copied, this does not really change much unless RFC 3336 gets updated perhaps. For now, I have left things as they are but I am open to be convinced to remove the ABNF if someone feels strongly about this. > (Comment repeats for zero-based-counter64) fixed as well > -- zero-based-counter32 description, 3rd paragraph: > > ben: s/"wrap it"/"wrap, it" > > (Comment repeats for zero-based-counter64) fixed both > -- section 5: > > The namespaces do not match the text (see comments on the module > namespace strings in sections 3 and 4) fixed, see explanation above > -- section 9.2: > > idnits complains about unreferenced entries in this section. I'm not > sure what to do about it, or if it matters at all, since they are > referenced from the model itself. Yes, these are false alarms. Thanks again for reviewing 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 ben@estacado.net Tue Apr 13 06:59: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 03AE93A692E; Tue, 13 Apr 2010 06:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 vU4L0WpWJRlT; Tue, 13 Apr 2010 06:59:06 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 9A2F83A69E7; Tue, 13 Apr 2010 06:59:02 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-8-111.dsl.rcsntx.swbell.net [68.94.8.111]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o3DDwRWI075234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Apr 2010 08:58:32 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <20100413115531.GA16774@elstar.local> Date: Tue, 13 Apr 2010 08:58:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0153EC83-0737-4B61-B97A-5D181C09D0A8@estacado.net> References: <202F3E8C-0803-4DD3-838C-313629D9A83B@estacado.net> <20100413115531.GA16774@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Tue, 13 Apr 2010 07:00:07 -0700 Cc: IETF-Discussion list , netmod@ietf.org, General Area Review Team Subject: Re: [netmod] Gen-ART LC review of draft-ietf-netmod-yang-types-07 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, 13 Apr 2010 13:59:08 -0000 Thanks, this addresses all of my concerns. Additional comments below.=20 On Apr 13, 2010, at 6:55 AM, Juergen Schoenwaelder wrote: > On Tue, Apr 06, 2010 at 10:59:36PM +0200, Ben Campbell wrote: >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >=20 > Thanks for your review. I will followup on your comments below, CCing > the WG mailing list so that the WG sees the exchange between us. >=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. >>=20 >> Document: draft-ietf-netmod-yang-types-07 >> Reviewer: Ben Campbell >> Review Date: 2010-04-06 >> IETF LC End Date: 2010-04-09 >> IESG Telechat date: (if known) >>=20 >> Summary: This draft is almost ready for publication as a proposed = standard. There are a few minor issues that might should be considered = prior to publication. >>=20 >> Major issues: None. >>=20 >> Minor issues: >>=20 >=20 [...] >> -- Section 4, domain-name, description, paragraph 2: "...systems that = want to store host names in >> schema nodes using the domain-name type are recommended to >> adhere to this stricter standard to ensure interoperability." >>=20 >> should "recommended" be normative? >=20 > I think I would leave it lowercase unless someone can provide a > reference where a normative version of the recommendation to follow > RFC 952 rules is written down. Our goal in general is to represent > what the underlying technology (DNS in this case) specifies, it is not > our goal to be more strict than the underlying specifications. >=20 Okay. [...] >> -- date-and-time, pattern and description: >>=20 >> Which is the normative description for date-and-time? The ABNF in >> the description, or the pattern attribute? I assume the second, but >> fear the presence of ABNF will make others assume the first. >=20 > Ideally, they should be consistent - and I hope they are. The ABNF is > more detailed - if you read the comments - and copied from RFC 3339. > If we make a change, we should completely remove the ABNF from the > description and simply leave the pointer to RFC 3339, e.g. >=20 > For a more detailed description, see section 5.6 of RFC 3336. >=20 > Since the ABNF is copied, this does not really change much unless RFC > 3336 gets updated perhaps. For now, I have left things as they are but > I am open to be convinced to remove the ABNF if someone feels strongly > about this. I don't feel strongly--it was just a mild general concern that duplicate = _normative_ text can lead to future errors if, as you say, the RFC gets = updated. But if you see value in having the ABNF in the description, = that's okay with me. At the most, it might be worth putting a comment in = the description to see the RFC for the full normative definition. [...] Thanks! Ben.= From dromasca@avaya.com Tue Apr 13 07:53:53 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3273A680A for ; Tue, 13 Apr 2010 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2staxIZ3EVid for ; Tue, 13 Apr 2010 07:53:52 -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 B24973A67E3 for ; Tue, 13 Apr 2010 07:53:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,197,1270440000"; d="scan'208,217";a="11382699" 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; 13 Apr 2010 10:53:32 -0400 X-IronPort-AV: E=Sophos;i="4.52,197,1270440000"; d="scan'208,217";a="451187154" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Apr 2010 10:52:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADB18.FEBFF7F1" Date: Tue, 13 Apr 2010 16:52:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen Art LC review of draft-ietf-netmod-yang-11 Thread-Index: AcrZkYH1DXH4FT6wSGWm9P3A3Y8XzABh2sog From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: Gen Art LC review of 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: Tue, 13 Apr 2010 14:53:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADB18.FEBFF7F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Sunday, April 11, 2010 7:10 PM To: General Area Review Team; mbj@tail-f.com Cc: Romascanu, Dan (Dan) Subject: Gen Art LC review of draft-ietf-netmod-yang-11 =09 =09 I have been selected as the General Area Review Team (Gen-ART)=20 reviewer for this draft (for background on Gen-ART, please see=20 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).=20 Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft.=20 =09 Document: draft-ietf-netmod-yang-11=20 Reviewer: Avshalom Houri=20 Review Date: 2010-04-11 (sorry for the delay but it is 180 pps...).=20 IESG last call date: 2010-04-09=20 =09 Summary: The draft is ready to be published as standard track RFC=20 =09 Major issues: None=20 =09 Minor issues: None=20 =09 Nits/editorial comments:=20 =09 Lines 4643-4652:=20 No restrictions are placed on the XML. This can be useful in for=20 ....=20 example RPC replies. An example is the parameter in the=20 =09 in for example -> for example in=20 =09 Line 5861:=20 contents of the deviation statement give details about the deviation.=20 give details -> gives details =09 Line 5887:=20 back to the unsuspecting application, or ignore that incoming or ignore -> or ignores=20 =09 tnx=20 avshalom =09 =09 =09 ------_=_NextPart_001_01CADB18.FEBFF7F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Sunday, April 11, 2010 = 7:10=20 PM
To: General Area Review Team; = mbj@tail-f.com
Cc:=20 Romascanu, Dan (Dan)
Subject: Gen Art LC review of=20 draft-ietf-netmod-yang-11

I have been selected as = the General=20 Area Review Team (Gen-ART)
reviewer=20 for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please=20 wait for direction from your document shepherd
or AD before posting a new version of = the draft.=20

Document:=20 draft-ietf-netmod-yang-11
Reviewer:=20 Avshalom Houri
Review = Date:=20 2010-04-11 (sorry for the delay but it is 180 pps...). =
IESG last call date: 2010-04-09 =

Summary: The draft is ready to be = published as=20 standard track RFC

Major=20 issues: None

Minor = issues:=20 None

Nits/editorial = comments:=20

Lines = 4643-4652:=20
   No restrictions = are placed on=20 the XML.  This can be useful in for
....
  =  example=20 RPC replies.  An example is the <filter> parameter in = the=20

in for example -> for = example=20 in

Line = 5861:
   contents of the deviation = statement=20 give details about the deviation.
give details -> gives details

Line 5887:
   back=20 to the unsuspecting application, or ignore that incoming =
or ignore -> or ignores =

tnx
avshalom


------_=_NextPart_001_01CADB18.FEBFF7F1-- From j.schoenwaelder@jacobs-university.de Tue Apr 13 10:11:56 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 C338028C10E; Tue, 13 Apr 2010 10:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.524 X-Spam-Level: X-Spam-Status: No, score=-1.524 tagged_above=-999 required=5 tests=[AWL=0.725, 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 cmMIqHX3ygkr; Tue, 13 Apr 2010 10:11:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 11B133A690B; Tue, 13 Apr 2010 10:11:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 081CCC000F; Tue, 13 Apr 2010 19:11:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0NIy154f5b4w; Tue, 13 Apr 2010 19:11:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23188C0009; Tue, 13 Apr 2010 19:11:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 887651183C46; Tue, 13 Apr 2010 19:11:37 +0200 (CEST) Date: Tue, 13 Apr 2010 19:11:37 +0200 From: Juergen Schoenwaelder To: Ben Campbell Message-ID: <20100413171137.GB17932@elstar.local> Mail-Followup-To: Ben Campbell , General Area Review Team , "bertietf@bwijnen.net" , "mehmet.ersue@nsn.com" , "Dan (Dan) ext Romascanu" , "david.partain@ericsson.com" , IETF-Discussion list , "netmod@ietf.org" References: <202F3E8C-0803-4DD3-838C-313629D9A83B@estacado.net> <20100413115531.GA16774@elstar.local> <0153EC83-0737-4B61-B97A-5D181C09D0A8@estacado.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0153EC83-0737-4B61-B97A-5D181C09D0A8@estacado.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF-Discussion list , "netmod@ietf.org" , General Area Review Team Subject: Re: [netmod] Gen-ART LC review of draft-ietf-netmod-yang-types-07 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, 13 Apr 2010 17:11:56 -0000 On Tue, Apr 13, 2010 at 03:58:22PM +0200, Ben Campbell wrote: > >> -- date-and-time, pattern and description: > >> > >> Which is the normative description for date-and-time? The ABNF in > >> the description, or the pattern attribute? I assume the second, but > >> fear the presence of ABNF will make others assume the first. > > > > Ideally, they should be consistent - and I hope they are. The ABNF is > > more detailed - if you read the comments - and copied from RFC 3339. > > If we make a change, we should completely remove the ABNF from the > > description and simply leave the pointer to RFC 3339, e.g. > > > > For a more detailed description, see section 5.6 of RFC 3336. > > > > Since the ABNF is copied, this does not really change much unless RFC > > 3336 gets updated perhaps. For now, I have left things as they are but > > I am open to be convinced to remove the ABNF if someone feels strongly > > about this. > > I don't feel strongly--it was just a mild general concern that duplicate _normative_ text can lead to future errors if, as you say, the RFC gets updated. But if you see value in having the ABNF in the description, that's okay with me. At the most, it might be worth putting a comment in the description to see the RFC for the full normative definition. Since there is an explicit reference to RFC 3336, I think this is covered. Many of the data types document formats that are described in other documents and there is a general trade off what to include and what to leave out and to include by reference. I guess it is at the end a judgement call and at this stage of the process, I simply prefer to minimize changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Tue Apr 13 11:14: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 114303A68F3 for ; Tue, 13 Apr 2010 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVC2+Wd0+L0j for ; Tue, 13 Apr 2010 11:14:02 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 6703C3A6407 for ; Tue, 13 Apr 2010 11:13:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KfOGRLiKaOsVuA8y5jCOetzFVVKo0bVY15UaZCKajc/i4gEy15W0L8mYNO1SN0Vg; 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.49.241] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1O1kcP-00022H-IN for netmod@ietf.org; Tue, 13 Apr 2010 14:13:49 -0400 Message-ID: <005a01cadb35$38687580$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: Date: Tue, 13 Apr 2010 11:14:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035b82cc0165ea67fc9148497b5ddd51f16350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.49.241 Subject: Re: [netmod] FW: Gen Art LC review of 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: Tue, 13 Apr 2010 18:14:04 -0000 Hi - > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > Sent: Sunday, April 11, 2010 7:10 PM > To: General Area Review Team; mbj@tail-f.com > Cc: Romascanu, Dan (Dan) > Subject: Gen Art LC review of draft-ietf-netmod-yang-11 ... > Lines 4643-4652: > No restrictions are placed on the XML. This can be useful in for > example RPC replies. An example is the parameter in the > > in for example -> for example in I think this would be much better with commas: useful in, for example, RPC useful, for example, in RPC For example, this can be useful in RPC replies. Any of these would work for me. > Line 5861: > contents of the deviation statement give details about the deviation. > give details -> gives details Disagree. The verb's subject is "contents", which is plural, so the correct form of the verb is indeed "give". > Line 5887: > back to the unsuspecting application, or ignore that incoming > > or ignore -> or ignores Disagree. This is the second prong of the construct "a choice to X or (to) Y". There is an implied (but very optional) "to" between "or" and "ignore". However, there *is* a problem immediately following. "ignore that requests" should be "ignore that request" or "ignore those requests", depending on the intended nuance. Randy From mbj@tail-f.com Tue Apr 13 12:10:42 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 C186E3A6A82 for ; Tue, 13 Apr 2010 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ileN6Uiz4VFl for ; Tue, 13 Apr 2010 12:10:41 -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 ADF2B3A67D2 for ; Tue, 13 Apr 2010 12:10:37 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id BB77476C53A; Tue, 13 Apr 2010 21:10:30 +0200 (CEST) Date: Tue, 13 Apr 2010 21:10:29 +0200 (CEST) Message-Id: <20100413.211029.172903951.mbj@tail-f.com> To: randy_presuhn@mindspring.com, AVSHALOM@il.ibm.com From: Martin Bjorklund In-Reply-To: <005a01cadb35$38687580$6801a8c0@oemcomputer> References: <005a01cadb35$38687580$6801a8c0@oemcomputer> 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] FW: Gen Art LC review of 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: Tue, 13 Apr 2010 19:10:42 -0000 "Randy Presuhn" wrote: > Hi - > > > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > > Sent: Sunday, April 11, 2010 7:10 PM > > To: General Area Review Team; mbj@tail-f.com > > Cc: Romascanu, Dan (Dan) > > Subject: Gen Art LC review of draft-ietf-netmod-yang-11 > > ... > > Lines 4643-4652: > > No restrictions are placed on the XML. This can be useful in for > > example RPC replies. An example is the parameter in the > > > > in for example -> for example in > > I think this would be much better with commas: > useful in, for example, RPC > useful, for example, in RPC > For example, this can be useful in RPC replies. > > Any of these would work for me. Ok, I picked the second one. > > Line 5861: > > contents of the deviation statement give details about the deviation. > > give details -> gives details > > Disagree. The verb's subject is "contents", which is plural, so the correct > form of the verb is indeed "give". Good, that was what I thought. > > Line 5887: > > back to the unsuspecting application, or ignore that incoming > > > > or ignore -> or ignores > > Disagree. This is the second prong of the construct "a choice to X > or (to) Y". There is an implied (but very optional) "to" between "or" > and "ignore". Thank you. As a non-native english speaker, I was unsure. > However, there *is* a problem immediately following. > "ignore that requests" should be "ignore that request" or "ignore > those requests", depending on the intended nuance. Fixed ("those requests"). /martin From mbj@tail-f.com Tue Apr 13 14:54: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 0EB8D3A6B4E for ; Tue, 13 Apr 2010 14:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.477 X-Spam-Level: X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=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 n5lvIU9Z0mif for ; Tue, 13 Apr 2010 14:54:47 -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 2050F3A6B76 for ; Tue, 13 Apr 2010 14:53:31 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 08DF8616004; Tue, 13 Apr 2010 23:53:24 +0200 (CEST) Date: Tue, 13 Apr 2010 23:53:23 +0200 (CEST) Message-Id: <20100413.235323.121809708.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1270802680.6878.13.camel@missotis> References: <201003161108.38711.david.partain@ericsson.com> <1270802680.6878.13.camel@missotis> 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] 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, 13 Apr 2010 21:54:48 -0000 Ladislav Lhotka wrote: > Hi, > > this WGLC is over but I haven't received any comments (yet). Sorry for the late reply, but here are my comments on this document. ------------------------------------------------------------ Section 1. accompanying rules for how to model configuration and status s/status/state/ information (in XML syntax) carried by NETCONF. The IETF Operations s/(in XML syntax)// ------------------------------------------------------------ Section 2. I think you should list all the terms you import, with references. No need to copy & paste their meaning though. For example, if I didn't know that the term "information set" is defined in [XML] - checking... - hmm, it wasn't defined there... I think you also need a reference to xml-infoset. ------------------------------------------------------------ Section 2. "nmf" NETMOD-specific XPath extension functions (see Section 12.6); Bad reference to 12.6? Should you have a separate section where you define the NETMOD-specific XPath extensions? ------------------------------------------------------------ Section 2.1. o ancestor datatype: Any datytype a given datatype is (transitively) derived from. s/datytype/datatype/ ------------------------------------------------------------ Section 2.1. o conceptual data tree: A virtual XML document integrating all components of a YANG data model, i.e., configuration datastore, RPC methods (both requests and replies) and notifications. s/RPC method/RPC operation/g -- note the 'g' and in some cases s/RPC/RPC operation/g You use the terms "conceptual data tree", "conceptual tree schema" and "conceptual tree" in many places in the document. Are they the same? If so, stick to one, if not, please defined the other meanings. ------------------------------------------------------------ Section 2.1. The conceptual tree is normally not instantiated, it only serves as a conceptual target for its schema. I do not understand this. The definition seems recursive. ------------------------------------------------------------ Section 3. While the mapping from YANG to DSDL described in this document is in principle invertible, the inverse mapping from DSDL to YANG is not in its scope. AFAICT the mapping is not 100% invertible. A simple (stupid) example is description "See: foo"; and reference "foo"; which are both mapped to See foo So I wonder what the sentence about invertible mapping really says. Is the intention that a YANG to DSDL mapping *could* in principle be invertible, but this one isn't b/c it is out of scope? ------------------------------------------------------------ Section 3. To this end, the complexity of the mapping is distributed into two steps: and then you list 3 steps 1-3...? ------------------------------------------------------------ Section 7. 1. The XML instance document can be immediately checked for grammatical and data type validity using the RELAX NG schema. What does "immediately checked" mean? What does "the RELAX NG schema" refer to? Is it the output from the first step or the second step? I suggest you use two distinct terms for these schemas. ------------------------------------------------------------ Section 8.1 ... configuration and status data ... s/status/state/ ------------------------------------------------------------ Section 8.1 Should these be nmt:rpcs and nmt:rpc, to align with YANG? ------------------------------------------------------------ Section 8.1. In general, these transformations should be relatively simple - they will typically s/should be/are/ ? ------------------------------------------------------------ Section 9. The output RELAX NG schema will then contain only named pattern definitions translated from YANG groupings and typedefs. This is somewhat confusing. So far, I thought that the conceptual tree also contained typedefs and groupings. But this text tells me that is not the case. I think the handling of typedefs and groupings should be mentioned in 8.1 where it says: The schema for the conceptual tree - a single RELAX NG schema with annotations - therefore has a quite similar logic as the input YANG module(s), the only major difference being the RELAX NG schema language. ------------------------------------------------------------ Section 9.2. s/underline/underscore/ ------------------------------------------------------------ Section 9.3. Translation rule 2 means for example that absolute XPath expressions appearing in the main configuration data tree always start with "nmt: netmod-tree/nmt:top/", those appearing in a notification always start with "nmt:netmod-tree/nmt:notifications/nmt:notification/", etc. Should this be "/nmt:netmod-tree/..." ? ------------------------------------------------------------ Section 10. I cannot see where the conceptual tree is actually defined. There is one example in 8.1 which shows the netmod-tree top-level container and its children, but no specification. Hmm, section 11 does this for substatements, but it doesn't define the top-level structure. Shouldn't chapter 11 go before this chapter? ------------------------------------------------------------ Section 10. multiple types) that is to be validated. These document type can be, s/type can/types can/ or s/These/the/ ------------------------------------------------------------ Section 10.2. The value of the mandatory @context attribute of (denoted as XELEM) MUST be set to the absolute path of the context element in the data tree. Is this term "data tree" really "conceptual data tree", or did you mean "data tree" as defined in YANG? (same for other occurances of this term). ------------------------------------------------------------ Section 10.2.1. For example, a candidate configuration referring to configuration parameters or state data of certain hardware will not pass full validation before the hardware is installed. This is a somewhat controversial example. config data cannot refer to state data. Pick a simpler example, e.g. all leafreaf referential intergrity tests have to be true in a candidate configuration. ------------------------------------------------------------ Section 10.4. XPARENT ELEM DEFCONT Picky: indentation. ------------------------------------------------------------ Section 10.4. The , or patterns appearing Picky: s/>p/> p/ I do not know DSDL enough to have any comments on the contents of chapter 11 and 12. I have not reviewed the Appendices. /martin From lhotka@cesnet.cz Wed Apr 14 02:04: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 EC80F3A69ED for ; Wed, 14 Apr 2010 02:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.756 X-Spam-Level: X-Spam-Status: No, score=0.756 tagged_above=-999 required=5 tests=[AWL=-1.794, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=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 6HzI+1SZ1KD8 for ; Wed, 14 Apr 2010 02:04:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id CF71C3A69F2 for ; Wed, 14 Apr 2010 02:04:12 -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 599C82CDE059; Wed, 14 Apr 2010 11:04:05 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100413.235323.121809708.mbj@tail-f.com> References: <201003161108.38711.david.partain@ericsson.com> <1270802680.6878.13.camel@missotis> <20100413.235323.121809708.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 14 Apr 2010 11:04:04 +0200 Message-ID: <1271235844.21600.179.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [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: Wed, 14 Apr 2010 09:04:19 -0000 Hi Martin, thanks for the review, please see comments below. Lada Martin Bjorklund píše v Út 13. 04. 2010 v 23:53 +0200: > ------------------------------------------------------------ > > Section 1. > > accompanying rules for how to model configuration and status > > s/status/state/ Fixed. > > information (in XML syntax) carried by NETCONF. The IETF Operations > > s/(in XML syntax)// Removed. > > ------------------------------------------------------------ > > Section 2. > > I think you should list all the terms you import, with references. No > need to copy & paste their meaning though. For example, if I didn't > know that the term "information set" is defined in [XML] - > checking... - hmm, it wasn't defined there... I think you also need a > reference to xml-infoset. I'll try to list all terms that are not generally known - you probably don't mean terms like "XML element" here. > > ------------------------------------------------------------ > > Section 2. > > "nmf" NETMOD-specific XPath extension functions (see Section 12.6); > > Bad reference to 12.6? Should you have a separate section where you > define the NETMOD-specific XPath extensions? Actually, the reference to 12.6 is all right - that section describes the only XPath extension used in the draft - nmf:evaluate(). I am not sure about the usefulness of a separate section, if there is only one function so far. > > ------------------------------------------------------------ > > Section 2.1. > > o ancestor datatype: Any datytype a given datatype is (transitively) > derived from. > > s/datytype/datatype/ Fixed. > > ------------------------------------------------------------ > > Section 2.1. > > o conceptual data tree: A virtual XML document integrating all > components of a YANG data model, i.e., configuration datastore, > RPC methods (both requests and replies) and notifications. > > s/RPC method/RPC operation/g -- note the 'g' > > and in some cases s/RPC/RPC operation/g Changed all to "RPC operation". I assume that "RPC request" and "RPC reply" is OK. > > You use the terms "conceptual data tree", "conceptual tree schema" and > "conceptual tree" in many places in the document. Are they the same? > If so, stick to one, if not, please defined the other meanings. "conceptual data tree" == "conceptual tree" I agree that this terminology is rather confusing, also because the terms "data tree" and "conceptual" are used in the YANG draft. The idea is as follows: Conceptual tree is an XML instance document such as the one shown in sec. 8.1., and conceptual tree schema is the annotated RELAX NG schema for this instance document. However, the conceptual tree (instance) is not interesting by itself. In fact, the only role of the extra elements with "nmt" prefix is to produce a RELAX NG pattern that demarcates the corresponding part in the conceptual tree schema. For example, to extract the schema for a datastore from the conceptual tree schema, one has to take the subtree of . As an alternative, I was considering to use special markers directly in the RELAX NG schema for combining the schemas for the datastore, RPCs and notifications in one document. The advantage of the present approach is that the conceptual tree schema as a whole is still a valid RELAX NG schema. I'd appreciate any ideas how to make this setup more straightforward and the description less complex. > > > ------------------------------------------------------------ > > Section 2.1. > > The conceptual tree is normally not instantiated, it only serves as a > conceptual target for its schema. > > I do not understand this. The definition seems recursive. See above. > > ------------------------------------------------------------ > > Section 3. > > While the mapping from YANG to DSDL described in this document is in > principle invertible, the inverse mapping from DSDL to YANG is not in > its scope. > > > AFAICT the mapping is not 100% invertible. A simple (stupid) example > is > > description "See: foo"; > and > reference "foo"; > > which are both mapped to See foo > > So I wonder what the sentence about invertible mapping really says. > Is the intention that a YANG to DSDL mapping *could* in principle be > invertible, but this one isn't b/c it is out of scope? Well, coming back to the original YANG module is of course impossible (some groupings are expanded by the mapping, augments are applied etc.). One could possibly think about producing a YANG module that is equivalent in the sense that the data model is the same. But I guess it's appropriate to remove this remark completely because the inverse mapping is really out of scope and nobody is interested in it (anymore). > > > ------------------------------------------------------------ > > Section 3. > > To this end, the complexity of the mapping is > distributed into two steps: > > and then you list 3 steps 1-3...? I can only see two steps numbered 1 and 2, what do you mean? > > > ------------------------------------------------------------ > > Section 7. > > 1. The XML instance document can be immediately checked for > grammatical and data type validity using the RELAX NG schema. > > What does "immediately checked" mean? I changed it to "The instance document is checked for ..." > > What does "the RELAX NG schema" refer to? Is it the output from the > first step or the second step? I suggest you use two distinct terms > for these schemas. Right, one RELAX NG schema is the "conceptual tree schema", which is the result of the first mapping step, and the second step then produces a RELAX NG schema for a concrete target instance document. I have to make sure this distinction is clear. > > > ------------------------------------------------------------ > > Section 8.1 > > > ... configuration and status data ... > > s/status/state/ Fixed. > > ------------------------------------------------------------ > > Section 8.1 > > > > > > Should these be nmt:rpcs and nmt:rpc, to align with YANG? OK, I can change it as you suggest. > > ------------------------------------------------------------ > > Section 8.1. > > In general, these > transformations should be relatively simple - they will typically > > s/should be/are/ ? The simplicity of course also depends on the tools used for the task. So how about "The goal was to make these transformations relatively straightforward - ..."? > > > ------------------------------------------------------------ > > Section 9. > > The > output RELAX NG schema will then contain only named pattern > definitions translated from YANG groupings and typedefs. > > This is somewhat confusing. So far, I thought that the conceptual > tree also contained typedefs and groupings. But this text tells me No the conceptual tree (the instance) only contains elements coming from groupings that are used in the input YANG modules. For modules like ietf-inet-types, the conceptual tree is essentially empty - only contains the top-level "nmt:*" elements. > that is not the case. I think the handling of typedefs and groupings > should be mentioned in 8.1 where it says: > > The schema for the conceptual tree - a single RELAX NG schema with > annotations - therefore has a quite similar logic as the input YANG > module(s), the only major difference being the RELAX NG schema > language. The conceptual tree _schema_ does contain the definitions that are really used. > > > ------------------------------------------------------------ > > Section 9.2. > > s/underline/underscore/ Fixed. > > > ------------------------------------------------------------ > > Section 9.3. > > Translation rule 2 means for example that absolute XPath expressions > appearing in the main configuration data tree always start with "nmt: > netmod-tree/nmt:top/", those appearing in a notification always start > with "nmt:netmod-tree/nmt:notifications/nmt:notification/", etc. > > Should this be "/nmt:netmod-tree/..." ? Yes, but in fact the rule 2 also looks like an unnecessary complication. In the second step, the top-level parts of the XPath expressions have to be adjusted anyway to reflect the target instance document type - for instance, they would become "/nc:rpc-reply/nc:data". In the meantime, I also realized that for XPath expressions appearing inside groupings the first part is actually variable as the same grouping can be used both in the data and in an RPC. So I have to take these cases into account. > > > ------------------------------------------------------------ > > Section 10. > > I cannot see where the conceptual tree is actually defined. There is > one example in 8.1 which shows the netmod-tree top-level container and > its children, but no specification. The description is in the second paragraph of sec. 8.1, although probably insufficient - see above. > > Hmm, section 11 does this for substatements, but it doesn't define the > top-level structure. Shouldn't chapter 11 go before this chapter? Sections 6-8 try to explain the big picture whereas sec. 11 gives a detailed specification of how the individual YANG statements are mapped. I think this order is essentially correct. > > > ------------------------------------------------------------ > > Section 10. > > multiple types) that is to be validated. These document type can be, > > s/type can/types can/ or s/These/the/ "These document types can ..." > > ------------------------------------------------------------ > > Section 10.2. > > The value of the mandatory @context attribute of (denoted > as XELEM) MUST be set to the absolute path of the context element in > the data tree. > > Is this term "data tree" really "conceptual data tree", or did you > mean "data tree" as defined in YANG? (same for other occurances of > this term). None of them, probably "target instance document" is appropriate here. In the following example, the context value is "/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:default-lease-time". How would you call it? > > > ------------------------------------------------------------ > > Section 10.2.1. > > For > example, a candidate configuration referring to configuration > parameters or state data of certain hardware will not pass full > validation before the hardware is installed. > > This is a somewhat controversial example. config data cannot refer to > state data. Pick a simpler example, e.g. all leafreaf referential > intergrity tests have to be true in a candidate configuration. OK. Actually, YANG defines validity only as full validity including the referential integrity, so I am thinking about removing this phases stuff from Schematron as well. Any opinions? > > > ------------------------------------------------------------ > > Section 10.4. > > > XPARENT > ELEM > DEFCONT > > > Picky: indentation. > Fixed. > > ------------------------------------------------------------ > > Section 10.4. > > The , or patterns appearing > > Picky: s/>p/> p/ Fixed. > > > I do not know DSDL enough to have any comments on the contents of > chapter 11 and 12. > > I have not reviewed the Appendices. > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Wed Apr 14 04:45:02 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2FD6B3A6ADB; Wed, 14 Apr 2010 04:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100414114502.2FD6B3A6ADB@core3.amsl.com> Date: Wed, 14 Apr 2010 04:45:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-12.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, 14 Apr 2010 11:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-ietf-netmod-yang-12.txt Pages : 182 Date : 2010-04-14 YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14043204.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Apr 14 05:30:02 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 04E6E28C2D5; Wed, 14 Apr 2010 05:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100414123002.04E6E28C2D5@core3.amsl.com> Date: Wed, 14 Apr 2010 05:30:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-types-08.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, 14 Apr 2010 12:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-yang-types-08.txt Pages : 31 Date : 2010-04-14 This document introduces a collection of common data types to be used with the YANG data modeling language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-types-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14052843.I-D@ietf.org> --NextPart-- From mehmet.ersue@nsn.com Wed Apr 14 08:32: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 BFDB828C27C for ; Wed, 14 Apr 2010 08:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 gD+afwpcd4sh for ; Wed, 14 Apr 2010 08:32:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3E57428C288 for ; Wed, 14 Apr 2010 08:32:30 -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 o3EFWGNv000436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Apr 2010 17:32:16 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3EFWFe2023581; Wed, 14 Apr 2010 17:32:15 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 17:32:15 +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: Wed, 14 Apr 2010 17:32:14 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcraQd1pYtJRIFMpTgqDm2JdzYw7ZgAASgCQAGkQfXA= References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "Bert (IETF) Wijnen" X-OriginalArrivalTime: 14 Apr 2010 15:32:15.0962 (UTC) FILETIME=[A968B3A0:01CADBE7] Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Wed, 14 Apr 2010 15:32:34 -0000 Hi, does this then needs to be done for every grouping (which is potentially an object)? For a long YANG module I assume this would cause some effort right? At least for keeping track of all possible objects and getting it consistent. Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Romascanu, Dan (Dan) > Sent: Monday, April 12, 2010 3:23 PM > To: Bert (IETF) Wijnen > Cc: NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Actually the text in the guidelines for the security considerations in > MIB documents does not seem to leave the option to not=20 > mention writeable > objects. Here is the text. >=20 > -- if you have any read-write and/or read-create objects, please > -- describe their specific sensitivity or vulnerability. > -- RFC 2669 has a very good example. >=20 > There are a number of management objects defined in this MIB module > with a MAX-ACCESS clause of read-write and/or read-create. Such > objects may be considered sensitive or vulnerable in some network > environments. The support for SET operations in a non-secure > environment without proper protection can have a negative effect on > network operations. These are the tables and objects and their > sensitivity/vulnerability: >=20 > >=20 > This text was exactly the reason that triggered my input, because what > is now described in the 'third draft' seems to lower the bar.=20 >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net]=20 > > Sent: Monday, April 12, 2010 4:13 PM > > To: Romascanu, Dan (Dan) > > Cc: NETMOD Working Group > > Subject: Re: [netmod] third draft for yang module security=20 > > considerations > >=20 > > Wow.... > >=20 > > I thought in the MIB template, we assumed that any objects=20 > > that are not mentioned are not vulnerable. Your approachof=20 > > course make it easier, for reviewers at least, because they=20 > > would have to list all data nodes, and for the ones that do=20 > > not have any security risks, they would need to say: > > security risk abcd > > no vulenrability risk, but sensitive for=20 > > privacy because of defg > > no security or privacy risks or some such > >=20 > > That is sort of fine with me... but I am sure others may have=20 > > different opinions > >=20 > > Bert > >=20 > > Romascanu, Dan (Dan) wrote: > > > I would actually prefer to take out all the conditional=20 > > language from=20 > > > the writeable nodes text. > > > > > > OLD:=20 > > > > > > In particular, writable data nodes that could be especially=20 > > disruptive=20 > > > if abused MUST be explicitly listed by name and the associated=20 > > > security risks MUST be spelled out. > > > > > > Similarly, readable data nodes that contain especially sensitive=20 > > > information or that raise significant privacy concerns MUST be=20 > > > explicitly listed by name and the reasons for the=20 > > sensitivity/privacy=20 > > > concerns MUST be explained. > > > > > > NEW:=20 > > > > > > In particular, writable data nodes MUST be explicitly=20 > > listed by name=20 > > > and the associated security risks MUST be spelled out. > > > > > > Similarly, readable data nodes that contain sensitive=20 > > information or=20 > > > that raise significant privacy concerns MUST be explicitly=20 > > listed by=20 > > > name and the reasons for the sensitivity/privacy concerns MUST be=20 > > > explained. > > > > > > =20 > > >> -----Original Message----- > > >> From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net] > > >> Sent: Monday, April 12, 2010 1:22 PM > > >> To: Romascanu, Dan (Dan) > > >> Cc: NETMOD Working Group > > >> Subject: Re: [netmod] third draft for yang module security=20 > > >> considerations > > >> > > >> Romascanu, Dan (Dan) wrote: > > >> =20 > > >>> I apologize for commenting only now, but I was on vacation > > >>> =20 > > >> for the two > > >> =20 > > >>> weeks after Anaheim. I did not yet read all mail and if the > > >>> =20 > > >> issue was > > >> =20 > > >>> already raised please point me to the relevant thread. > > >>> > > >>> =20 > > >>> > > >>> =20 > > >>> =20 > > >>>> -----Original Message----- > > >>>> From: netmod-bounces@ietf.org > > >>>> [mailto:netmod-bounces@ietf.org] On Behalf Of Bert=20 > (IETF) Wijnen > > >>>> =20 > > >>>> =20 > > >>> =20 > > >>> =20 > > >>>> In particular, writable data nodes that could > > >>>> be especially disruptive if abused MUST be > > >>>> explicitly listed by name and the associated > > >>>> security risks MUST be spelled out. > > >>>> > > >>>> Similarly, readable data nodes that contain > > >>>> especially sensitive information or that raise > > >>>> significant privacy concerns MUST be explicitly > > >>>> listed by name and the reasons for the > > >>>> sensitivity/privacy concerns MUST be explained. > > >>>> > > >>>> =20 > > >>>> =20 > > >>> It looks to me that the optional mode language used here > > >>> =20 > > >> 'data nodes > > >> =20 > > >>> that could be especially disruptive' and especially the word=20 > > >>> 'especially' :-) contradict the MUST and allow for the security=20 > > >>> considerations section to not document nodes that are not=20 > > considered > > >>> *especially* disruptive if abused. The practice with MIB > > >>> =20 > > >> objects is I > > >> =20 > > >>> think to document all writeable objects. Do we want to=20 > > depart from=20 > > >>> this practice? > > >>> > > >>> I am more indulgent concerning readable only nodes.=20 > > >>> > > >>> Dan > > >>> > > >>> =20 > > >>> =20 > > >> I don't think it was discussed yet. > > >> I am OK with taking out the word "especially", and in fact=20 > > I think it=20 > > >> would be good to take it out in both cases. > > >> > > >> Other opinions or supporting opinions? > > >> > > >> Bert > > >> > > >> > > >> =20 > > > > > > I would actually prefer to take out all the conditional=20 > > language from=20 > > > the writeable nodes text. > > > > > > OLD:=20 > > > > > > In particular, writable data nodes that could be especially=20 > > disruptive=20 > > > if abused MUST be explicitly listed by name and the associated=20 > > > security risks MUST be spelled out. > > > > > > Similarly, readable data nodes that contain especially sensitive=20 > > > information or that raise significant privacy concerns MUST be=20 > > > explicitly listed by name and the reasons for the=20 > > sensitivity/privacy=20 > > > concerns MUST be explained. > > > > > > NEW:=20 > > > > > > In particular, writable data nodes MUST be explicitly=20 > > listed by name=20 > > > and the associated security risks MUST be spelled out. > > > > > > Similarly, readable data nodes that contain sensitive=20 > > information or=20 > > > that raise significant privacy concerns MUST be explicitly=20 > > listed by=20 > > > name and the reasons for the sensitivity/privacy concerns MUST be=20 > > > explained. > > > > > > Dan > > > > > > =20 > >=20 > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From andyb@iwl.com Wed Apr 14 08:56: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 5F94E3A6851 for ; Wed, 14 Apr 2010 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, 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 5I7jRrSneC0K for ; Wed, 14 Apr 2010 08:56:55 -0700 (PDT) Received: from smtp175.dfw.emailsrvr.com (smtp175.dfw.emailsrvr.com [67.192.241.175]) by core3.amsl.com (Postfix) with ESMTP id 8E7E63A67A4 for ; Wed, 14 Apr 2010 08:56:55 -0700 (PDT) Received: from relay17.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E60312C7267E; Wed, 14 Apr 2010 11:56:48 -0400 (EDT) Received: by relay17.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2064D2C724A5; Wed, 14 Apr 2010 11:56:48 -0400 (EDT) Message-ID: <4BC5E57F.6070103@iwl.com> Date: Wed, 14 Apr 2010 08:55:43 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations 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, 14 Apr 2010 15:56:57 -0000 Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi, > > does this then needs to be done for every grouping (which is potentially > an object)? > For a long YANG module I assume this would cause some effort right? > At least for keeping track of all possible objects and getting it > consistent. > I do not want to enumerate every leaf in the module within the security section. That has never been the procedure for MIBs -- with good reason. There may be 100 leafs and 3 of them have security implications. Does the RFC reader really want to wade through 97 "I have nothing to say here" entries? > Cheers, > Mehmet Andy > > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of ext Romascanu, Dan (Dan) >> Sent: Monday, April 12, 2010 3:23 PM >> To: Bert (IETF) Wijnen >> Cc: NETMOD Working Group >> Subject: Re: [netmod] third draft for yang module security >> considerations >> >> Actually the text in the guidelines for the security considerations in >> MIB documents does not seem to leave the option to not >> mention writeable >> objects. Here is the text. >> >> -- if you have any read-write and/or read-create objects, please >> -- describe their specific sensitivity or vulnerability. >> -- RFC 2669 has a very good example. >> >> There are a number of management objects defined in this MIB module >> with a MAX-ACCESS clause of read-write and/or read-create. Such >> objects may be considered sensitive or vulnerable in some network >> environments. The support for SET operations in a non-secure >> environment without proper protection can have a negative effect on >> network operations. These are the tables and objects and their >> sensitivity/vulnerability: >> >> >> >> This text was exactly the reason that triggered my input, because what >> is now described in the 'third draft' seems to lower the bar. >> >> Dan >> >> >>> -----Original Message----- >>> From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net] >>> Sent: Monday, April 12, 2010 4:13 PM >>> To: Romascanu, Dan (Dan) >>> Cc: NETMOD Working Group >>> Subject: Re: [netmod] third draft for yang module security >>> considerations >>> >>> Wow.... >>> >>> I thought in the MIB template, we assumed that any objects >>> that are not mentioned are not vulnerable. Your approachof >>> course make it easier, for reviewers at least, because they >>> would have to list all data nodes, and for the ones that do >>> not have any security risks, they would need to say: >>> security risk abcd >>> no vulenrability risk, but sensitive for >>> privacy because of defg >>> no security or privacy risks or some such >>> >>> That is sort of fine with me... but I am sure others may have >>> different opinions >>> >>> Bert >>> >>> Romascanu, Dan (Dan) wrote: >>>> I would actually prefer to take out all the conditional >>> language from >>>> the writeable nodes text. >>>> >>>> OLD: >>>> >>>> In particular, writable data nodes that could be especially >>> disruptive >>>> if abused MUST be explicitly listed by name and the associated >>>> security risks MUST be spelled out. >>>> >>>> Similarly, readable data nodes that contain especially sensitive >>>> information or that raise significant privacy concerns MUST be >>>> explicitly listed by name and the reasons for the >>> sensitivity/privacy >>>> concerns MUST be explained. >>>> >>>> NEW: >>>> >>>> In particular, writable data nodes MUST be explicitly >>> listed by name >>>> and the associated security risks MUST be spelled out. >>>> >>>> Similarly, readable data nodes that contain 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. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net] >>>>> Sent: Monday, April 12, 2010 1:22 PM >>>>> To: Romascanu, Dan (Dan) >>>>> Cc: NETMOD Working Group >>>>> Subject: Re: [netmod] third draft for yang module security >>>>> considerations >>>>> >>>>> Romascanu, Dan (Dan) wrote: >>>>> >>>>>> I apologize for commenting only now, but I was on vacation >>>>>> >>>>> for the two >>>>> >>>>>> weeks after Anaheim. I did not yet read all mail and if the >>>>>> >>>>> issue was >>>>> >>>>>> already raised please point me to the relevant thread. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: netmod-bounces@ietf.org >>>>>>> [mailto:netmod-bounces@ietf.org] On Behalf Of Bert >> (IETF) Wijnen >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> In particular, writable data nodes that could >>>>>>> be especially disruptive if abused MUST be >>>>>>> explicitly listed by name and the associated >>>>>>> security risks MUST be spelled out. >>>>>>> >>>>>>> Similarly, readable data nodes that contain >>>>>>> especially sensitive information or that raise >>>>>>> significant privacy concerns MUST be explicitly >>>>>>> listed by name and the reasons for the >>>>>>> sensitivity/privacy concerns MUST be explained. >>>>>>> >>>>>>> >>>>>>> >>>>>> It looks to me that the optional mode language used here >>>>>> >>>>> 'data nodes >>>>> >>>>>> that could be especially disruptive' and especially the word >>>>>> 'especially' :-) contradict the MUST and allow for the security >>>>>> considerations section to not document nodes that are not >>> considered >>>>>> *especially* disruptive if abused. The practice with MIB >>>>>> >>>>> objects is I >>>>> >>>>>> think to document all writeable objects. Do we want to >>> depart from >>>>>> this practice? >>>>>> >>>>>> I am more indulgent concerning readable only nodes. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>> I don't think it was discussed yet. >>>>> I am OK with taking out the word "especially", and in fact >>> I think it >>>>> would be good to take it out in both cases. >>>>> >>>>> Other opinions or supporting opinions? >>>>> >>>>> Bert >>>>> >>>>> >>>>> >>>> I would actually prefer to take out all the conditional >>> language from >>>> the writeable nodes text. >>>> >>>> OLD: >>>> >>>> In particular, writable data nodes that could be especially >>> disruptive >>>> if abused MUST be explicitly listed by name and the associated >>>> security risks MUST be spelled out. >>>> >>>> Similarly, readable data nodes that contain especially sensitive >>>> information or that raise significant privacy concerns MUST be >>>> explicitly listed by name and the reasons for the >>> sensitivity/privacy >>>> concerns MUST be explained. >>>> >>>> NEW: >>>> >>>> In particular, writable data nodes MUST be explicitly >>> listed by name >>>> and the associated security risks MUST be spelled out. >>>> >>>> Similarly, readable data nodes that contain 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. >>>> >>>> Dan >>>> >>>> >>> >> _______________________________________________ >> 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 dromasca@avaya.com Wed Apr 14 09:12:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4173A69B1 for ; Wed, 14 Apr 2010 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_05=-1.11] 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 kYHRavneGAwY for ; Wed, 14 Apr 2010 09:12:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 22E7E3A67A3 for ; Wed, 14 Apr 2010 09:12:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="213520937" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2010 12:12:18 -0400 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="451626181" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2010 12:11:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 18:11:16 +0200 Message-ID: In-Reply-To: <4BC5E57F.6070103@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: Acrb6xqcvnW4mPGnSweOl9pKuvBePwAADuOQ References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> <4BC5E57F.6070103@iwl.com> From: "Romascanu, Dan (Dan)" To: , "Ersue, Mehmet (NSN - DE/Munich)" Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Wed, 14 Apr 2010 16:12:31 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Sent: Wednesday, April 14, 2010 6:56 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Romascanu, Dan (Dan); Bert (IETF) Wijnen; NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Ersue, Mehmet (NSN - DE/Munich) wrote: > > Hi, > >=20 > > does this then needs to be done for every grouping (which is=20 > > potentially an object)? > > For a long YANG module I assume this would cause some effort right? > > At least for keeping track of all possible objects and getting it=20 > > consistent. > >=20 >=20 >=20 > I do not want to enumerate every leaf in the module within=20 > the security section. That has never been the procedure for=20 > MIBs -- with good reason. >=20 > There may be 100 leafs and 3 of them have security=20 > implications. Does the RFC reader really want to wade through > 97 "I have nothing to say here" entries? >=20 Actually the procedure and boilerplate for MIB modules mandates listing all writeable objects or group of objects.=20 I understand the concern and also the fact that in a YANG module all or most of the leaves are writeable, while for MIB objects this may be the case only for a minority of objects or none. Yet, exactly because this looks to me like a departure from what we have been accustomed to do in MIB modules, our decision should be discussed and we must have good arguments for the security reviewers who need to agree on this boilerplate before we start using it.=20 Then, do you believe that 3 out of 100 will be the real ratio of security-sensitive configuration out of the total? Do you mean 97% of what we configure in a router has no security implications - i.e. does not result in the network mis-behaving and users connectivity being impacted in case of mis-configuration? I doubt it.=20 Dan From andyb@iwl.com Wed Apr 14 09:40: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 6EB823A67F8 for ; Wed, 14 Apr 2010 09:40:48 -0700 (PDT) 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 jVMHfmFVTyQn for ; Wed, 14 Apr 2010 09:40:47 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id 8A89A3A67C1 for ; Wed, 14 Apr 2010 09:40:47 -0700 (PDT) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 72EAD9085CB; Wed, 14 Apr 2010 12:40:41 -0400 (EDT) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1E89A90866A; Wed, 14 Apr 2010 12:40:41 -0400 (EDT) Message-ID: <4BC5EFC9.1070106@iwl.com> Date: Wed, 14 Apr 2010 09:39:37 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> <4BC5E57F.6070103@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations 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, 14 Apr 2010 16:40:48 -0000 Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: Andy Bierman [mailto:andyb@iwl.com] >> Sent: Wednesday, April 14, 2010 6:56 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: Romascanu, Dan (Dan); Bert (IETF) Wijnen; NETMOD Working Group >> Subject: Re: [netmod] third draft for yang module security >> considerations >> >> Ersue, Mehmet (NSN - DE/Munich) wrote: >>> Hi, >>> >>> does this then needs to be done for every grouping (which is >>> potentially an object)? >>> For a long YANG module I assume this would cause some effort right? >>> At least for keeping track of all possible objects and getting it >>> consistent. >>> >> >> I do not want to enumerate every leaf in the module within >> the security section. That has never been the procedure for >> MIBs -- with good reason. >> >> There may be 100 leafs and 3 of them have security >> implications. Does the RFC reader really want to wade through >> 97 "I have nothing to say here" entries? >> > > Actually the procedure and boilerplate for MIB modules mandates listing > all writeable objects or group of objects. > > I understand the concern and also the fact that in a YANG module all or > most of the leaves are writeable, while for MIB objects this may be the > case only for a minority of objects or none. Yet, exactly because this > looks to me like a departure from what we have been accustomed to do in > MIB modules, our decision should be discussed and we must have good > arguments for the security reviewers who need to agree on this > boilerplate before we start using it. > > Then, do you believe that 3 out of 100 will be the real ratio of > security-sensitive configuration out of the total? Do you mean 97% of > what we configure in a router has no security implications - i.e. does > not result in the network mis-behaving and users connectivity being > impacted in case of mis-configuration? I doubt it. > I do not see the value of listing the objects that do not have any security issues, no matter what the percentage. The percentage will vary, depending on the module subject matter. Is there some assumption that every writable object is a security risk because it can cause the network to change? Large modules like ipfix-psamp.yang have a lot of writable leafs. Listing all of them is going to hide the problem leafs in pages of useless text. It is going to be a lot of busy work for the IPFIX authors to list every writable leaf and explain why or why not be worried about security. > Dan > Andy From dromasca@avaya.com Wed Apr 14 09:53:02 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 45B643A698F for ; Wed, 14 Apr 2010 09:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 QyCtsOTJxl0T for ; Wed, 14 Apr 2010 09:53:01 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2CDA428C0D0 for ; Wed, 14 Apr 2010 09:52:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="184334423" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2010 12:52:21 -0400 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="451639547" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2010 12:52:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 18:52:16 +0200 Message-ID: In-Reply-To: <4BC5EFC9.1070106@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: Acrb8TmFvPbIbWKlQ0+Oplr7iM3JZAAAHwRA References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> <4BC5E57F.6070103@iwl.com> <4BC5EFC9.1070106@iwl.com> From: "Romascanu, Dan (Dan)" To: Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Wed, 14 Apr 2010 16:53:02 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Sent: Wednesday, April 14, 2010 7:40 PM > To: Romascanu, Dan (Dan) > Cc: Ersue, Mehmet (NSN - DE/Munich); Bert (IETF) Wijnen;=20 > NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Romascanu, Dan (Dan) wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Andy Bierman [mailto:andyb@iwl.com] > >> Sent: Wednesday, April 14, 2010 6:56 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: Romascanu, Dan (Dan); Bert (IETF) Wijnen; NETMOD Working Group > >> Subject: Re: [netmod] third draft for yang module security=20 > >> considerations > >> > >> Ersue, Mehmet (NSN - DE/Munich) wrote: > >>> Hi, > >>> > >>> does this then needs to be done for every grouping (which is=20 > >>> potentially an object)? > >>> For a long YANG module I assume this would cause some=20 > effort right? > >>> At least for keeping track of all possible objects and getting it=20 > >>> consistent. > >>> > >> > >> I do not want to enumerate every leaf in the module within the=20 > >> security section. That has never been the procedure for=20 > MIBs -- with=20 > >> good reason. > >> > >> There may be 100 leafs and 3 of them have security implications. =20 > >> Does the RFC reader really want to wade through > >> 97 "I have nothing to say here" entries? > >> > >=20 > > Actually the procedure and boilerplate for MIB modules mandates=20 > > listing all writeable objects or group of objects. > >=20 > > I understand the concern and also the fact that in a YANG=20 > module all=20 > > or most of the leaves are writeable, while for MIB objects=20 > this may be=20 > > the case only for a minority of objects or none. Yet,=20 > exactly because=20 > > this looks to me like a departure from what we have been=20 > accustomed to=20 > > do in MIB modules, our decision should be discussed and we=20 > must have=20 > > good arguments for the security reviewers who need to agree on this=20 > > boilerplate before we start using it. > >=20 > > Then, do you believe that 3 out of 100 will be the real ratio of=20 > > security-sensitive configuration out of the total? Do you=20 > mean 97% of=20 > > what we configure in a router has no security implications=20 > - i.e. does=20 > > not result in the network mis-behaving and users connectivity being=20 > > impacted in case of mis-configuration? I doubt it. > >=20 >=20 > I do not see the value of listing the objects that do not=20 > have any security issues, no matter what the percentage. > The percentage will vary, depending on the module subject matter. OK, I can agree with this. This is however NOT was done with MIB objects, and will need to be explained to the security people.=20 >=20 > Is there some assumption that every writable object is a=20 > security risk because it can cause the network to change? >=20 That's one way to approximate the security risks. If by a configuration command on a leaf you can put down a router or reduce its capacity to a quarter, then it's a security risk.=20 > Large modules like ipfix-psamp.yang have a lot of writable leafs. > Listing all of them is going to hide the problem leafs in=20 > pages of useless text. It is going to be a lot of busy work=20 > for the IPFIX authors to list every writable leaf and explain=20 > why or why not be worried about security. Listing all individual objects was avoided in the security consideration sections of MIB documents by allowing to describe security risks for 'tables and objects' when the same security risks applied for example to all writeable objects in a table. We may try something similar in YANG. Dan From andyb@iwl.com Wed Apr 14 10:12: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 F22EA3A69C2 for ; Wed, 14 Apr 2010 10:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.070, 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 WeeYnY39EJR4 for ; Wed, 14 Apr 2010 10:12:05 -0700 (PDT) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 07BDE3A69A2 for ; Wed, 14 Apr 2010 10:12:04 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id D435A13D3A2B; Wed, 14 Apr 2010 13:11:57 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 6C2DD13D4386; Wed, 14 Apr 2010 13:11:51 -0400 (EDT) Message-ID: <4BC5F716.2010408@iwl.com> Date: Wed, 14 Apr 2010 10:10:46 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> <4BC5E57F.6070103@iwl.com> <4BC5EFC9.1070106@iwl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations 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, 14 Apr 2010 17:12:07 -0000 Romascanu, Dan (Dan) wrote: > .... >> I do not see the value of listing the objects that do not >> have any security issues, no matter what the percentage. >> The percentage will vary, depending on the module subject matter. > > OK, I can agree with this. This is however NOT was done with MIB > objects, and will need to be explained to the security people. > >> Is there some assumption that every writable object is a >> security risk because it can cause the network to change? >> > > That's one way to approximate the security risks. If by a configuration > command on a leaf you can put down a router or reduce its capacity to a > quarter, then it's a security risk. > Maybe we need more precise text on this issue. Need to be listed: 1) affects network behavior (routing, VPN) 2) affects network services (dhcp, dns) 3) affects a device's ability to use the network (interfaces) 4) operator access related parameters (NACM, user table, radius, etc.) 5) parameters to control output of data to the network (syslog, netconf subscriptions) Does not need to be listed: A) parameters to affect how the device implementation behaves (performance tuning, cache sizes) B) parameters for user or session preferences C) parameters for functional options (polling interval, timezone) >> Large modules like ipfix-psamp.yang have a lot of writable leafs. >> Listing all of them is going to hide the problem leafs in >> pages of useless text. It is going to be a lot of busy work >> for the IPFIX authors to list every writable leaf and explain >> why or why not be worried about security. > > Listing all individual objects was avoided in the security consideration > sections of MIB documents by allowing to describe security risks for > 'tables and objects' when the same security risks applied for example to > all writeable objects in a table. We may try something similar in YANG. > good point. If most of a list or container needs to be listed, then 1 entry can cover the entire subtree. > Dan > > Andy From randy_presuhn@mindspring.com Wed Apr 14 12:37: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 C16253A68DA for ; Wed, 14 Apr 2010 12:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kbq2g+jvm0r for ; Wed, 14 Apr 2010 12:37:03 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A671C3A6774 for ; Wed, 14 Apr 2010 12:37:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=huxk2/TuP3LvUvjvqsRTZbZuSwsGHfZDJf/JGsXBXbKZTRqdhZmO8X3g79ZCmQF3; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.4.76] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1O28OP-0003Ci-4c for netmod@ietf.org; Wed, 14 Apr 2010 15:36:57 -0400 Message-ID: <006301cadc0a$00a6de40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "NETMOD Working Group" References: <4BA91F64.70801@bwijnen.net> <4BBEDD3B.90902@bwijnen.net><4BC2CBD4.5060601@bwijnen.net><4BC2F43A.1030402@bwijnen.net><4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net><4BC5E57F.6070103@iwl.com><4BC5EFC9.1070106@iwl.com> <4BC5F716.2010408@iwl.com> Date: Wed, 14 Apr 2010 12:38:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035d106df4728683891eaf6e5dbc8b6bda1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.4.76 Subject: Re: [netmod] third 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: Wed, 14 Apr 2010 19:37:05 -0000 Hi - > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: "NETMOD Working Group" > Sent: Wednesday, April 14, 2010 10:10 AM > Subject: Re: [netmod] third draft for yang module security considerations ... > Does not need to be listed: > > A) parameters to affect how the device implementation behaves > (performance tuning, cache sizes) > B) parameters for user or session preferences > C) parameters for functional options (polling interval, timezone) To me these are all potentially sensitive. Messing up the performance tuning, session preferences, polling intervals or timezone could have severe operational consequences. Imagine changing a timezone and performance tuning parameters for a branch office's file server, causing its late-night backup script to run during the middle of the day. I'd put it another way: if something is important enough to make configurable, it is by definition potentially sensitive. I'd go so far as to say that if there's some bit of configuration data that is not deemed sensitive, the spec bears the burden of explaining why it's worth configuring. Randy From david.kessens@nsn.com Wed Apr 14 12:37:56 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 727DA3A68DA for ; Wed, 14 Apr 2010 12:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqBf-LZiWtJH for ; Wed, 14 Apr 2010 12:37:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EFB283A68C3 for ; Wed, 14 Apr 2010 12:37:54 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3EJbght022063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Apr 2010 21:37:43 +0200 Received: from localhost.localdomain ([10.138.51.230]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3EJbfVT007877; Wed, 14 Apr 2010 21:37:41 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o3EJbeOW007356; Wed, 14 Apr 2010 12:37:40 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o3EJbdZx007355; Wed, 14 Apr 2010 12:37:39 -0700 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Wed, 14 Apr 2010 12:37:39 -0700 From: David Kessens To: Andy Bierman Message-ID: <20100414193736.GB2798@nsn.com> References: <4BC2F43A.1030402@bwijnen.net> <4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> <4BC5E57F.6070103@iwl.com> <4BC5EFC9.1070106@iwl.com> <4BC5F716.2010408@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC5F716.2010408@iwl.com> User-Agent: Mutt/1.5.20 (2009-08-17) Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Wed, 14 Apr 2010 19:37:56 -0000 I am a bit afraid that we are going to make things more difficult then what makes sense: Per definition, writable objects come with security risks as they might leave the device in a different state. The yang module already documents what is writable or readable, I don't see much reason why this should be enumerated again. Basically, the security section should say to read the module to find out which ones are at such a higher risk because they are writable. As for the specifics of the risk, that is really not something that was introduced by the management system (yang) but are more fundamental to whatever you are managing. I can live with a statement that refers to the inherent risks of the protocol being managed and a reference to the security section of that document and the inherent risks of using buggy code. Basically, we should say something that configuring your device using yang can be risky if you don't know understand what you are configuring. The yang module cannot prevent you from doing dumb things. In the end, everything writable is a risk under the wrong circumstances, whether it is just a "user preference" option or bringing down/up an interface. David Kessens --- On Wed, Apr 14, 2010 at 10:10:46AM -0700, Andy Bierman wrote: > Romascanu, Dan (Dan) wrote: > > > .... > >> I do not see the value of listing the objects that do not > >> have any security issues, no matter what the percentage. > >> The percentage will vary, depending on the module subject matter. > > > > OK, I can agree with this. This is however NOT was done with MIB > > objects, and will need to be explained to the security people. > > > >> Is there some assumption that every writable object is a > >> security risk because it can cause the network to change? > >> > > > > That's one way to approximate the security risks. If by a configuration > > command on a leaf you can put down a router or reduce its capacity to a > > quarter, then it's a security risk. > > > > > Maybe we need more precise text on this issue. > > Need to be listed: > > 1) affects network behavior (routing, VPN) > 2) affects network services (dhcp, dns) > 3) affects a device's ability to use the network (interfaces) > 4) operator access related parameters (NACM, user table, radius, etc.) > 5) parameters to control output of data to the network (syslog, > netconf subscriptions) > > Does not need to be listed: > > A) parameters to affect how the device implementation behaves > (performance tuning, cache sizes) > B) parameters for user or session preferences > C) parameters for functional options (polling interval, timezone) > > > > >> Large modules like ipfix-psamp.yang have a lot of writable leafs. > >> Listing all of them is going to hide the problem leafs in > >> pages of useless text. It is going to be a lot of busy work > >> for the IPFIX authors to list every writable leaf and explain > >> why or why not be worried about security. > > > > Listing all individual objects was avoided in the security consideration > > sections of MIB documents by allowing to describe security risks for > > 'tables and objects' when the same security risks applied for example to > > all writeable objects in a table. We may try something similar in YANG. > > > > good point. > If most of a list or container needs to be listed, then 1 entry can > cover the entire subtree. > > > > Dan > > > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod David Kessens --- From andyb@iwl.com Wed Apr 14 13:10:10 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C2C3A691A for ; Wed, 14 Apr 2010 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=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 gVv-O+WYS2gT for ; Wed, 14 Apr 2010 13:10:07 -0700 (PDT) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 0F1EA3A6A47 for ; Wed, 14 Apr 2010 13:09:49 -0700 (PDT) Received: from relay11.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id C02E6180423; Wed, 14 Apr 2010 16:09:42 -0400 (EDT) Received: by relay11.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 13E2718046C; Wed, 14 Apr 2010 16:09:36 -0400 (EDT) Message-ID: <4BC620BF.4000107@iwl.com> Date: Wed, 14 Apr 2010 13:08:31 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: David Kessens References: <4BC2F43A.1030402@bwijnen.net> <4BC31C4D.5050203@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A64704480@DEMUEXC006.nsn-intra.net> <4BC5E57F.6070103@iwl.com> <4BC5EFC9.1070106@iwl.com> <4BC5F716.2010408@iwl.com> <20100414193736.GB2798@nsn.com> In-Reply-To: <20100414193736.GB2798@nsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations 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, 14 Apr 2010 20:10:10 -0000 David Kessens wrote: > I am a bit afraid that we are going to make things more difficult then > what makes sense: > amen to that! > Per definition, writable objects come with security risks as they might > leave the device in a different state. > > The yang module already documents what is writable or readable, I don't see > much reason why this should be enumerated again. Basically, the security > section should say to read the module to find out which ones are at such a > higher risk because they are writable. > Good idea, especially since we will never agree on rules for deciding if an object needs to be listed or not. The NETCONF NACM module (in draft-bierman-netconf-nacm-01.txt) contains the nacm:secure and nacm:very-secure extensions. These can used to tag YANG constructs that should be read-only or no-access by default. Tools can process YANG nodes based on the tags. For example, the server implementing NACM must not allow default access to such nodes. Another tool might generate the list of secure and very-secure objects in xml2rfc format. An NMS might high-light these objects in a YANG browser. I think a good compromise is to put the security concerns in the description-stmt for the node, and just list the writable nodes in the security considerations section, without any additional text. Instead there would be something like: Refer to the YANG definitions of the following objects, which allow write access, for security considerations: /top-node/foo /top-node/bar /other-node/some/leaf > As for the specifics of the risk, that is really not something that was > introduced by the management system (yang) but are more fundamental to > whatever you are managing. > > I can live with a statement that refers to the inherent risks of the > protocol being managed and a reference to the security section of that > document and the inherent risks of using buggy code. > > Basically, we should say something that configuring your device using yang > can be risky if you don't know understand what you are configuring. The yang > module cannot prevent you from doing dumb things. In the end, everything > writable is a risk under the wrong circumstances, whether it is just a "user > preference" option or bringing down/up an interface. > > David Kessens Andy From mbj@tail-f.com Wed Apr 14 13:20: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 BCE203A6A46 for ; Wed, 14 Apr 2010 13:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=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 b-jQjIA+hYSF for ; Wed, 14 Apr 2010 13:20:38 -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 2B4FD3A6A79 for ; Wed, 14 Apr 2010 13:19:07 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id F341B616002; Wed, 14 Apr 2010 22:18:59 +0200 (CEST) Date: Wed, 14 Apr 2010 22:18:59 +0200 (CEST) Message-Id: <20100414.221859.20394429.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BC620BF.4000107@iwl.com> References: <4BC5F716.2010408@iwl.com> <20100414193736.GB2798@nsn.com> <4BC620BF.4000107@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] third 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: Wed, 14 Apr 2010 20:20:39 -0000 Andy Bierman wrote: > The NETCONF NACM module (in draft-bierman-netconf-nacm-01.txt) > contains the nacm:secure and nacm:very-secure extensions. > These can used to tag YANG constructs that should be read-only > or no-access by default. [...] > I think a good compromise is to put the security concerns in the > description-stmt for the node, and just list the writable nodes in > the security considerations section, without any additional text. I like this idea. I think it can be useful to make things a bit more clear by putting the security consideration text not in the description statement, but in the nacm:secure statement: leaf foo { ... description "what the leaf means"; nacm:secure "why it is marked as secure"; } /martin From andyb@iwl.com Wed Apr 14 13:38: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 613253A6A93 for ; Wed, 14 Apr 2010 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=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 taQmGNtJYnA0 for ; Wed, 14 Apr 2010 13:38:28 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by core3.amsl.com (Postfix) with ESMTP id CEC6328C10B for ; Wed, 14 Apr 2010 13:37:28 -0700 (PDT) Received: from relay14.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id B7FCA9084F0; Wed, 14 Apr 2010 16:37:22 -0400 (EDT) Received: by relay14.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 64FB99084C6; Wed, 14 Apr 2010 16:37:22 -0400 (EDT) Message-ID: <4BC6273C.2010806@iwl.com> Date: Wed, 14 Apr 2010 13:36:12 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BC5F716.2010408@iwl.com> <20100414193736.GB2798@nsn.com> <4BC620BF.4000107@iwl.com> <20100414.221859.20394429.mbj@tail-f.com> In-Reply-To: <20100414.221859.20394429.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] third draft for yang module security considerations 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, 14 Apr 2010 20:38:29 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> The NETCONF NACM module (in draft-bierman-netconf-nacm-01.txt) >> contains the nacm:secure and nacm:very-secure extensions. >> These can used to tag YANG constructs that should be read-only >> or no-access by default. > > [...] > >> I think a good compromise is to put the security concerns in the >> description-stmt for the node, and just list the writable nodes in >> the security considerations section, without any additional text. > > I like this idea. I think it can be useful to make things a bit more > clear by putting the security consideration text not in the > description statement, but in the nacm:secure statement: > > leaf foo { > ... > description > "what the leaf means"; > nacm:secure > "why it is marked as secure"; > } > This seems like it would be useful, but in reality, it introduces the same problem as David is trying to avoid, which is to define the criteria for 'security text' vs. 'non-security text'. I also do not want the most important descriptive text in an extension that can be tossed by every compiler. That would be bad. Special-purpose description clauses are a slippery-slope. We already have description, presence, reference, organization, and contact. That is plenty. > > > /martin > Andy From phil@juniper.net Wed Apr 14 14:09:42 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 9DD993A6AF3 for ; Wed, 14 Apr 2010 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kANpMageugyh for ; Wed, 14 Apr 2010 14:09:41 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 552513A67DB for ; Wed, 14 Apr 2010 14:09:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS8YvBiGxUrpTB7yCkfcc20TMRMM89J8j@postini.com; Wed, 14 Apr 2010 14:09:30 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, 14 Apr 2010 14:05: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); Wed, 14 Apr 2010 14:05:03 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 14:05:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 14:05: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 o3EL52D91058; Wed, 14 Apr 2010 14:05:02 -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 o3EKmFTU011402; Wed, 14 Apr 2010 20:48:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201004142048.o3EKmFTU011402@idle.juniper.net> To: Randy Presuhn In-Reply-To: <006301cadc0a$00a6de40$6801a8c0@oemcomputer> Date: Wed, 14 Apr 2010 16:48:15 -0400 From: Phil Shafer X-OriginalArrivalTime: 14 Apr 2010 21:05:02.0966 (UTC) FILETIME=[26ABB960:01CADC16] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Wed, 14 Apr 2010 21:09:42 -0000 "Randy Presuhn" writes: >I'd go so far as to say that if there's some bit of configuration data >that is not deemed sensitive, the spec bears the burden of >explaining why it's worth configuring. If all config data is sensitive, then we don't need to burn words crawling thru the details for each node. In many cases explaining the attack scenarios or implications of a config error is a very complex task. For example, if the domain search list is not entered correctly, will my syslog data (IDP/SNMP/etc) get discarded? Or if the system location is not entered correctly, will my network fail if I turn off power to rack 13 after checking that nothing on rack 13 is needed anymore? How far down this road do we need to go? Perhaps we just need a more blanket statement like: Caveat Configurator: Configuring network equipment is inherently dangerous. Improper usage, manipulation, handling, storage, and transportation of configuration data create a risk of security-related issues. The chief concern is controlling access to the devices, but the configuration of the network will affect the ability of the network to function correctly, including reporting security-related issues. Configuration data must be dealt with correctly to allow the network to operate in a useful and secure manner. Please read the YANG module thoroughly before using, and consider the issues that can arise from improper configuration handling. Any specific issues with particular data nodes are described in the YANG module with the appropriate node definition. Thanks, Phil From dromasca@avaya.com Thu Apr 15 03:17: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 4DA3A3A6B84 for ; Thu, 15 Apr 2010 03:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 oKBOAuIWpBpE for ; Thu, 15 Apr 2010 03:17:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EC1843A6B83 for ; Thu, 15 Apr 2010 03:16:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,211,1270440000"; d="scan'208";a="184440877" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Apr 2010 06:16:09 -0400 X-IronPort-AV: E=Sophos;i="4.52,211,1270440000"; d="scan'208";a="451879779" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Apr 2010 06:16:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2010 12:15:48 +0200 Message-ID: In-Reply-To: <201004142048.o3EKmFTU011402@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcrcFsu491aEW4NbRVaKuhXmZ/3K1wAay26w References: <006301cadc0a$00a6de40$6801a8c0@oemcomputer> <201004142048.o3EKmFTU011402@idle.juniper.net> From: "Romascanu, Dan (Dan)" To: "Phil Shafer" , "Randy Presuhn" Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Thu, 15 Apr 2010 10:17:01 -0000 I doubt that a blanket statement like the one proposed below will ever be approved by the security area experts. This goes against the practice and guidance provided to authors of RFCs in the last decade or maybe longer time which requires 'strong' security considerations sections - see RFC 3552 (BCP 72). I think (and Bert should correct me here if I am wrong) that the Security Considerations guidelines for MIB documents were created by Bert and Steve Bellovin to help people writing MIB documents implement the recommendations of RFC 3552 in a way that makes sense for MIB modules. What we need is something similar for YANG modules that can be written in a manner that does not create a huge overhead for people writing, reading and deploying YANG modules.=20 Dan > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer > Sent: Wednesday, April 14, 2010 11:48 PM > To: Randy Presuhn > Cc: NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > "Randy Presuhn" writes: > >I'd go so far as to say that if there's some bit of=20 > configuration data=20 > >that is not deemed sensitive, the spec bears the burden of=20 > explaining=20 > >why it's worth configuring. >=20 > If all config data is sensitive, then we don't need to burn=20 > words crawling thru the details for each node. In many cases=20 > explaining the attack scenarios or implications of a config=20 > error is a very complex task. For example, if the domain=20 > search list is not entered correctly, will my syslog data=20 > (IDP/SNMP/etc) get discarded? Or if the system location is=20 > not entered correctly, will my network fail if I turn off=20 > power to rack 13 after checking that nothing on rack 13 is=20 > needed anymore? How far down this road do we need to go? >=20 > Perhaps we just need a more blanket statement like: >=20 > Caveat Configurator: >=20 > Configuring network equipment is inherently dangerous. Improper > usage, manipulation, handling, storage, and transportation of > configuration data create a risk of security-related issues. The > chief concern is controlling access to the devices, but the > configuration of the network will affect the ability of the network > to function correctly, including reporting security-related issues. > Configuration data must be dealt with correctly to allow the > network to operate in a useful and secure manner. >=20 > Please read the YANG module thoroughly before using, and consider > the issues that can arise from improper configuration handling. > Any specific issues with particular data nodes are described in > the YANG module with the appropriate node definition. >=20 > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Thu Apr 15 03:19: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 5A4783A6941 for ; Thu, 15 Apr 2010 03:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_46=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 mFxXBP1ZJNSS for ; Thu, 15 Apr 2010 03:19:23 -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 9BB0F3A6B83 for ; Thu, 15 Apr 2010 03:19:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,211,1270440000"; d="scan'208";a="11731238" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 15 Apr 2010 06:19:01 -0400 X-IronPort-AV: E=Sophos;i="4.52,211,1270440000"; d="scan'208";a="464832632" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Apr 2010 06:19: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: Thu, 15 Apr 2010 12:18:51 +0200 Message-ID: In-Reply-To: <4BC6273C.2010806@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcrcEnFeuU8IaNWPTsWdrVoSWmDu4wAckhjg References: <4BC5F716.2010408@iwl.com> <20100414193736.GB2798@nsn.com> <4BC620BF.4000107@iwl.com><20100414.221859.20394429.mbj@tail-f.com> <4BC6273C.2010806@iwl.com> From: "Romascanu, Dan (Dan)" To: , "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] third 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: Thu, 15 Apr 2010 10:19:24 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Wednesday, April 14, 2010 11:36 PM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> The NETCONF NACM module (in draft-bierman-netconf-nacm-01.txt) > >> contains the nacm:secure and nacm:very-secure extensions. > >> These can used to tag YANG constructs that should be read-only or=20 > >> no-access by default. > >=20 > > [...] > >=20 > >> I think a good compromise is to put the security concerns in the=20 > >> description-stmt for the node, and just list the writable nodes in=20 > >> the security considerations section, without any additional text. > >=20 > > I like this idea. I think it can be useful to make things=20 > a bit more=20 > > clear by putting the security consideration text not in the=20 > > description statement, but in the nacm:secure statement: > >=20 > > leaf foo { > > ... > > description > > "what the leaf means"; > > nacm:secure > > "why it is marked as secure"; > > } > >=20 >=20 > This seems like it would be useful, but in reality, it=20 > introduces the same problem as David is trying to avoid,=20 > which is to define the criteria for 'security text' vs.=20 > 'non-security text'. >=20 > I also do not want the most important descriptive text in an=20 > extension that can be tossed by every compiler. That would be bad. >=20 > Special-purpose description clauses are a slippery-slope. > We already have description, presence, reference,=20 > organization, and contact. That is plenty. >=20 >=20 +1=20 Moreover, it looks to me that it does not create less lines of text but potentially more than listing individual leaves and their security (or non-security) concerns in the Security Considerations section.=20 Dan From lhotka@cesnet.cz Thu Apr 15 05:08: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 1B43B28C193 for ; Thu, 15 Apr 2010 05:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.681 X-Spam-Level: X-Spam-Status: No, score=0.681 tagged_above=-999 required=5 tests=[AWL=-1.269, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_45=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 NvMn0+EQJVzd for ; Thu, 15 Apr 2010 05:08:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 33C2228C17C for ; Thu, 15 Apr 2010 05:08:10 -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 662072CDE059 for ; Thu, 15 Apr 2010 14:08:03 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 15 Apr 2010 14:08:02 +0200 Message-ID: <1271333282.1743.77.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: [netmod] external review of dsdl-map-05 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, 15 Apr 2010 12:08:17 -0000 Hi, Jirka Kosek sent me his comments to the DSDL mapping draft. I also added my comments in brackets. Lada -------- Přeposlaná zpráva -------- Od: Jirka Kosek Komu: Ladislav Lhotka Předmět: Re: prosba o review Datum: Thu, 15 Apr 2010 11:31:40 +0200 ... Sec. 7. NETCONF Content Validation: I don't know exactly what DSRL is supposed to add to a document, but perhaps it would be better to run the RELAX NG validation after adding the defaults in order to be able to catch the cases where the default value that has been added to the document e.g. violates the data type constraints. [ I considered this option previously - it would in effect change all leafs with default values from optional to mandatory in the RELAX NG schema. I don't think the (in)validity of default values is a problem, as long as they are taken from valid YANG modules. ] Sec 8.4: The description of namespace handling in RELAX NG is not completely right. RELAX NG doesn't have the notion of "target namespace". RELAX NG grammar defines patterns for elements and part of this pattern is element name. This name may be qualified (in a namespace) and this specified either by ns attribute or by using QName in a name attribute So namespace declarations like xmlns:x itself doesn't define anything similar to target namespace. Important is that some declared element uses this prefix in element name. [ I will fix the terminology. ] Section 9.3: Definition of translation of XPath expression is quite fuzzy. I think that it has to be specified more exactly as a rewrite rules operating on XPath expression tokenized to symbols defined in XPath specs (http://www.w3.org/TR/xpath/) or it might be possible to reach similar functionality by defining custom context for evaluating expression. Similar thing has been done for HTML5, see http://www.whatwg.org/specs/web-apps/current-work/multipage/apis-in-html-documents.html#interactions-with-xpath-and-xslt http://www.w3.org/Bugs/Public/show_bug.cgi?id=7059 [ I'll try to follow the recommendation in the first part. The links at the bottom lead to a discussion quite similar to one that our WG had regarding the default namespace handling in XPath expressions. Such an approach is not possible for the DSDL mapping though, because XSLT 1.0 processors follow the spec exactly when handling QNames (no prefix = no namespace). ] Appendix A.1: I suggest not to use !DOCTYPE and expand entity &nmannot-uri; in listing. !DOCTYPE can be itself misleading. [ IMO the entity aids readability as it is used in multiple places, and also helps to fit the schema into the 72-character limit for line length. ] If you really want to preserve !DOCTYPE, then use correct one: 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 D70D03A6BA6 for ; Thu, 15 Apr 2010 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.158, 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 0EO8b4HWV-Qf for ; Thu, 15 Apr 2010 08:46:50 -0700 (PDT) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by core3.amsl.com (Postfix) with ESMTP id 1BAA23A6BBB for ; Thu, 15 Apr 2010 08:46:02 -0700 (PDT) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 2687C13D40D5; Thu, 15 Apr 2010 11:45:55 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 198DE13D4114; Thu, 15 Apr 2010 11:45:51 -0400 (EDT) Message-ID: <4BC734B5.4040802@iwl.com> Date: Thu, 15 Apr 2010 08:45:57 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <006301cadc0a$00a6de40$6801a8c0@oemcomputer> <201004142048.o3EKmFTU011402@idle.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] third draft for yang module security considerations 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, 15 Apr 2010 15:46:50 -0000 Romascanu, Dan (Dan) wrote: > I doubt that a blanket statement like the one proposed below will ever > be approved by the security area experts. This goes against the practice > and guidance provided to authors of RFCs in the last decade or maybe > longer time which requires 'strong' security considerations sections - > see RFC 3552 (BCP 72). I think (and Bert should correct me here if I am > wrong) that the Security Considerations guidelines for MIB documents > were created by Bert and Steve Bellovin to help people writing MIB > documents implement the recommendations of RFC 3552 in a way that makes > sense for MIB modules. What we need is something similar for YANG > modules that can be written in a manner that does not create a huge > overhead for people writing, reading and deploying YANG modules. > > I remember the motivation for strong SMIv2 SC sections was to avoid having to read the entire MIB module to find out if there are any objects of interest. I think listing the writable objects (in the SC section) is a good idea. This does not mean every leaf -- it can be per list or container if the author wants to do that. > Dan > > Andy > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of Phil Shafer >> Sent: Wednesday, April 14, 2010 11:48 PM >> To: Randy Presuhn >> Cc: NETMOD Working Group >> Subject: Re: [netmod] third draft for yang module security >> considerations >> >> "Randy Presuhn" writes: >> >>> I'd go so far as to say that if there's some bit of >>> >> configuration data >> >>> that is not deemed sensitive, the spec bears the burden of >>> >> explaining >> >>> why it's worth configuring. >>> >> If all config data is sensitive, then we don't need to burn >> words crawling thru the details for each node. In many cases >> explaining the attack scenarios or implications of a config >> error is a very complex task. For example, if the domain >> search list is not entered correctly, will my syslog data >> (IDP/SNMP/etc) get discarded? Or if the system location is >> not entered correctly, will my network fail if I turn off >> power to rack 13 after checking that nothing on rack 13 is >> needed anymore? How far down this road do we need to go? >> >> Perhaps we just need a more blanket statement like: >> >> Caveat Configurator: >> >> Configuring network equipment is inherently dangerous. Improper >> usage, manipulation, handling, storage, and transportation of >> configuration data create a risk of security-related issues. The >> chief concern is controlling access to the devices, but the >> configuration of the network will affect the ability of the network >> to function correctly, including reporting security-related issues. >> Configuration data must be dealt with correctly to allow the >> network to operate in a useful and secure manner. >> >> Please read the YANG module thoroughly before using, and consider >> the issues that can arise from improper configuration handling. >> Any specific issues with particular data nodes are described in >> the YANG module with the appropriate node definition. >> >> Thanks, >> Phil >> _______________________________________________ >> 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 dromasca@avaya.com Thu Apr 15 08:55: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 D0B103A698D for ; Thu, 15 Apr 2010 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 YzG4zuzixRGi for ; Thu, 15 Apr 2010 08:55:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8CD143A6767 for ; Thu, 15 Apr 2010 08:55:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,213,1270440000"; d="scan'208";a="184495753" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Apr 2010 11:55:28 -0400 X-IronPort-AV: E=Sophos;i="4.52,213,1270440000"; d="scan'208";a="451998757" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Apr 2010 11:55:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2010 17:55:07 +0200 Message-ID: In-Reply-To: <4BC734B5.4040802@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: Acrcsr1QDufvvufnQESttYn4DGb1GAAAIC+w References: <006301cadc0a$00a6de40$6801a8c0@oemcomputer> <201004142048.o3EKmFTU011402@idle.juniper.net> <4BC734B5.4040802@iwl.com> From: "Romascanu, Dan (Dan)" To: Cc: NETMOD Working Group Subject: Re: [netmod] third 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: Thu, 15 Apr 2010 15:55:37 -0000 =20 > -----Original Message----- > From: Andy Bierman [mailto:andyb@iwl.com]=20 > Sent: Thursday, April 15, 2010 6:46 PM > To: Romascanu, Dan (Dan) > Cc: Phil Shafer; Randy Presuhn; NETMOD Working Group > Subject: Re: [netmod] third draft for yang module security=20 > considerations >=20 > Romascanu, Dan (Dan) wrote: > > I doubt that a blanket statement like the one proposed=20 > below will ever=20 > > be approved by the security area experts. This goes against the=20 > > practice and guidance provided to authors of RFCs in the=20 > last decade=20 > > or maybe longer time which requires 'strong' security=20 > considerations=20 > > sections - see RFC 3552 (BCP 72). I think (and Bert should=20 > correct me=20 > > here if I am > > wrong) that the Security Considerations guidelines for MIB=20 > documents=20 > > were created by Bert and Steve Bellovin to help people writing MIB=20 > > documents implement the recommendations of RFC 3552 in a way that=20 > > makes sense for MIB modules. What we need is something similar for=20 > > YANG modules that can be written in a manner that does not create a=20 > > huge overhead for people writing, reading and deploying=20 > YANG modules. > > > > =20 >=20 > I remember the motivation for strong SMIv2 SC sections was to=20 > avoid having to read the entire MIB module to find out if=20 > there are any objects of interest. >=20 > I think listing the writable objects (in the SC section) is a=20 > good idea. > This does not mean every leaf -- it can be per list or=20 > container if the author wants to do that. >=20 I agree. This seems to me the best variant of those discussed until now and is similar to what we do in MIB documents. Dan From mbj@tail-f.com Fri Apr 16 01:37:41 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589FF3A6359 for ; Fri, 16 Apr 2010 01:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGoYf2WjC9XN for ; Fri, 16 Apr 2010 01:37:40 -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 E774C3A67CC for ; Fri, 16 Apr 2010 01:37:39 -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 D9118616001; Fri, 16 Apr 2010 10:37:31 +0200 (CEST) Date: Fri, 16 Apr 2010 10:37:30 +0200 (CEST) Message-Id: <20100416.103730.27882465.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1271235844.21600.179.camel@missotis> References: <1270802680.6878.13.camel@missotis> <20100413.235323.121809708.mbj@tail-f.com> <1271235844.21600.179.camel@missotis> 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] 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: Fri, 16 Apr 2010 08:37:41 -0000 I Lada, I think your changes are fine. See below for additional comments. Ladislav Lhotka wrote: > > You use the terms "conceptual data tree", "conceptual tree schema" and > > "conceptual tree" in many places in the document. Are they the same? > > If so, stick to one, if not, please defined the other meanings. > > "conceptual data tree" == "conceptual tree" > > I agree that this terminology is rather confusing, also because the > terms "data tree" and "conceptual" are used in the YANG draft. The idea > is as follows: > > Conceptual tree is an XML instance document such as the one shown in > sec. 8.1., and conceptual tree schema is the annotated RELAX NG schema > for this instance document. Ok, this is fine. > I'd appreciate any ideas how to make this setup more straightforward and > the description less complex. It is ok, just make sure you define both these terms in the terminology section, and taht you use these terms consistently. (I.e. remove the term conceptual data tree). > > ------------------------------------------------------------ > > > > Section 3. > > > > To this end, the complexity of the mapping is > > distributed into two steps: > > > > and then you list 3 steps 1-3...? > > I can only see two steps numbered 1 and 2, what do you mean? Sorry, I messed up my notes. This is in section 6: The mapping procedure is divided into two steps: ... and then you list 3 steps. > > Section 8.1. > > > > In general, these > > transformations should be relatively simple - they will typically > > > > s/should be/are/ ? > > The simplicity of course also depends on the tools used for the task. So > how about "The goal was to make these transformations relatively > straightforward - ..."? Ok. > > ------------------------------------------------------------ > > > > Section 10. > > > > I cannot see where the conceptual tree is actually defined. There is > > one example in 8.1 which shows the netmod-tree top-level container and > > its children, but no specification. > > The description is in the second paragraph of sec. 8.1, although > probably insufficient - see above. I think it is insufficient. The second paragraph describes in general terms what it is, but the structure is not defined. The structure shows up in the example in paragraph three. This is also related to the next comment. If section 8 is just for overview purposes, the conceptual tree schema needs to be defined in 9-11. > > Hmm, section 11 does this for substatements, but it doesn't define the > > top-level structure. Shouldn't chapter 11 go before this chapter? > > Sections 6-8 try to explain the big picture whereas sec. 11 gives a > detailed specification of how the individual YANG statements are mapped. > I think this order is essentially correct. 6-8 is fine. The order of 9-11 does not seem natural: 9. Mapping YANG Data Models to the Conceptual Tree Schema 10. Mapping Conceptual Tree Schema to DSDL 11. Mapping YANG Statements to Conceptual Tree Schema It seems as 9 and 11 belong together; both detail how to map from YANG to Conceptual Tree Schema. The next step is ho to map to DSDL; shouldn't that be described after 9 and 11? > > ------------------------------------------------------------ > > > > Section 10.2. > > > > The value of the mandatory @context attribute of (denoted > > as XELEM) MUST be set to the absolute path of the context element in > > the data tree. > > > > Is this term "data tree" really "conceptual data tree", or did you > > mean "data tree" as defined in YANG? (same for other occurances of > > this term). > > None of them, probably "target instance document" is appropriate here. > In the following example, the context value is > "/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:default-lease-time". How would you > call it? This is a pretty important piece of the whole YANG->DSDL puzzle, so it should have its own term. "target instance document" is fine. For example, in section 6 you say: 2. In the second step, the conceptual tree schema is transformed in multiple ways to a coordinated set of DSDL schemas that can be used for validating a particular data object in a specific context. > > ------------------------------------------------------------ > > > > Section 10.2.1. > > > > For > > example, a candidate configuration referring to configuration > > parameters or state data of certain hardware will not pass full > > validation before the hardware is installed. > > > > This is a somewhat controversial example. config data cannot refer to > > state data. Pick a simpler example, e.g. all leafreaf referential > > intergrity tests have to be true in a candidate configuration. > > OK. Actually, YANG defines validity only as full validity including the > referential integrity, so I am thinking about removing this phases stuff > from Schematron as well. Any opinions? There is one constraint which applies to all data trees / target instance docuements, and that is "key". All the others can be done in one single phase. /martin From mbj@tail-f.com Fri Apr 16 01:55:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E1D3A67EA for ; Fri, 16 Apr 2010 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.261 X-Spam-Level: X-Spam-Status: No, score=0.261 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=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 O6b280f2cUuv for ; Fri, 16 Apr 2010 01:55:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B9B463A6359 for ; Fri, 16 Apr 2010 01:55:28 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 768C8616001; Fri, 16 Apr 2010 10:55:21 +0200 (CEST) Date: Fri, 16 Apr 2010 10:55:21 +0200 (CEST) Message-Id: <20100416.105521.216498728.mbj@tail-f.com> To: dromasca@avaya.com From: Martin Bjorklund In-Reply-To: References: <4BC734B5.4040802@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] third 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: Fri, 16 Apr 2010 08:55:31 -0000 "Romascanu, Dan (Dan)" wrote: > > > > -----Original Message----- > > From: Andy Bierman [mailto:andyb@iwl.com] > > Sent: Thursday, April 15, 2010 6:46 PM > > To: Romascanu, Dan (Dan) > > Cc: Phil Shafer; Randy Presuhn; NETMOD Working Group > > Subject: Re: [netmod] third draft for yang module security > > considerations > > > > Romascanu, Dan (Dan) wrote: > > > I doubt that a blanket statement like the one proposed > > below will ever > > > be approved by the security area experts. This goes against the > > > practice and guidance provided to authors of RFCs in the > > last decade > > > or maybe longer time which requires 'strong' security > > considerations > > > sections - see RFC 3552 (BCP 72). I think (and Bert should > > correct me > > > here if I am > > > wrong) that the Security Considerations guidelines for MIB > > documents > > > were created by Bert and Steve Bellovin to help people writing MIB > > > documents implement the recommendations of RFC 3552 in a way that > > > makes sense for MIB modules. What we need is something similar for > > > YANG modules that can be written in a manner that does not create a > > > huge overhead for people writing, reading and deploying > > YANG modules. > > > > > > > > > > I remember the motivation for strong SMIv2 SC sections was to > > avoid having to read the entire MIB module to find out if > > there are any objects of interest. > > > > I think listing the writable objects (in the SC section) is a > > good idea. > > This does not mean every leaf -- it can be per list or > > container if the author wants to do that. > > > > I agree. This seems to me the best variant of those discussed until now > and is similar to what we do in MIB documents. Let me see if I understand this proposal correctly: All config true nodes MUST be listed in the SC section, but a container or list node can be listed, and if so, covers the entire subtree. In the SC section, the node is just mentioned by name, and the text describing the security concerns MUST be written in the YANG module (e.g. in the description statement). If this is the proposal, I still think it makes sense to put this security text in the nacm:secure and nacm:very-secure statements. If you don't like the text to be an argument to these statements, it could go into a description statement as a substement to nacm:secure/very-secure: nacm:secure { description "Modification of this node blah blah..."; } [This is similar to what we do with enum values - each enum has its own description statement, instead of describing them all in the node's description.] If we don't do this, it will be harder to find the text, and at best we'll end up with some convention for structure in the node's description statement, such as: description "blah blah... blah blah... Security Concerns Modification of this node blah blah... "; nacm:secure; /martin From lhotka@cesnet.cz Fri Apr 16 04:12: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 005C73A6B77 for ; Fri, 16 Apr 2010 04:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8HqiJ5-oayq for ; Fri, 16 Apr 2010 04:12:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id E66643A6B5C for ; Fri, 16 Apr 2010 04:11:27 -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 4EB0C2CDE059; Fri, 16 Apr 2010 13:11:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100416.103730.27882465.mbj@tail-f.com> References: <1270802680.6878.13.camel@missotis> <20100413.235323.121809708.mbj@tail-f.com> <1271235844.21600.179.camel@missotis> <20100416.103730.27882465.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 16 Apr 2010 13:11:17 +0200 Message-ID: <1271416278.8185.132.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [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: Fri, 16 Apr 2010 11:12:08 -0000 Martin Bjorklund píše v Pá 16. 04. 2010 v 10:37 +0200: > > I'd appreciate any ideas how to make this setup more straightforward and > > the description less complex. > > It is ok, just make sure you define both these terms in the > terminology section, and taht you use these terms > consistently. (I.e. remove the term conceptual data tree). Yup, I have to make up a replacement for this term, thinking about "hybrid schema". > > > > ------------------------------------------------------------ > > > > > > Section 3. > > > > > > To this end, the complexity of the mapping is > > > distributed into two steps: > > > > > > and then you list 3 steps 1-3...? > > > > I can only see two steps numbered 1 and 2, what do you mean? > > Sorry, I messed up my notes. This is in section 6: OK, I pulled item #3 out of the list and made it a separate paragraph. > > > ------------------------------------------------------------ > > > > > > Section 10. > > > > > > I cannot see where the conceptual tree is actually defined. There is > > > one example in 8.1 which shows the netmod-tree top-level container and > > > its children, but no specification. > > > > The description is in the second paragraph of sec. 8.1, although > > probably insufficient - see above. > > I think it is insufficient. The second paragraph describes in general > terms what it is, but the structure is not defined. The structure > shows up in the example in paragraph three. This is also related to > the next comment. If section 8 is just for overview purposes, the > conceptual tree schema needs to be defined in 9-11. I'll try to improve it. > > > > > Hmm, section 11 does this for substatements, but it doesn't define the > > > top-level structure. Shouldn't chapter 11 go before this chapter? > > > > Sections 6-8 try to explain the big picture whereas sec. 11 gives a > > detailed specification of how the individual YANG statements are mapped. > > I think this order is essentially correct. > > 6-8 is fine. > > The order of 9-11 does not seem natural: > > 9. Mapping YANG Data Models to the Conceptual Tree Schema > 10. Mapping Conceptual Tree Schema to DSDL > 11. Mapping YANG Statements to Conceptual Tree Schema > > It seems as 9 and 11 belong together; both detail how to map from YANG > to Conceptual Tree Schema. The next step is ho to map to DSDL; > shouldn't that be described after 9 and 11? OK, I moved current chapter 10 after 11. > > > > ------------------------------------------------------------ > > > > > > Section 10.2. > > > > > > The value of the mandatory @context attribute of (denoted > > > as XELEM) MUST be set to the absolute path of the context element in > > > the data tree. > > > > > > Is this term "data tree" really "conceptual data tree", or did you > > > mean "data tree" as defined in YANG? (same for other occurances of > > > this term). > > > > None of them, probably "target instance document" is appropriate here. > > In the following example, the context value is > > "/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:default-lease-time". How would you > > call it? > > This is a pretty important piece of the whole YANG->DSDL puzzle, so it > should have its own term. "target instance document" is fine. For > example, in section 6 you say: > > 2. In the second step, the conceptual tree schema is transformed in > multiple ways to a coordinated set of DSDL schemas that can be > used for validating a particular data object in a specific > context. > Right, all this has to use uniform term, so let's use "target instance document". > > > ------------------------------------------------------------ > > > > > > Section 10.2.1. > > > > > > For > > > example, a candidate configuration referring to configuration > > > parameters or state data of certain hardware will not pass full > > > validation before the hardware is installed. > > > > > > This is a somewhat controversial example. config data cannot refer to > > > state data. Pick a simpler example, e.g. all leafreaf referential > > > intergrity tests have to be true in a candidate configuration. > > > > OK. Actually, YANG defines validity only as full validity including the > > referential integrity, so I am thinking about removing this phases stuff > > from Schematron as well. Any opinions? > > There is one constraint which applies to all data trees / target > instance docuements, and that is "key". All the others can be done in > one single phase. Hmm, I am not sure we are talking about the same thing. In -05, Schematron schemas define two phases - "full" and "noref" - one of them has to be selected a priori for performing validation. The only difference between them is that the latter doesn't check referential integrity constraints related to leafref and instance-identifier types. My proposal is to use only "full" as it is the only concept of validity defined in YANG. Is "key" then anything special in this context? I don't think so. Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Apr 16 05:06:56 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 8777D3A67A6 for ; Fri, 16 Apr 2010 05:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgcbOhC5T8rq for ; Fri, 16 Apr 2010 05:06:55 -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 5BF1E3A69DD for ; Fri, 16 Apr 2010 05:01:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EFD2616001; Fri, 16 Apr 2010 14:01:02 +0200 (CEST) Date: Fri, 16 Apr 2010 14:01:01 +0200 (CEST) Message-Id: <20100416.140101.162524594.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1271416278.8185.132.camel@missotis> References: <1271235844.21600.179.camel@missotis> <20100416.103730.27882465.mbj@tail-f.com> <1271416278.8185.132.camel@missotis> 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] 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: Fri, 16 Apr 2010 12:06:56 -0000 > > > > ------------------------------------------------------------ > > > > > > > > Section 10.2.1. > > > > > > > > For > > > > example, a candidate configuration referring to configuration > > > > parameters or state data of certain hardware will not pass full > > > > validation before the hardware is installed. > > > > > > > > This is a somewhat controversial example. config data cannot refer to > > > > state data. Pick a simpler example, e.g. all leafreaf referential > > > > intergrity tests have to be true in a candidate configuration. > > > > > > OK. Actually, YANG defines validity only as full validity including the > > > referential integrity, so I am thinking about removing this phases stuff > > > from Schematron as well. Any opinions? > > > > There is one constraint which applies to all data trees / target > > instance docuements, and that is "key". All the others can be done in > > one single phase. > > Hmm, I am not sure we are talking about the same thing. In -05, > Schematron schemas define two phases - "full" and "noref" - one of them > has to be selected a priori for performing validation. The only > difference between them is that the latter doesn't check referential > integrity constraints related to leafref and instance-identifier types. > My proposal is to use only "full" as it is the only concept of validity > defined in YANG. Is "key" then anything special in this context? I don't > think so. If I understand this correctly, in order to check that keys are unique, I must run Schematron on the target instance document. If there is only one phase, it will check not only keys, but all other constraints as well. But if the target is candidate, I may want to check keys, but not the others. /martin From wjhns1@hardakers.net Fri Apr 16 05:51: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 799D928C139 for ; Fri, 16 Apr 2010 05:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YI0YNMfl+Fs for ; Fri, 16 Apr 2010 05:51: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 42C2128C36D for ; Fri, 16 Apr 2010 05:39:39 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id B9BC198204; Fri, 16 Apr 2010 05:39:31 -0700 (PDT) From: Wes Hardaker To: andyb@iwl.com Organization: Sparta References: <006301cadc0a$00a6de40$6801a8c0@oemcomputer> <201004142048.o3EKmFTU011402@idle.juniper.net> <4BC734B5.4040802@iwl.com> Date: Fri, 16 Apr 2010 05:39:31 -0700 In-Reply-To: <4BC734B5.4040802@iwl.com> (Andy Bierman's message of "Thu, 15 Apr 2010 08:45:57 -0700") 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: NETMOD Working Group Subject: Re: [netmod] third 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: Fri, 16 Apr 2010 12:51:25 -0000 >>>>> On Thu, 15 Apr 2010 08:45:57 -0700, Andy Bierman said: AB> I think listing the writable objects (in the SC section) is a good AB> idea. This does not mean every leaf -- it can be per list or AB> container if the author wants to do that. The important thing to document is not the actual items, IMHO, it's how they can be used and misused and the dangers imposed by allowed remote access to them. A list of writable objects xyz:thatAreBadlyNamed doesn't help anyone from any perspective get a notion of the security related to the module. A list of statements or grouping objects, as proposed, combined with statements saying "incorrectly authorized access to this tree would allow remote attackers to perform man-in-the-middle attacks of critical local network resources". Personally, I'd like to see each object in the tree documented by some blanket coverage (including read-only objects). But the blanket shouldn't be at the leaf level unless that's necessary for the discussion. The important thing isn't the objects, it's the security ramification of the objects. -- Wes Hardaker Cobham Analytic Solutions From andyb@iwl.com Fri Apr 16 06:42:49 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84133A68A3 for ; Fri, 16 Apr 2010 06:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HV2ZSINQbf6 for ; Fri, 16 Apr 2010 06:42:48 -0700 (PDT) Received: from smtp165.iad.emailsrvr.com (smtp165.iad.emailsrvr.com [207.97.245.165]) by core3.amsl.com (Postfix) with ESMTP id A4DA03A6BFA for ; Fri, 16 Apr 2010 06:36:28 -0700 (PDT) Received: from relay16.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 70A831B40F7; Fri, 16 Apr 2010 09:36:21 -0400 (EDT) Received: by relay16.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id E1FF61B4103; Fri, 16 Apr 2010 09:36:20 -0400 (EDT) Message-ID: <4BC867E8.5060504@iwl.com> Date: Fri, 16 Apr 2010 06:36:40 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Bjorklund References: <4BC734B5.4040802@iwl.com> <20100416.105521.216498728.mbj@tail-f.com> In-Reply-To: <20100416.105521.216498728.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] third draft for yang module security considerations 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, 16 Apr 2010 13:42:49 -0000 Martin Bjorklund wrote: > "Romascanu, Dan (Dan)" wrote: > >> >> >> >>> -----Original Message----- >>> From: Andy Bierman [mailto:andyb@iwl.com] >>> Sent: Thursday, April 15, 2010 6:46 PM >>> To: Romascanu, Dan (Dan) >>> Cc: Phil Shafer; Randy Presuhn; NETMOD Working Group >>> Subject: Re: [netmod] third draft for yang module security >>> considerations >>> >>> Romascanu, Dan (Dan) wrote: >>> >>>> I doubt that a blanket statement like the one proposed >>>> >>> below will ever >>> >>>> be approved by the security area experts. This goes against the >>>> practice and guidance provided to authors of RFCs in the >>>> >>> last decade >>> >>>> or maybe longer time which requires 'strong' security >>>> >>> considerations >>> >>>> sections - see RFC 3552 (BCP 72). I think (and Bert should >>>> >>> correct me >>> >>>> here if I am >>>> wrong) that the Security Considerations guidelines for MIB >>>> >>> documents >>> >>>> were created by Bert and Steve Bellovin to help people writing MIB >>>> documents implement the recommendations of RFC 3552 in a way that >>>> makes sense for MIB modules. What we need is something similar for >>>> YANG modules that can be written in a manner that does not create a >>>> huge overhead for people writing, reading and deploying >>>> >>> YANG modules. >>> >>>> >>>> >>> I remember the motivation for strong SMIv2 SC sections was to >>> avoid having to read the entire MIB module to find out if >>> there are any objects of interest. >>> >>> I think listing the writable objects (in the SC section) is a >>> good idea. >>> This does not mean every leaf -- it can be per list or >>> container if the author wants to do that. >>> >>> >> I agree. This seems to me the best variant of those discussed until now >> and is similar to what we do in MIB documents. >> > > Let me see if I understand this proposal correctly: > > All config true nodes MUST be listed in the SC section, but a > container or list node can be listed, and if so, covers the entire > subtree. > > In the SC section, the node is just mentioned by name, and the text > describing the security concerns MUST be written in the YANG module > (e.g. in the description statement). > > > If this is the proposal, I still think it makes sense to put this > security text in the nacm:secure and nacm:very-secure statements. If > you don't like the text to be an argument to these statements, it > could go into a description statement as a substement to > nacm:secure/very-secure: > > nacm:secure { > description > "Modification of this node blah blah..."; > } > > [This is similar to what we do with enum values - each enum has its > own description statement, instead of describing them all in the > node's description.] > > If we don't do this, it will be harder to find the text, and at best > we'll end up with some convention for structure in the node's > description statement, such as: > > But compilers are allowed to toss the entire nacm:secure extension statement. We need this text inside standard YANG statements. We should not micro-manage the description-stmt. We should enumerate what is supposed to be in there, but not any specific order or structure to the contents. Also, the nacm:secure and nacm:very-secure extensions have a specific meaning in NACM (read-only or no-access). They are not intended to be used in every node as a documentation mechanism. > description > "blah blah... > blah blah... > > Security Concerns > > Modification of this node blah blah... > "; > nacm:secure; > > > /martin > > Andy Andy From dromasca@avaya.com Sun Apr 18 07:22: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 B71BA3A6AB3 for ; Sun, 18 Apr 2010 07:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-l7bwvM+E8j for ; Sun, 18 Apr 2010 07:22:09 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 518B43A6AC4 for ; Sun, 18 Apr 2010 07:22:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,230,1270440000"; d="scan'208";a="12108772" 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; 18 Apr 2010 10:21:59 -0400 X-IronPort-AV: E=Sophos;i="4.52,230,1270440000"; d="scan'208";a="452666927" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Apr 2010 10:21:19 -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: Sun, 18 Apr 2010 16:21:10 +0200 Message-ID: In-Reply-To: <20100416.105521.216498728.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] third draft for yang module security considerations Thread-Index: AcrdQo31HQWZX7rPSUqSRLSrNU+N5gBvQh9w References: <4BC734B5.4040802@iwl.com> <20100416.105521.216498728.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" Cc: netmod@ietf.org Subject: Re: [netmod] third 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: Sun, 18 Apr 2010 14:22:14 -0000 =20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > > I agree. This seems to me the best variant of those discussed until=20 > > now and is similar to what we do in MIB documents. >=20 > Let me see if I understand this proposal correctly: >=20 > All config true nodes MUST be listed in the SC section, but a > container or list node can be listed, and if so, covers the entire > subtree. >=20 > In the SC section, the node is just mentioned by name, and the text > describing the security concerns MUST be written in the YANG module > (e.g. in the description statement). >=20 >=20 Actually I incline towards placing the text describing the security concerns in the Security Considerations section rather than overloading the YANG module.=20 Dan From andyb@iwl.com Sun Apr 18 09:21: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 3ED763A6805 for ; Sun, 18 Apr 2010 09:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.143, 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 8fjGQg4fZn5a for ; Sun, 18 Apr 2010 09:21:46 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by core3.amsl.com (Postfix) with ESMTP id 2754B3A68D7 for ; Sun, 18 Apr 2010 09:21:46 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E3DB43EF562; Sun, 18 Apr 2010 12:21:37 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A477A3EF49F; Sun, 18 Apr 2010 12:21:37 -0400 (EDT) Message-ID: <4BCB31C3.1070601@iwl.com> Date: Sun, 18 Apr 2010 09:22:27 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4BC734B5.4040802@iwl.com> <20100416.105521.216498728.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] third draft for yang module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 16:21:49 -0000 Romascanu, Dan (Dan) wrote: > > > >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> > > > >>> I agree. This seems to me the best variant of those discussed until >>> now and is similar to what we do in MIB documents. >>> >> Let me see if I understand this proposal correctly: >> >> All config true nodes MUST be listed in the SC section, but a >> container or list node can be listed, and if so, covers the entire >> subtree. >> >> In the SC section, the node is just mentioned by name, and the text >> describing the security concerns MUST be written in the YANG module >> (e.g. in the description statement). >> >> >> > > Actually I incline towards placing the text describing the security > concerns in the Security Considerations section rather than overloading > the YANG module. > > This is fine with me. We should optimize for the readers anyway. > Dan > > Andy From root@core3.amsl.com Mon Apr 19 00: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 B4C523A6ACD; Mon, 19 Apr 2010 00:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100419070001.B4C523A6ACD@core3.amsl.com> Date: Mon, 19 Apr 2010 00:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 07: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 : An NETCONF- and NETMOD-based Architecture for Network Management Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-05.txt Pages : 30 Date : 2010-04-18 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-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-arch-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-18235849.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Apr 20 10: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 D91E13A6B3F; Tue, 20 Apr 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100420170001.D91E13A6B3F@core3.amsl.com> Date: Tue, 20 Apr 2010 10:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-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: Tue, 20 Apr 2010 17: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 : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-04.txt Pages : 29 Date : 2010-04-20 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-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-yang-usage-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-20095833.I-D@ietf.org> --NextPart-- From andyb@iwl.com Tue Apr 20 10:16:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B55B3A69DC for ; Tue, 20 Apr 2010 10:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 EgADQEX6+Tfg for ; Tue, 20 Apr 2010 10:16:04 -0700 (PDT) Received: from smtp135.iad.emailsrvr.com (smtp135.iad.emailsrvr.com [207.97.245.135]) by core3.amsl.com (Postfix) with ESMTP id E6BB928C103 for ; Tue, 20 Apr 2010 10:15:42 -0700 (PDT) Received: from relay23.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B2A3A1B4BFB for ; Tue, 20 Apr 2010 13:15:33 -0400 (EDT) Received: by relay23.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 548C71B4BE8 for ; Tue, 20 Apr 2010 13:15:33 -0400 (EDT) Message-ID: <4BCDE183.3060302@iwl.com> Date: Tue, 20 Apr 2010 10:16:51 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: netmod@ietf.org References: <20100420170001.D91E13A6B3F@core3.amsl.com> In-Reply-To: <20100420170001.D91E13A6B3F@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-usage-04.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, 20 Apr 2010 17:16:05 -0000 Hi, Please review the latest YANG usage draft. I think I addressed all the review comments, except 1. I left description-stmt mandatory for body-stmts. I almost changed MUST to SHOULD, but didn't. It is a slippery slope to say that no description is needed because the object or grouping meaning is self-evident. It is too hard to write a guideline to determine if this is true or not. I introduced a dependency on the online security considerations text that Bert is working on. Refer to the change log for more details. Andy > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > > Title : Guidelines for Authors and Reviewers of YANG Data Model Documents > Author(s) : A. Bierman > Filename : draft-ietf-netmod-yang-usage-04.txt > Pages : 29 > Date : 2010-04-20 > > This memo provides guidelines for authors and reviewers of standards > track specifications containing YANG data model modules. Applicable > portions may be used as a basis for reviews of other YANG data model > documents. Recommendations and procedures are defined, which are > intended to increase interoperability and usability of NETCONF > implementations which utilize YANG data model modules. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-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. > > ------------------------------------------------------------------------ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From dromasca@avaya.com Wed Apr 21 07:37: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 A71C53A6C5A for ; Wed, 21 Apr 2010 07:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 HewgkOeiX1lT for ; Wed, 21 Apr 2010 07:37:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 146823A6C5E for ; Wed, 21 Apr 2010 07:07:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,250,1270440000"; d="scan'208";a="214548580" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Apr 2010 10:06:55 -0400 X-IronPort-AV: E=Sophos;i="4.52,250,1270440000"; d="scan'208";a="466554076" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Apr 2010 10:06:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 16:06:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG Deferred Ballot notification: draft-ietf-netmod-yang-12.txt Thread-Index: AcrhW7jlS7v7ernDSi6To/Rix0w18QAABzNA From: "Romascanu, Dan (Dan)" To: Subject: [netmod] FW: IESG Deferred Ballot notification: draft-ietf-netmod-yang-12.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, 21 Apr 2010 14:37:22 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of DraftTracker Mail System Sent: Wednesday, April 21, 2010 5:06 PM To: iesg@ietf.org Subject: IESG Deferred Ballot notification: draft-ietf-netmod-yang-12.txt Ballot of draft-ietf-netmod-yang-12.txt has been deferred by Alexey Melnikov. This ballot will be on IESG agenda of '2010-05-06' From dromasca@avaya.com Thu Apr 22 01:02: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 D34E33A6852; Thu, 22 Apr 2010 01:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 73io6PIhBMci; Thu, 22 Apr 2010 01:02:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id AE24728C151; Thu, 22 Apr 2010 01:00:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,255,1270440000"; d="scan'208";a="185425371" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Apr 2010 04:00:18 -0400 X-IronPort-AV: E=Sophos;i="4.52,255,1270440000"; d="scan'208";a="466802468" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Apr 2010 04:00:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 10:00:03 +0200 Message-ID: In-Reply-To: <4BCFC5A1.2060309@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd Thread-Index: AcrhzdkQ+ZdQqstYQ9uKxYB1wjCbIgAI2xwQ References: <20100421195749.6B3A83A6925@core3.amsl.com><056601cae1cb$a74f4040$0600a8c0@china.huawei.com> <4BCFC5A1.2060309@stpeter.im> From: "Romascanu, Dan (Dan)" To: "Peter Saint-Andre" , "David Harrington" Cc: draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org, iesg@ietf.org, netmod@ietf.org, opsawg-chairs@tools.ietf.org Subject: Re: [netmod] COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd 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, 22 Apr 2010 08:02:38 -0000 Copying the netmod crowd.=20 Is there any reason for the two representations to be different or to prefer one to the other?=20 Dan =20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Peter Saint-Andre > Sent: Thursday, April 22, 2010 6:42 AM > To: David Harrington > Cc: draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org;=20 > iesg@ietf.org; opsawg-chairs@tools.ietf.org > Subject: Re: COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd >=20 > On 4/21/10 9:26 PM, David Harrington wrote: > > The WG spent a number of iterations and a lot of analysis=20 > to get this=20 > > right. > > I would hesitate to modify it now, without going back to read the=20 > > threads that discussed it before. >=20 > OK. >=20 > I note in passing that draft-ietf-netmod-yang-types=20 > (currently also under review by the IESG) provides a=20 > different regexp for IPv4 address: >=20 > (([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?[0-9]?[0- > 9]|2[0-4][0-9]|25[0-5]) >=20 > It would be nice to have a consistent definition that we=20 > could re-use in IETF specifications... >=20 > /psa >=20 >=20 From j.schoenwaelder@jacobs-university.de Thu Apr 22 02:31: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 798C43A67DB; Thu, 22 Apr 2010 02:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.183 X-Spam-Level: X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s04qzFKLDAOA; Thu, 22 Apr 2010 02:31:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D07743A689D; Thu, 22 Apr 2010 02:31:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2075C0002; Thu, 22 Apr 2010 11:31:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id txc-Z9lbS7WL; Thu, 22 Apr 2010 11:31:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47CD9C0010; Thu, 22 Apr 2010 11:30:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6C23B11A3760; Thu, 22 Apr 2010 11:30:52 +0200 (CEST) Date: Thu, 22 Apr 2010 11:30:52 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100422093052.GC48431@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Peter Saint-Andre , David Harrington , "draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org" , "iesg@ietf.org" , "netmod@ietf.org" , "opsawg-chairs@tools.ietf.org" References: <20100421195749.6B3A83A6925@core3.amsl.com> <056601cae1cb$a74f4040$0600a8c0@china.huawei.com> <4BCFC5A1.2060309@stpeter.im> 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" , "opsawg-chairs@tools.ietf.org" , "iesg@ietf.org" , Peter Saint-Andre , "draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org" Subject: Re: [netmod] COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd 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, 22 Apr 2010 09:31:24 -0000 On Thu, Apr 22, 2010 at 10:00:03AM +0200, Romascanu, Dan (Dan) wrote: > Copying the netmod crowd. > > Is there any reason for the two representations to be different or to > prefer one to the other? There are two issues here we need to separate: First, the ipv4-address (yang-types) supports zone indexes which the ip-address (smi-datatypes) does not support since it sticks to the value range of the SMIv2 IpAddress type. This difference is on purpose. Second, the pattern for the IPv4 address portion is different. They were the same until January/February this year. Lada wrote a comment that some patterns are unnecessarily complex: http://www.ietf.org/mail-archive/web/netmod/current/msg04997.html I tried to address this by making the pattern shorter: http://www.ietf.org/mail-archive/web/netmod/current/msg04998.html Now, looking at these two pattern again with fresh eyes, I see that the ipv4-address (yang-types) pattern does allow leading zeros, which I think it should not. So I think by addressing Lada's comment, we introduced a bug (which is then also carried over to ipv4-prefix). So far the explanation what happened. (And my set of test cases did not catch the leading zeros.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Apr 22 03:04: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 E03393A689F; Thu, 22 Apr 2010 03:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O28J-j6AC5EY; Thu, 22 Apr 2010 03:04:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3E75E3A6804; Thu, 22 Apr 2010 03:04:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EB21C0016; Thu, 22 Apr 2010 12:04:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zl0nbUdJpxfa; Thu, 22 Apr 2010 12:04:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 824A1C000C; Thu, 22 Apr 2010 12:04:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B37AD11A39AD; Thu, 22 Apr 2010 12:04:37 +0200 (CEST) Date: Thu, 22 Apr 2010 12:04:37 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" , Peter Saint-Andre , David Harrington , "draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org" , "iesg@ietf.org" , "netmod@ietf.org" , "opsawg-chairs@tools.ietf.org" Message-ID: <20100422100437.GA49251@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Peter Saint-Andre , David Harrington , "draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org" , "iesg@ietf.org" , "netmod@ietf.org" , "opsawg-chairs@tools.ietf.org" References: <20100421195749.6B3A83A6925@core3.amsl.com> <056601cae1cb$a74f4040$0600a8c0@china.huawei.com> <4BCFC5A1.2060309@stpeter.im> <20100422093052.GC48431@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20100422093052.GC48431@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [netmod] COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd 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, 22 Apr 2010 10:04:56 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 22, 2010 at 11:30:52AM +0200, Juergen Schoenwaelder wrote: > So far the explanation what happened. (And my set of test cases did > not catch the leading zeros.) And here is a pattern that is reasonably short, relatively easy to understand (I hope) and hopefully does the right thing (remove the last line to omit the zone index part): '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' + '(%[\p{N}\p{L}]+)?' Attached is a python collection of test cases. Feel free to add test cases in an attempt to prove the pattern wrong... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipv4-gen.py" import libxml2 ipv4_pat = \ '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' \ + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' \ + '(%[\p{N}\p{L}]+)?'; ipv4_re = libxml2.regexpCompile(ipv4_pat) ipv4_good = ["192.0.2.1", "0.0.0.0", "0.10.100.0", "200.20.2.0", "189.201.222.99", "255.255.255.255", "192.0.2.1%1", "0.0.0.0%2", "255.255.255.255%3", "192.0.2.1%eth1", "0.0.0.0%en1", "255.255.255.255%lo"] ipv4_bad = ["321.1.2.3", "1.2.3.321", "1.2.3.4.5", "01.2.3.4", "1.2.3.04", "256.0.0.1", "0.0.1.256", "1.2.3.4%a%b"] for ip in ipv4_good: if ipv4_re.regexpExec(ip) != 1: print "** ipv4 pattern fails to accept %s" % ip for ip in ipv4_bad: if ipv4_re.regexpExec(ip) != 0: print "** ipv4 pattern fails to reject %s" % ip --AhhlLboLdkugWU4S-- From mark@ellisonsoftware.com Thu Apr 22 07:47: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 7202328C1DF; Thu, 22 Apr 2010 07:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmFbo9Cc9Q2g; Thu, 22 Apr 2010 07:46:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AB3DF28C202; Thu, 22 Apr 2010 07:42:40 -0700 (PDT) Received: by wwb24 with SMTP id 24so1325936wwb.31 for ; Thu, 22 Apr 2010 07:42:27 -0700 (PDT) MIME-Version: 1.0 Sender: mark@ellisonsoftware.com Received: by 10.216.3.70 with HTTP; Thu, 22 Apr 2010 07:42:26 -0700 (PDT) In-Reply-To: <20100422100437.GA49251@elstar.local> References: <20100421195749.6B3A83A6925@core3.amsl.com> <056601cae1cb$a74f4040$0600a8c0@china.huawei.com> <4BCFC5A1.2060309@stpeter.im> <20100422093052.GC48431@elstar.local> <20100422100437.GA49251@elstar.local> Date: Thu, 22 Apr 2010 10:42:27 -0400 X-Google-Sender-Auth: a62fb1bab07dd9ec Received: by 10.216.85.79 with SMTP id t57mr161780wee.132.1271947347059; Thu, 22 Apr 2010 07:42:27 -0700 (PDT) Message-ID: From: Mark Ellison To: Juergen Schoenwaelder , "Romascanu, Dan (Dan)" , Peter Saint-Andre , David Harrington , "draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org" , "iesg@ietf.org" , "netmod@ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=0016e6d96d28cb69ae0484d45199 Subject: Re: [netmod] COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd 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, 22 Apr 2010 14:47:00 -0000 --0016e6d96d28cb69ae0484d45199 Content-Type: text/plain; charset=ISO-8859-1 Hi, As one of the authors and not an expert in regular expressions, I am glad that Peter brought the IPv4 pattern issue to our attention. I think it would be a good thing to use the same pattern for the IPv4 address regular expression (without the zone portion) in draft-ietf-ipsawg-smi-datatypes-in-xsd as in draft-ietf-netmod-yang-types. If there are any regular expression experts able to verify the accuracy of the pattern provided below by Juergen it would be appreciated very much. I am in favor of updating the smi-datatypes-in-xsd draft to include the improved IPv4 pattern. Regards, Mark On Thu, Apr 22, 2010 at 6:04 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 22, 2010 at 11:30:52AM +0200, Juergen Schoenwaelder wrote: > > > So far the explanation what happened. (And my set of test cases did > > not catch the leading zeros.) > > And here is a pattern that is reasonably short, relatively easy to > understand (I hope) and hopefully does the right thing (remove the > last line to omit the zone index part): > > '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' > + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' > + '(%[\p{N}\p{L}]+)?' > Attached is a python collection of test cases. Feel free to add test > cases in an attempt to prove the pattern wrong... > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --0016e6d96d28cb69ae0484d45199 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

As one of the authors and not an expert in regular expressions, = I am glad that Peter brought the IPv4 pattern issue to our attention.
I think it would be a good thing to use the same pattern for the IPv4 add= ress regular expression (without the zone portion) in draft-ietf-ipsawg-smi= -datatypes-in-xsd as in draft-ietf-netmod-yang-types.

If there are any regular expression experts able to verify the accuracy= of the pattern provided below by Juergen it would be appreciated very much= .

I am in favor of updating the smi-datatypes-in-xsd draft to includ= e the improved IPv4 pattern.

Regards,

Mark


On Thu, Apr 22, 2010 at 6:04= AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de><= /span> wrote:
On Thu, Apr 22, 2010 at 11:30:52AM +0200, Juergen Schoenwaelder wrote:

> So far the explanation what happened. (And my set of test cases did > not catch the leading zeros.)

And here is a pattern that is reasonably short, relatively easy to understand (I hope) and hopefully does the right thing (remove the
last line to omit the zone index part):

=A0 =A0 =A0 =A0'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.)= {3}'
=A0 =A0 =A0+ =A0'([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])= 9;
=A0 =A0 =A0+ '(%[\p{N}\p{L}]+)?'
=A0
Attached is a python collection of test cases. Feel free to add test
cases in an attempt to prove the pattern wrong...

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>




--0016e6d96d28cb69ae0484d45199-- From stpeter@stpeter.im Thu Apr 22 09:26: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 B539D3A6A21; Thu, 22 Apr 2010 09:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 8Xvy-o6Eu6Te; Thu, 22 Apr 2010 09:26:54 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 05ECD3A6A59; Thu, 22 Apr 2010 09:23:30 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4893A40E15; Thu, 22 Apr 2010 10:23:19 -0600 (MDT) Message-ID: <4BD077F6.8020306@stpeter.im> Date: Thu, 22 Apr 2010 10:23:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Ellison References: <20100421195749.6B3A83A6925@core3.amsl.com> <056601cae1cb$a74f4040$0600a8c0@china.huawei.com> <4BCFC5A1.2060309@stpeter.im> <20100422093052.GC48431@elstar.local> <20100422100437.GA49251@elstar.local> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040804020006000806000600" X-Mailman-Approved-At: Thu, 22 Apr 2010 09:28:23 -0700 Cc: "netmod@ietf.org" , "draft-ietf-opsawg-smi-datatypes-in-xsd@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [netmod] COMMENT: draft-ietf-opsawg-smi-datatypes-in-xsd 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, 22 Apr 2010 16:26:58 -0000 This is a cryptographically signed message in MIME format. --------------ms040804020006000806000600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/22/10 8:42 AM, Mark Ellison wrote: > Hi, >=20 > As one of the authors and not an expert in regular expressions, I am > glad that Peter brought the IPv4 pattern issue to our attention. >=20 > I think it would be a good thing to use the same pattern for the IPv4 > address regular expression (without the zone portion) in > draft-ietf-ipsawg-smi-datatypes-in-xsd as in draft-ietf-netmod-yang-typ= es. Agreed. > If there are any regular expression experts able to verify the accuracy= > of the pattern provided below by Juergen it would be appreciated very m= uch. We could ask on the ietf@ietf.org list. :) --------------ms040804020006000806000600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQyMjE2MjMxOFowIwYJKoZIhvcNAQkEMRYEFKLyzfiI8GLbx9YJhIH8 hIfi8OiQMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEADfjayR2wnWf8ka3u4fPzTIQg3BZR4Ibg9ecLl+T7 DgXqxpksgnTjwJnvjh8FVStqaWBewqrQoz8IlVO1Rg9NpubItEFgTGBnBm4LL9HtNV/jzA3S KzT1pWKygB86vuUHyRHR5yqpSmL/Vb2GZFhGylEzw75VEWr4+I7+0V7l8iX4Pv7wtLkDcJFT mLdbr7POVSxMBBOqFXnB5yq6skW7duWEUHOpJeEVbXyXMIg/RpTP3fg0PfCJrKE4W9ByJA/M bfIuK4gRMA8eW6pPn7bMczl1X8VjJaNsLUoqJIhUM8A3MsWEbx/2nuDxiekptNIL+tExJKWb i4NJ1Q6j8MvaiwAAAAAAAA== --------------ms040804020006000806000600-- From dromasca@avaya.com Mon Apr 26 01:37: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 3934C3A68C4 for ; Mon, 26 Apr 2010 01:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_50=0.001, J_CHICKENPOX_14=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 eSg5KW5CCEJ5 for ; Mon, 26 Apr 2010 01:37: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 648083A6896 for ; Mon, 26 Apr 2010 01:37:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,272,1270440000"; d="scan'208";a="13151073" 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; 26 Apr 2010 04:37:44 -0400 X-IronPort-AV: E=Sophos;i="4.52,272,1270440000"; d="scan'208";a="454885260" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Apr 2010 04:37:14 -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, 26 Apr 2010 10:36:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-netmod-yang Thread-Index: AcrkwV6Jh/Pj9/XaTu25Fs8wRcUevQAWjx6w From: "Romascanu, Dan (Dan)" To: Subject: [netmod] FW: DISCUSS and COMMENT: draft-ietf-netmod-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:37:59 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Monday, April 26, 2010 12:51 AM To: iesg@ietf.org Cc: netmod-chairs@tools.ietf.org; draft-ietf-netmod-yang@tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-netmod-yang=20 Discuss: [I reviewed the whole document, except for the ABNF section. I haven't reviewed reply to my original DUSCUSS yet. Note that I also have a list of other possible comments I need to check, so expect an update.] This is a well written document, a pleasure to read. Thank you. However I did find some things that I would like to discuss before recommending approval of this document: 1) 5.1. Modules and Submodules The names of all standard modules and submodules MUST be unique. Developers of enterprise modules are RECOMMENDED to choose names for (Similar text in several other sections, e.g. 7.1, 7.2) Why RECOMMENDED and not a MUST here? I.e. what is a good reason to violate this and to choose conflicting names? their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. 2) 5.2. File Layout YANG modules and submodules are typically stored in files, one module or submodule per file. The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) Does this mean that 2 new MIME media types should be registered? If yes, I can help you create the registration templates. 3) 6.1.3. Quoting If the double quoted string contains a line break followed by space or tab characters which are used to indent the text according to the Does a tab character correspond to a fixed number of spaces? If yes, how many? layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the double quote character, or to the first non-whitespace character, whichever occurs first. 4) 7.1. The module Statement A module SHOULD have the following layout: Why SHOULD here? What is the significance of the recommended layout and how does it benefit an implementation? Parsers can't rely on this SHOULD, so they will have to implement any allowed ordering. (Similar text in Section 7.2). -----------New text-------------- 5) 7.7.1. Ordering YANG supports two styles for ordering the entries within lists and leaf-lists. In many lists, the order of list entries does not impact the implementation of the list's configuration, and the device is free to sort the list entries in any reasonable order. The "description" string for the list may suggest an order. Are you sure you meant "description" here? YANG calls this style of list "system ordered" and they are indicated with the statement "ordered-by system". 6) 7.10.2. XML Mapping Rules An anyxml node is encoded as an XML element. The element's local name is the anyxml's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). The value of the anyxml node is encoded as XML content of this element. and 7.10.4. Usage Example Given the following anyxml statement: anyxml data; The following are two valid encodings of the same anyxml value: 1 I don't see where the payload ("...") is specified in the example. It looks that either your example is incorrect, or the description of anyxml is incorrect. Of course I can be wrong as well. 7) 7.19.2. The status Statement If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module. If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module. What does it mean to reference a definition? Can you show an example demonstrating use of this statement? 8) 7.19.4. The reference Statement The "reference" statement takes as an argument a string which is used to specify a textual cross-reference to an external document, either another module which defines related management information, or a document which provides additional information relevant to this definition. What do you call a "reference" here? Is a URI a reference? 9) 9.6.4. The enum Statement The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of control codes SHOULD be avoided. How do you define a "control code"? 10) 9.8.2. Lexicographic Representation Binary values are encoded with the base64 encoding scheme [RFC4648]. You need to specify the alphabet used (there are 2 different ones defined in RFC 4648). 11) In Section 12: ;; statment keywords anyxml-keyword =3D 'anyxml' argument-keyword =3D 'argument' augment-keyword =3D 'augment' <'> is not allowed in ABNF. 12) 14. IANA Considerations o a reference to the (sub)module's documentation (the RFC number) [...] 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. How can "iana-" be used if all modules require an RFC? 13) 9.4. The string Built-in Type The string built-in type represents human readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]: ;; any Unicode character, excluding the surrogate blocks, ;; FFFE, and FFFF. (Comment) This comment is not quite correct - it doesn't mention exclusded ASCII control characters (at least some of them). string =3D *char char =3D %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / %x10000-10FFFF Surrogate pairs are between U+D800 and U+DFFF. They are not excluded above. Comment: 4.2.2.1. Leaf Nodes A leaf node contains simple data like an integer or a string. It has exactly one value of a particular type, and no child nodes. YANG Example: leaf host-name { type string; description "Hostname for this system"; } NETCONF XML Example: my.example.com This and other examples got me confused. First, the document says that 1 representation can be converted to the other one without loss of data, but then the example doesn't show "description". 7.1.6. The include Statement When the optional "revision-date" is present, the specified revision of the submodule is included in the module. What would happen if a specific revision is included, but the submodule doesn't contain any revision? I assume that would be an error, but I am wondering if it is worth calling this out explicitly. (Similar comment for "import".) Otherwise, it is undefined which revision of the submodule is included. -------New comments---------- 7.5.3. The must Statement The "must" statement, which is optional, takes as an argument a string which contains an XPath expression. I think this needs a reference to a section defining XPath expressions. 7.10. The anyxml Statement An anyxml node cannot be augmented. A reference to where augmented is defined would be useful. Or instead say something like: An anyxml node cannot be augmented using the ... statement. 7.18.1. The feature Statement The "feature" statement is used to define a mechanism by which portions of the schema are marked as conditional. A feature name is defined that can later be referenced using the "if-feature" statement (see Section 7.18.2). Schema nodes tagged with a feature are ignored unless the device supports the given feature. Does this mean that nodes with if-feature are also ignored (can be omitted) in YIN representation? If a feature is dependent on any other features (i.e., the feature has one or more "if-feature" sub-statements), then all of features it depends on MUST also be implemented by the device. I think you meant to say that if one of "if-feature" statements of a feature is not implemented by a device, then the device can't implement the feature. 9.4.4. The length Statement The "length" statement, which is an optional substatement to the "type" statement, takes as an argument a length expression string. It is used to restrict the built-in type "string", or types derived from "string". A "length" statement restricts the number of characters in the number of *Unicode* characters string. In Section 12: ;; ;; RFC 4234 core rules. ;; s/4234/5234 From root@core3.amsl.com Mon Apr 26 03: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 EA82528C0EA; Mon, 26 Apr 2010 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100426100001.EA82528C0EA@core3.amsl.com> Date: Mon, 26 Apr 2010 03:00:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-types-09.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, 26 Apr 2010 10:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-yang-types-09.txt Pages : 31 Date : 2010-04-26 This document introduces a collection of common data types to be used with the YANG data modeling language. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-types-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-yang-types-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-26024944.I-D@ietf.org> --NextPart-- From bertietf@bwijnen.net Tue Apr 27 00:51:05 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628C33A6858 for ; Tue, 27 Apr 2010 00:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.195 X-Spam-Level: *** X-Spam-Status: No, score=3.195 tagged_above=-999 required=5 tests=[AWL=-2.461, BAYES_99=3.5, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhMOgKGlPF89 for ; Tue, 27 Apr 2010 00:51:04 -0700 (PDT) Received: from relay.versatel.net (relay58.tele2.vuurwerk.nl [62.250.3.58]) by core3.amsl.com (Postfix) with ESMTP id 337603A681F for ; Tue, 27 Apr 2010 00:51:03 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1O6fZC-0003eh-MZ for netmod@ietf.org; Tue, 27 Apr 2010 09:50:50 +0200 Message-ID: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "NETMOD Working Group" Date: Tue, 27 Apr 2010 09:50:09 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Subject: [netmod] 4th 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, 27 Apr 2010 07:51:05 -0000 We had quite a few discussions on the 3rd revision. >From my reading however, it seems we more or less agree that: - security considerations must be listed in the SC section and not in a separtely tagged description clause with the nodes themselves. - we cannot do a blanket statement that basically ALL config data is sensitive - it is OK toi list a container or node list if all the leaves have the sanme/similar secuirty considereations. Based on that, I think it is best to make that last point more explicit. I basically had that, but I was still using the MIB term of "subtrees". So the 4th revision (last??) of the template-text would be as follows: ---- Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then it the security considerations of each new RPC operation MUST be explained. Note: it is best to list a container or list node if all the leaves in the container or list node share the same or similar security considerations. 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 containers, list nodes and data nodes with their specific sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. These are the containers, list nodes and data nodes with their specific sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: From andyb@iwl.com Tue Apr 27 01:19:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131143A6802 for ; Tue, 27 Apr 2010 01:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_50=0.001, 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 IYxzEwsuL-DF for ; Tue, 27 Apr 2010 01:19:14 -0700 (PDT) Received: from smtp165.iad.emailsrvr.com (smtp165.iad.emailsrvr.com [207.97.245.165]) by core3.amsl.com (Postfix) with ESMTP id 43C303A6834 for ; Tue, 27 Apr 2010 01:19:12 -0700 (PDT) Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id DB7411B47ED; Tue, 27 Apr 2010 04:18:59 -0400 (EDT) Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 737AE1B4048; Tue, 27 Apr 2010 04:18:59 -0400 (EDT) Message-ID: <4BD69E16.4040400@iwl.com> Date: Tue, 27 Apr 2010 01:19:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> In-Reply-To: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] 4th draft for yang module security considerations 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, 27 Apr 2010 08:19:16 -0000 Bert Wijnen (IETF) wrote: > We had quite a few discussions on the 3rd revision. >> From my reading however, it seems we more or less agree that: > > - security considerations must be listed in the SC section and > not in a separtely tagged description clause with the nodes themselves. > - we cannot do a blanket statement that basically ALL config data > is sensitive > - it is OK toi list a container or node list if all the leaves have > the sanme/similar secuirty considereations. > Based on that, I think it is best to make that last point more explicit. > I basically had that, but I was still using the MIB term of "subtrees". > So the 4th revision (last??) of the template-text would be as > follows: > This is fine, but there is no 'perfect' answer, no matter where the text is placed. Since YANG modules (like MIB modules) are often extracted from RFCs, and the SC section is not part of the extracted module, there is a risk operators will not see this text. Andy > ---- > > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). > > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. > > Further, if new RPC operations have been defined, > then it the security considerations of each new > RPC operation MUST be explained. > > Note: it is best to list a container or list node if all the > leaves in the container or list node share the same > or similar security considerations. > > 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 containers, list nodes and data nodes with their specific > sensitivity/vulnerability: > > > > -- for all YANG modules you must evaluate whether any readable data > -- nodes (those are all the "config false" nodes, but also all other > -- nodes, because they can also be read via operations like get or > -- get-config) are sensitive or vulnerable (for instance, if they > -- might reveal customer information or violate personal privacy > -- laws such as those of the European Union if exposed to > -- unauthorized parties) > > Some of the readable data nodes in this YANG module may be > considered sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, > get-config or notification) to these data nodes. These are the > containers, list nodes and data nodes with their specific > sensitivity/vulnerability: > > > > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. > > Some of the RPC operations in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control access to these operations. These are the > operations and their sensitivity/vulnerability: > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From dromasca@avaya.com Tue Apr 27 01:35:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2163A6929 for ; Tue, 27 Apr 2010 01:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 8Ir2RBi-WODH for ; Tue, 27 Apr 2010 01:35:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D78133A687E for ; Tue, 27 Apr 2010 01:35:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="215334662" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Apr 2010 04:35:07 -0400 X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="468055436" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2010 04:35:06 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 10:35:04 +0200 Message-ID: In-Reply-To: <4BD69E16.4040400@iwl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] 4th draft for yang module security considerations Thread-Index: Acrl4lCYeybbVJ18SUaLWPzOZuEEPAAAgakg References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> <4BD69E16.4040400@iwl.com> From: "Romascanu, Dan (Dan)" To: , "Bert Wijnen (IETF)" Cc: NETMOD Working Group Subject: Re: [netmod] 4th 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, 27 Apr 2010 08:35:31 -0000 =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >=20 > Since YANG modules (like MIB modules) are often extracted=20 > from RFCs, and the SC section is not part of the extracted=20 > module, there is a risk operators will not see this text. >=20 >=20 > Andy >=20 > Indeed, but the same risk exists for MIB modules and is assumed by the community for a number of years.=20 I believe that this is acceptable.=20 Dan From dromasca@avaya.com Tue Apr 27 01:35:53 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091833A690F for ; Tue, 27 Apr 2010 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plXElEHYX9SW for ; Tue, 27 Apr 2010 01:35:52 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A85C43A6934 for ; Tue, 27 Apr 2010 01:35:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="186053063" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Apr 2010 04:35:35 -0400 X-IronPort-AV: E=Sophos;i="4.52,279,1270440000"; d="scan'208";a="468055541" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2010 04:35:34 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 10:35:22 +0200 Message-ID: In-Reply-To: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] 4th draft for yang module security considerations Thread-Index: Acrl3mLbI35Oe9gTSviLRwRPzz8XcwABimAw References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "NETMOD Working Group" Subject: Re: [netmod] 4th 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, 27 Apr 2010 08:35:53 -0000 This looks OK to me.=20 Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Tuesday, April 27, 2010 10:50 AM > To: NETMOD Working Group > Subject: [netmod] 4th draft for yang module security considerations >=20 > We had quite a few discussions on the 3rd revision. > From my reading however, it seems we more or less agree that: >=20 > - security considerations must be listed in the SC section and > not in a separtely tagged description clause with the nodes > themselves. > - we cannot do a blanket statement that basically ALL config data > is sensitive > - it is OK toi list a container or node list if all the leaves have > the sanme/similar secuirty considereations.=20 >=20 > Based on that, I think it is best to make that last point=20 > more explicit. > I basically had that, but I was still using the MIB term of=20 > "subtrees". > So the 4th revision (last??) of the template-text would be as > follows: >=20 > ---- >=20 > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). >=20 > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > =20 > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. >=20 > Further, if new RPC operations have been defined, > then it the security considerations of each new > RPC operation MUST be explained. >=20 > Note: it is best to list a container or list node if all the > leaves in the container or list node share the same > or similar security considerations. >=20 > X. Security Considerations > =20 > -- if you have any writeable data nodes (those are all the > -- "config true" nodes, and remember, that is the default) > -- describe their specific sensitivity or vulnerability. >=20 > There are a number of data nodes defined in this YANG module=20 > which are writable/creatable/deletable (i.e. config true,=20 > which is the default). These data nodes may be considered=20 > sensitive or vulnerable in some network environments. Write=20 > operations (e.g. edit-config) to these data nodes without=20 > proper protection can have a negative effect on network=20 > operations. These are the containers, list nodes and data=20 > nodes with their specific > sensitivity/vulnerability: >=20 > are sensitive> > =20 > -- for all YANG modules you must evaluate whether any readable data > -- nodes (those are all the "config false" nodes, but also all other > -- nodes, because they can also be read via operations like get or > -- get-config) are sensitive or vulnerable (for instance, if they > -- might reveal customer information or violate personal privacy > -- laws such as those of the European Union if exposed to > -- unauthorized parties) >=20 > Some of the readable data nodes in this YANG module may be=20 > considered sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get,=20 > get-config or notification) to these data nodes. These are=20 > the containers, list nodes and data nodes with their specific > sensitivity/vulnerability: >=20 > are sensitive> > =20 > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. >=20 > Some of the RPC operations in this YANG module may be=20 > considered sensitive or vulnerable in some network=20 > environments. It is thus important to control access to=20 > these operations. These are the operations and their=20 > sensitivity/vulnerability: >=20 > > =20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mehmet.ersue@nsn.com Tue Apr 27 02:08: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 35AF53A684F for ; Tue, 27 Apr 2010 02:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVNowXZCVzf9 for ; Tue, 27 Apr 2010 02:08:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id CAAD03A69DE for ; Tue, 27 Apr 2010 02:07:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3R97VFD027179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Apr 2010 11:07:31 +0200 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 o3R97UBO001497; Tue, 27 Apr 2010 11:07:30 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 11:07:30 +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: Tue, 27 Apr 2010 11:07:27 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6476ECA9@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] 4th draft for yang module security considerations Thread-Index: Acrl3mLbI35Oe9gTSviLRwRPzz8XcwABimAwAAEZyzA= References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "Bert Wijnen (IETF)" , "ext Mark Scott" X-OriginalArrivalTime: 27 Apr 2010 09:07:30.0730 (UTC) FILETIME=[10E898A0:01CAE5E9] Cc: NETMOD Working Group Subject: Re: [netmod] 4th 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, 27 Apr 2010 09:08:08 -0000 +1 Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Romascanu, Dan (Dan) > Sent: Tuesday, April 27, 2010 10:35 AM > To: Bert Wijnen (IETF); NETMOD Working Group > Subject: Re: [netmod] 4th draft for yang module security=20 > considerations >=20 > This looks OK to me.=20 >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: netmod-bounces@ietf.org=20 > > [mailto:netmod-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > > Sent: Tuesday, April 27, 2010 10:50 AM > > To: NETMOD Working Group > > Subject: [netmod] 4th draft for yang module security considerations > >=20 > > We had quite a few discussions on the 3rd revision. > > From my reading however, it seems we more or less agree that: > >=20 > > - security considerations must be listed in the SC section and > > not in a separtely tagged description clause with the nodes > > themselves. > > - we cannot do a blanket statement that basically ALL config data > > is sensitive > > - it is OK toi list a container or node list if all the leaves have > > the sanme/similar secuirty considereations.=20 > >=20 > > Based on that, I think it is best to make that last point=20 > > more explicit. > > I basically had that, but I was still using the MIB term of=20 > > "subtrees". > > So the 4th revision (last??) of the template-text would be as > > follows: > >=20 > > ---- > >=20 > > Each specification that defines one or more YANG > > modules MUST contain a section that discusses > > security considerations relevant to those modules. > > This section MUST be patterned after the latest > > approved template (available at [ed: URL TBD]). > >=20 > > In particular, writable data nodes that could > > be especially disruptive if abused MUST be > > explicitly listed by name and the associated > > security risks MUST be spelled out. > > =20 > > Similarly, readable data nodes that contain > > especially sensitive information or that raise > > significant privacy concerns MUST be explicitly > > listed by name and the reasons for the > > sensitivity/privacy concerns MUST be explained. > >=20 > > Further, if new RPC operations have been defined, > > then it the security considerations of each new > > RPC operation MUST be explained. > >=20 > > Note: it is best to list a container or list node if all the > > leaves in the container or list node share the same > > or similar security considerations. > >=20 > > X. Security Considerations > > =20 > > -- if you have any writeable data nodes (those are all the > > -- "config true" nodes, and remember, that is the default) > > -- describe their specific sensitivity or vulnerability. > >=20 > > There are a number of data nodes defined in this YANG module=20 > > which are writable/creatable/deletable (i.e. config true,=20 > > which is the default). These data nodes may be considered=20 > > sensitive or vulnerable in some network environments. Write=20 > > operations (e.g. edit-config) to these data nodes without=20 > > proper protection can have a negative effect on network=20 > > operations. These are the containers, list nodes and data=20 > > nodes with their specific > > sensitivity/vulnerability: > >=20 > > > are sensitive> > > =20 > > -- for all YANG modules you must evaluate whether any readable data > > -- nodes (those are all the "config false" nodes, but also all other > > -- nodes, because they can also be read via operations like get or > > -- get-config) are sensitive or vulnerable (for instance, if they > > -- might reveal customer information or violate personal privacy > > -- laws such as those of the European Union if exposed to > > -- unauthorized parties) > >=20 > > Some of the readable data nodes in this YANG module may be=20 > > considered sensitive or vulnerable in some network environments. > > It is thus important to control read access (e.g. via get,=20 > > get-config or notification) to these data nodes. These are=20 > > the containers, list nodes and data nodes with their specific > > sensitivity/vulnerability: > >=20 > > > are sensitive> > > =20 > > -- if your YANG module has defined any rpc operations > > -- describe their specific sensitivity or vulnerability. > >=20 > > Some of the RPC operations in this YANG module may be=20 > > considered sensitive or vulnerable in some network=20 > > environments. It is thus important to control access to=20 > > these operations. These are the operations and their=20 > > sensitivity/vulnerability: > >=20 > > > > =20 > >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mark@ellisonsoftware.com Tue Apr 27 10:27: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 8EEDE3A6B6A for ; Tue, 27 Apr 2010 10:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.374 X-Spam-Level: X-Spam-Status: No, score=-100.374 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRh5oe6I8un2 for ; Tue, 27 Apr 2010 10:27:45 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3E9983A6B5E for ; Tue, 27 Apr 2010 10:27:29 -0700 (PDT) Received: by wyb35 with SMTP id 35so3819366wyb.31 for ; Tue, 27 Apr 2010 10:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.87.75 with SMTP id x53mr2199540wee.144.1272389232722; Tue, 27 Apr 2010 10:27:12 -0700 (PDT) Sender: mark@ellisonsoftware.com Received: by 10.216.3.70 with HTTP; Tue, 27 Apr 2010 10:27:12 -0700 (PDT) In-Reply-To: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> Date: Tue, 27 Apr 2010 13:27:12 -0400 X-Google-Sender-Auth: 1f9f3287fe3e32d9 Message-ID: From: Mark Ellison To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=0016e6db29b53bc1bb04853b3474 Cc: NETMOD Working Group Subject: Re: [netmod] 4th 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, 27 Apr 2010 17:27:46 -0000 --0016e6db29b53bc1bb04853b3474 Content-Type: text/plain; charset=ISO-8859-1 Bert, One minor editorial nit in the following: > Further, if new RPC operations have been defined, > then it the security considerations of each new > RPC operation MUST be explained. s/then it the/then the/ Regards, Mark On Tue, Apr 27, 2010 at 3:50 AM, Bert Wijnen (IETF) wrote: > We had quite a few discussions on the 3rd revision. > From my reading however, it seems we more or less agree that: > > - security considerations must be listed in the SC section and > not in a separtely tagged description clause with the nodes themselves. > - we cannot do a blanket statement that basically ALL config data > is sensitive > - it is OK toi list a container or node list if all the leaves have > the sanme/similar secuirty considereations. > Based on that, I think it is best to make that last point more explicit. > I basically had that, but I was still using the MIB term of "subtrees". > So the 4th revision (last??) of the template-text would be as > follows: > > ---- > > Each specification that defines one or more YANG > modules MUST contain a section that discusses > security considerations relevant to those modules. > This section MUST be patterned after the latest > approved template (available at [ed: URL TBD]). > > In particular, writable data nodes that could > be especially disruptive if abused MUST be > explicitly listed by name and the associated > security risks MUST be spelled out. > > Similarly, readable data nodes that contain > especially sensitive information or that raise > significant privacy concerns MUST be explicitly > listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. > > Further, if new RPC operations have been defined, > then it the security considerations of each new > RPC operation MUST be explained. > > Note: it is best to list a container or list node if all the > leaves in the container or list node share the same > or similar security considerations. > > 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 containers, list nodes and data nodes with their specific > sensitivity/vulnerability: > > > > -- for all YANG modules you must evaluate whether any readable data > -- nodes (those are all the "config false" nodes, but also all other > -- nodes, because they can also be read via operations like get or > -- get-config) are sensitive or vulnerable (for instance, if they > -- might reveal customer information or violate personal privacy > -- laws such as those of the European Union if exposed to > -- unauthorized parties) > > Some of the readable data nodes in this YANG module may be > considered sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, > get-config or notification) to these data nodes. These are the > containers, list nodes and data nodes with their specific > sensitivity/vulnerability: > > > > -- if your YANG module has defined any rpc operations > -- describe their specific sensitivity or vulnerability. > > Some of the RPC operations in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control access to these operations. These are the > operations and their sensitivity/vulnerability: > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0016e6db29b53bc1bb04853b3474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bert,

One minor editorial nit in the following:

> Further,= if new RPC operations have been defined,
> then it the security considerations of each new
> RPC operation MUST be explained.

s/then it the/then the/
Regards,

Mark

On Tue, Apr 27, 201= 0 at 3:50 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:
We had quite a fe= w discussions on the 3rd revision.
>From my reading however, it seems we more or less agree that:

- security considerations must be listed in the SC section and
=A0not in a separtely tagged description clause with the nodes =A0themselve= s.
- we cannot do a blanket statement that basically ALL config data
=A0is sensitive
- it is OK toi list a container or node list if all the leaves have
=A0the sanme/similar secuirty considereations.
Based on that, I think it is best to make that last point more explicit. I basically had that, but I was still using the MIB term of "subtrees&= quot;.
So the 4th revision (last??) of the template-text would be as
follows:

----

=A0Each specification that defines one or more YANG
=A0modules MUST contain a section that discusses
=A0security considerations relevant to those modules.
=A0This section MUST be patterned after the latest
=A0approved template (available at [ed: URL TBD]).

=A0In particular, writable data nodes that could
=A0be especially disruptive if abused MUST be
=A0explicitly listed by name and the associated
=A0security risks MUST be spelled out.

=A0Similarly, readable data nodes that contain
=A0especially sensitive information or that raise
=A0significant privacy concerns MUST be explicitly
=A0listed by name and the reasons for the
=A0sensitivity/privacy concerns MUST be explained.

=A0Further, if new RPC operations have been defined,
=A0then it the security considerations of each new
=A0RPC operation MUST be explained.

=A0Note: it is best to list a container or list node if all the
=A0leaves in the container or list node share the same
=A0or similar security considerations.

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). =A0These data nodes may be considered sensitive
or vulnerable in some network environments. =A0Write operations
(e.g. edit-config) to these data nodes without proper protection
can have a negative effect on network operations. =A0These are
the containers, list nodes and data nodes with their specific
sensitivity/vulnerability:

<list containers, list nodes or data nodes, state why they are sensitive= >

-- for all YANG modules you must evaluate whether any readable data
-- nodes (those are all the "config false" nodes, but also all ot= her
-- nodes, because they can also be read via operations like get or
-- get-config) are sensitive or vulnerable (for instance, if they
-- might reveal customer information or violate personal privacy
-- laws such as those of the European Union if exposed to
-- unauthorized parties)

Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g. via get,
get-config or notification) to these data nodes. =A0These are the
containers, list nodes and data nodes with their specific
sensitivity/vulnerability:

<list containers, list nodes or data nodes, state why they are sensitive= >

-- if your YANG module has defined any rpc operations
-- describe their specific sensitivity or vulnerability.

Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. =A0It is thus
important to control access to these operations. =A0These are the
operations and their sensitivity/vulnerability:

<list RPC operations and state why they are sensitive>


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



--0016e6db29b53bc1bb04853b3474-- From bertietf@bwijnen.net Tue Apr 27 11:09: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 2DC493A6B87 for ; Tue, 27 Apr 2010 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.798 X-Spam-Level: * X-Spam-Status: No, score=1.798 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, 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 mdtJ9ybwPTmR for ; Tue, 27 Apr 2010 11:09:14 -0700 (PDT) Received: from relay.versatel.net (relay58.tele2.vuurwerk.nl [62.250.3.58]) by core3.amsl.com (Postfix) with ESMTP id 572863A6A61 for ; Tue, 27 Apr 2010 11:08:55 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1O6pD8-0001mj-0v; Tue, 27 Apr 2010 20:08:42 +0200 Message-ID: <43447B97F09044418C553FBF37EFB291@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Mark Ellison" References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> In-Reply-To: Date: Tue, 27 Apr 2010 20:04:22 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Cc: NETMOD Working Group Subject: Re: [netmod] 4th 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, 27 Apr 2010 18:09:15 -0000 Yep. Thanks Mark. Bert ----- Original Message ----- From: "Mark Ellison" To: "Bert Wijnen (IETF)" Cc: "NETMOD Working Group" Sent: Tuesday, April 27, 2010 7:27 PM Subject: Re: [netmod] 4th draft for yang module security considerations > Bert, > > One minor editorial nit in the following: > >> Further, if new RPC operations have been defined, >> then it the security considerations of each new >> RPC operation MUST be explained. > > s/then it the/then the/ > > Regards, > > Mark > > On Tue, Apr 27, 2010 at 3:50 AM, Bert Wijnen (IETF) > wrote: > >> We had quite a few discussions on the 3rd revision. >> From my reading however, it seems we more or less agree that: >> >> - security considerations must be listed in the SC section and >> not in a separtely tagged description clause with the nodes themselves. >> - we cannot do a blanket statement that basically ALL config data >> is sensitive >> - it is OK toi list a container or node list if all the leaves have >> the sanme/similar secuirty considereations. >> Based on that, I think it is best to make that last point more explicit. >> I basically had that, but I was still using the MIB term of "subtrees". >> So the 4th revision (last??) of the template-text would be as >> follows: >> >> ---- >> >> Each specification that defines one or more YANG >> modules MUST contain a section that discusses >> security considerations relevant to those modules. >> This section MUST be patterned after the latest >> approved template (available at [ed: URL TBD]). >> >> In particular, writable data nodes that could >> be especially disruptive if abused MUST be >> explicitly listed by name and the associated >> security risks MUST be spelled out. >> >> Similarly, readable data nodes that contain >> especially sensitive information or that raise >> significant privacy concerns MUST be explicitly >> listed by name and the reasons for the >> sensitivity/privacy concerns MUST be explained. >> >> Further, if new RPC operations have been defined, >> then it the security considerations of each new >> RPC operation MUST be explained. >> >> Note: it is best to list a container or list node if all the >> leaves in the container or list node share the same >> or similar security considerations. >> >> 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 containers, list nodes and data nodes with their specific >> sensitivity/vulnerability: >> >> >> >> -- for all YANG modules you must evaluate whether any readable data >> -- nodes (those are all the "config false" nodes, but also all other >> -- nodes, because they can also be read via operations like get or >> -- get-config) are sensitive or vulnerable (for instance, if they >> -- might reveal customer information or violate personal privacy >> -- laws such as those of the European Union if exposed to >> -- unauthorized parties) >> >> Some of the readable data nodes in this YANG module may be >> considered sensitive or vulnerable in some network environments. >> It is thus important to control read access (e.g. via get, >> get-config or notification) to these data nodes. These are the >> containers, list nodes and data nodes with their specific >> sensitivity/vulnerability: >> >> >> >> -- if your YANG module has defined any rpc operations >> -- describe their specific sensitivity or vulnerability. >> >> Some of the RPC operations in this YANG module may be considered >> sensitive or vulnerable in some network environments. It is thus >> important to control access to these operations. These are the >> operations and their sensitivity/vulnerability: >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From dromasca@avaya.com Tue Apr 27 11:26: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 A1BFD28C1DD for ; Tue, 27 Apr 2010 11:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThtkvdamSoFW for ; Tue, 27 Apr 2010 11:26:17 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BC66428C24B for ; Tue, 27 Apr 2010 11:24:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,282,1270440000"; d="scan'208";a="215437787" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Apr 2010 14:24:44 -0400 X-IronPort-AV: E=Sophos;i="4.52,282,1270440000"; d="scan'208";a="455465568" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Apr 2010 14:24:44 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 20:24:19 +0200 Message-ID: In-Reply-To: <43447B97F09044418C553FBF37EFB291@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] 4th draft for yang module security considerations Thread-Index: AcrmNL2druHAG/TiRb+CX2Zpdd0ziQAAbNeA References: <7EE9107147F64FD6A17D28282C6B3779@BertLaptop> <43447B97F09044418C553FBF37EFB291@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Mark Ellison" Cc: NETMOD Working Group Subject: Re: [netmod] 4th 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, 27 Apr 2010 18:26:18 -0000 If there are no major issues I propose that we send this version to the Security ADs for review (with nits fixed) If there still are major issues please jump in in the next two days.=20 Thanks and Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Tuesday, April 27, 2010 9:04 PM > To: Mark Ellison > Cc: NETMOD Working Group > Subject: Re: [netmod] 4th draft for yang module security=20 > considerations >=20 > Yep. Thanks Mark. >=20 > Bert > ----- Original Message ----- > From: "Mark Ellison" > To: "Bert Wijnen (IETF)" > Cc: "NETMOD Working Group" > Sent: Tuesday, April 27, 2010 7:27 PM > Subject: Re: [netmod] 4th draft for yang module security=20 > considerations >=20 >=20 > > Bert, > > > > One minor editorial nit in the following: > > > >> Further, if new RPC operations have been defined, > >> then it the security considerations of each new > >> RPC operation MUST be explained. > > > > s/then it the/then the/ > > > > Regards, > > > > Mark > > > > On Tue, Apr 27, 2010 at 3:50 AM, Bert Wijnen (IETF)=20 > > wrote: > > > >> We had quite a few discussions on the 3rd revision. > >> From my reading however, it seems we more or less agree that: > >> > >> - security considerations must be listed in the SC section and > >> not in a separtely tagged description clause with the=20 > nodes themselves. > >> - we cannot do a blanket statement that basically ALL config data > >> is sensitive > >> - it is OK toi list a container or node list if all the leaves have > >> the sanme/similar secuirty considereations. > >> Based on that, I think it is best to make that last point=20 > more explicit. > >> I basically had that, but I was still using the MIB term=20 > of "subtrees". > >> So the 4th revision (last??) of the template-text would be as > >> follows: > >> > >> ---- > >> > >> Each specification that defines one or more YANG > >> modules MUST contain a section that discusses > >> security considerations relevant to those modules. > >> This section MUST be patterned after the latest > >> approved template (available at [ed: URL TBD]). > >> > >> In particular, writable data nodes that could > >> be especially disruptive if abused MUST be > >> explicitly listed by name and the associated > >> security risks MUST be spelled out. > >> > >> Similarly, readable data nodes that contain > >> especially sensitive information or that raise > >> significant privacy concerns MUST be explicitly > >> listed by name and the reasons for the > >> sensitivity/privacy concerns MUST be explained. > >> > >> Further, if new RPC operations have been defined, > >> then it the security considerations of each new > >> RPC operation MUST be explained. > >> > >> Note: it is best to list a container or list node if all the > >> leaves in the container or list node share the same > >> or similar security considerations. > >> > >> 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 containers, list nodes and data nodes with their specific > >> sensitivity/vulnerability: > >> > >> are sensitive> > >> > >> -- for all YANG modules you must evaluate whether any readable data > >> -- nodes (those are all the "config false" nodes, but also=20 > all other > >> -- nodes, because they can also be read via operations like get or > >> -- get-config) are sensitive or vulnerable (for instance, if they > >> -- might reveal customer information or violate personal privacy > >> -- laws such as those of the European Union if exposed to > >> -- unauthorized parties) > >> > >> Some of the readable data nodes in this YANG module may be > >> considered sensitive or vulnerable in some network environments. > >> It is thus important to control read access (e.g. via get, > >> get-config or notification) to these data nodes. These are the > >> containers, list nodes and data nodes with their specific > >> sensitivity/vulnerability: > >> > >> are sensitive> > >> > >> -- if your YANG module has defined any rpc operations > >> -- describe their specific sensitivity or vulnerability. > >> > >> Some of the RPC operations in this YANG module may be considered > >> sensitive or vulnerable in some network environments. It is thus > >> important to control access to these operations. These are the > >> operations and their sensitivity/vulnerability: > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From dromasca@avaya.com Thu Apr 29 04:00: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 C761528C234 for ; Thu, 29 Apr 2010 04:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW4PqDpgOqgk for ; Thu, 29 Apr 2010 04:00:13 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B29943A6C71 for ; Thu, 29 Apr 2010 04:00:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,294,1270440000"; d="scan'208";a="215729580" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Apr 2010 06:59:48 -0400 X-IronPort-AV: E=Sophos;i="4.52,294,1270440000"; d="scan'208";a="468847386" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Apr 2010 06:59:48 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Apr 2010 12:59:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-netmod-yang-12 Thread-Index: Acrm2BBzaKGADhquRXuLFeRh8/AiGwAsvWWg From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: Secdir review of draft-ietf-netmod-yang-12 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, 29 Apr 2010 11:00:13 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, April 28, 2010 4:37 PM To: secdir@ietf.org; IESG IESG; draft-ietf-netmod-yang@tools.ietf.org Subject: Secdir review of draft-ietf-netmod-yang-12 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a language used to read and write descriptions of management information. It is not intended to be used within an "on the wire" internet protocol. As such, the usual "on the wire" security issues do not apply. The "Security Considerations" looks OK. I would suggest adding a caution about reading data from untrusted sources. Document readers have a long history of being attacked by malformed documents. e.g.: YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised. Alan DeKok. From lhotka@cesnet.cz Fri Apr 30 04:17: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 7EF2A3A69B1 for ; Fri, 30 Apr 2010 04:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_50=0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWQ717hAUBzG for ; Fri, 30 Apr 2010 04:17:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 3D0003A68EA for ; Fri, 30 Apr 2010 04:17:34 -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 2DD0F2CDE05E for ; Fri, 30 Apr 2010 13:17:20 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 30 Apr 2010 13:17:18 +0200 Message-ID: <1272626238.10889.4.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [netmod] yang-types: bug in regex 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, 30 Apr 2010 11:17:37 -0000 Hi, I found a bug in the pattern for "date-and-time" in ietf-yang-types: --- draft-ietf-netmod-yang-types-09.txt.orig 2010-04-30 13:10:07.909168417 +0200 +++ draft-ietf-netmod-yang-types-09.txt 2010-04-30 13:11:36.473167337 +0200 @@ -592,7 +592,7 @@ typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' - + '(Z|[\+|-]\d{2}:\d{2})'; + + '(Z|[\+\-]\d{2}:\d{2})'; } description "The date-and-time type is a profile of the ISO 8601 Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Apr 30 12:55:53 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D29628C268 for ; Fri, 30 Apr 2010 12:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdeVeiPtSsO9 for ; Fri, 30 Apr 2010 12:55:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 555C028C19F for ; Fri, 30 Apr 2010 12:55:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54ACAC0002; Fri, 30 Apr 2010 21:55:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wrubA45Y93Sk; Fri, 30 Apr 2010 21:55:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 075B3C0004; Fri, 30 Apr 2010 21:55:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CD9411D6077; Fri, 30 Apr 2010 21:55:36 +0200 (CEST) Date: Fri, 30 Apr 2010 21:55:35 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100430195535.GB4169@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1272626238.10889.4.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1272626238.10889.4.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] yang-types: bug in regex 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, 30 Apr 2010 19:55:53 -0000 On Fri, Apr 30, 2010 at 01:17:18PM +0200, Ladislav Lhotka wrote: > Hi, > > I found a bug in the pattern for "date-and-time" in ietf-yang-types: > > --- draft-ietf-netmod-yang-types-09.txt.orig 2010-04-30 > 13:10:07.909168417 +0200 > +++ draft-ietf-netmod-yang-types-09.txt 2010-04-30 13:11:36.473167337 > +0200 > @@ -592,7 +592,7 @@ > typedef date-and-time { > type string { > pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' > - + '(Z|[\+|-]\d{2}:\d{2})'; > + + '(Z|[\+\-]\d{2}:\d{2})'; > } > description > "The date-and-time type is a profile of the ISO 8601 Thanks. I hope to get this fixed before the ID gets cast into stone. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103