From reid@snmp.com Thu Jan 5 14:17:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE43121F85A5 for ; Thu, 5 Jan 2012 14:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbn5s1YRFMzX for ; Thu, 5 Jan 2012 14:17:31 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5019B21F84D9 for ; Thu, 5 Jan 2012 14:17:18 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA22001 for ; Thu, 5 Jan 2012 17:17:17 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA29125 for ; Thu, 5 Jan 2012 17:17:12 -0500 (EST) Message-Id: <201201052217.RAA29125@adminfs.snmp.com> cc: netmod@ietf.org From: David Reid In-reply-to: Your message of Mon, 14 Nov 2011 12:36:15 -0500. <201111141736.MAA26175@adminfs.snmp.com> Date: Thu, 05 Jan 2012 17:17:12 -0500 Sender: reid@snmp.com Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:17:31 -0000 > > Hi, > > > > Martin Bjorklund wrote: > > > This makes me wonder what the 2119 language tries to convey in this > > > document. What does interoperability mean for this spec? The text > > > says that it is used for: > > > > > > enabling read-only access to data objects defined in SMIv2 MIB > > > modules via NETCONF > > > > The document says that all nodes MUST be config false, which is > > natural since the interoperability goal is read-only access. But I > > think we should allow implementations to mark nodes as config true, in > > an implementation dependent manner. This would not affect our > > read-only interoperability goal. > > > > We already know from this ML that some vendors (including myself) will > > provide config true access to parts of the MIBs. (We're using a bunch > > of directives to the compiler to control which parts). As the > > document is written today, the output from my tool is non-compliant, > > but I do not think this is necessary. > > > > Our tool also allows config true under some conditions. I don't think we ever reached a conclusion on this topic. I don't have a good answer, but my current implementation uses config true for some objects, which is non-compliant. Is there a way we can soften the MUST be config false statement such that config false is all that is required, but config true is not considered non-compliant? -David Reid From reid@snmp.com Thu Jan 5 14:20:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B921F8586 for ; Thu, 5 Jan 2012 14:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PL4s+2i3ZhY for ; Thu, 5 Jan 2012 14:20:53 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE9F21F88DA for ; Thu, 5 Jan 2012 14:20:53 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA22194 for ; Thu, 5 Jan 2012 17:20:52 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA29212 for ; Thu, 5 Jan 2012 17:20:52 -0500 (EST) Message-Id: <201201052220.RAA29212@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 05 Jan 2012 17:20:51 -0500 From: David Reid Subject: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:20:54 -0000 I'm looking at implementing the current smi to yang conversion rules in the netconf server. More specifically, I'm trying to use the converted yang module as the data model for netconf, snmp, cli, web, etc. I'm a little concerned about the current containment hierarchy. Maybe this isn't a problem, but let me try to explain my concern. I know that our charter only specifies a data modeling language for netconf, but I think there is a vision to use yang for more than just netconf and I know that this is happening in practice. What I would like to see in the future are documents kind of like RFC 3781 (SMIng mappings to SNMP) to define YANG mappings other protocols. One such mapping I would like to see is YANG to an EOS-like (Evolution of SNMP) version of SNMP. It might also include a mapping from a subset of yang to SNMPv3, allowing someone to write the model in yang (using the defined subset) and produce a MIB for SNMPv3 retrieval in addition to netconf. I'm not suggesting we do that now, but the current smi to yang mapping provides a very good foundation for that type of document. The only problem I see is that if the yang containment in the converted module conflicts with the OID hierarchy, a yang mapping to SNMP will be more difficult, and I don't want to do anything now that would make such a mapping document difficult or impossible in the future. It seems to me that allowing the yang containment to not match the OID hierarchy will make a yang mapping to SNMP more difficult. I'm not sure the best solution. It seems like we would need to flatten scalars (like the -01 draft) and remove the top level container. The problem with the top-level container is that it has no OID and thus does not fit in the SNMP world. The unflattened scalars make containers like "interfaces" contain different data depending on if it is retrieved in netconf or retrieved in SNMP. Of course I have all the OIDs in the converted yang module, so I can extract what I need for SNMP. But it seems wrong to have the data organized differently if retrieved through SNMP than through netconf. And I'm not sure which way to organize it when retrieved through the web interface or cli. I'm not sure if I stated my concern clearly, but I'm curious as to what some of the rest of you think. -David Reid From andy@netconfcentral.org Thu Jan 5 14:27:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3A21F88D7 for ; Thu, 5 Jan 2012 14:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR-a5NNUiiRg for ; Thu, 5 Jan 2012 14:27:59 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 03AA421F889D for ; Thu, 5 Jan 2012 14:27:56 -0800 (PST) Received: from cm-omr5 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q05MRqwg020889 for ; Thu, 5 Jan 2012 17:27:54 -0500 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:57423] helo=[192.168.0.126]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 74/95-08454-7E3260F4; Thu, 05 Jan 2012 17:27:52 -0500 Message-ID: <4F0623E7.5020407@netconfcentral.org> Date: Thu, 05 Jan 2012 14:27:51 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid References: <201201052217.RAA29125@adminfs.snmp.com> In-Reply-To: <201201052217.RAA29125@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:27:59 -0000 On 01/05/2012 02:17 PM, David Reid wrote: >>> Hi, >>> >>> Martin Bjorklund wrote: >>>> This makes me wonder what the 2119 language tries to convey in this >>>> document. What does interoperability mean for this spec? The text >>>> says that it is used for: >>>> >>>> enabling read-only access to data objects defined in SMIv2 MIB >>>> modules via NETCONF >>> The document says that all nodes MUST be config false, which is >>> natural since the interoperability goal is read-only access. But I >>> think we should allow implementations to mark nodes as config true, in >>> an implementation dependent manner. This would not affect our >>> read-only interoperability goal. >>> >>> We already know from this ML that some vendors (including myself) will >>> provide config true access to parts of the MIBs. (We're using a bunch >>> of directives to the compiler to control which parts). As the >>> document is written today, the output from my tool is non-compliant, >>> but I do not think this is necessary. >>> >> Our tool also allows config true under some conditions. > I don't think we ever reached a conclusion on this topic. I don't have a > good answer, but my current implementation uses config true for some objects, > which is non-compliant. Is there a way we can soften the MUST be config false > statement such that config false is all that is required, but config true is > not considered non-compliant? Unless you can define a standard algorithm for deciding when to generate config true instead of config false, I don't think this can go into the draft. IMO, if a user adds special extensions to the SMIv2 file (or the translator config), then it is implicitly requesting a non-standard translation, so it is OK if it does not follow the 'config false' rule all the time. > > -David Reid Andy From andy@netconfcentral.org Thu Jan 5 14:47:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB7421F84AA for ; Thu, 5 Jan 2012 14:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNfGTPCqcdb3 for ; Thu, 5 Jan 2012 14:47:23 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 271B921F84A3 for ; Thu, 5 Jan 2012 14:47:17 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q05MlFF7022170 for ; Thu, 5 Jan 2012 17:47:15 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33679] helo=[192.168.0.126]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D2/A3-28181-378260F4; Thu, 05 Jan 2012 17:47:15 -0500 Message-ID: <4F062873.2050405@netconfcentral.org> Date: Thu, 05 Jan 2012 14:47:15 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid References: <201201052220.RAA29212@adminfs.snmp.com> In-Reply-To: <201201052220.RAA29212@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:47:24 -0000 On 01/05/2012 02:20 PM, David Reid wrote: > I'm looking at implementing That's all I had to read to decide you're probably right. the current smi to yang conversion rules in > the netconf server. More specifically, I'm trying to use the converted > yang module as the data model for netconf, snmp, cli, web, etc. I'm a > little concerned about the current containment hierarchy. Maybe this isn't > a problem, but let me try to explain my concern. Preaching to the choir here. The vision has always been to decouple each of the layers (transport, operation, and content). It should be possible for you to write a new RFC to support new protocols. But I don't agree the SMI mapping needs to be flattened. The same problem exists in NETCONF tools. The yuma server solves this problem with the 'ncx:root' extension. container config { ncx:root; } For XML, XPath and other processing, this serves as the root node '/'. Is the problem that the valid YANG path '/' has no translation in SMIv2? (If so, make one up.) I don't like arbitrary containment as a general rule. I prefer to have actual SMIv2 siblings to be YANG siblings as well, but there should be 1 top-level container for the module, plus 0 or more notifications at the top level. Andy > I know that our charter only specifies a data modeling language for netconf, > but I think there is a vision to use yang for more than just netconf and I > know that this is happening in practice. What I would like to see in the > future are documents kind of like RFC 3781 (SMIng mappings to SNMP) to > define YANG mappings other protocols. One such mapping I would like to see > is YANG to an EOS-like (Evolution of SNMP) version of SNMP. It might also > include a mapping from a subset of yang to SNMPv3, allowing someone to write > the model in yang (using the defined subset) and produce a MIB for SNMPv3 > retrieval in addition to netconf. I'm not suggesting we do that now, but > the current smi to yang mapping provides a very good foundation for that > type of document. The only problem I see is that if the yang containment > in the converted module conflicts with the OID hierarchy, a yang mapping to > SNMP will be more difficult, and I don't want to do anything now that would > make such a mapping document difficult or impossible in the future. > > It seems to me that allowing the yang containment to not match the OID > hierarchy will make a yang mapping to SNMP more difficult. I'm not sure the > best solution. It seems like we would need to flatten scalars (like the -01 > draft) and remove the top level container. The problem with the top-level > container is that it has no OID and thus does not fit in the SNMP world. The > unflattened scalars make containers like "interfaces" contain different data > depending on if it is retrieved in netconf or retrieved in SNMP. > > Of course I have all the OIDs in the converted yang module, so I can extract > what I need for SNMP. But it seems wrong to have the data organized differently > if retrieved through SNMP than through netconf. And I'm not sure which way > to organize it when retrieved through the web interface or cli. > > I'm not sure if I stated my concern clearly, but I'm curious as to what some > of the rest of you think. > > -David Reid > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From mbj@tail-f.com Thu Jan 5 14:48:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440C421F883E for ; Thu, 5 Jan 2012 14:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S34JAeMHKLIh for ; Thu, 5 Jan 2012 14:48:42 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 348C321F84B8 for ; Thu, 5 Jan 2012 14:48:35 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1AE071200AD8; Thu, 5 Jan 2012 23:48:32 +0100 (CET) Date: Thu, 05 Jan 2012 23:48:31 +0100 (CET) Message-Id: <20120105.234831.260163695.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F0623E7.5020407@netconfcentral.org> References: <201201052217.RAA29125@adminfs.snmp.com> <4F0623E7.5020407@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:48:43 -0000 Andy Bierman wrote: > On 01/05/2012 02:17 PM, David Reid wrote: > >>> Hi, > >>> > >>> Martin Bjorklund wrote: > >>>> This makes me wonder what the 2119 language tries to convey in this > >>>> document. What does interoperability mean for this spec? The text > >>>> says that it is used for: > >>>> > >>>> enabling read-only access to data objects defined in SMIv2 MIB > >>>> modules via NETCONF > >>> The document says that all nodes MUST be config false, which is > >>> natural since the interoperability goal is read-only access. But I > >>> think we should allow implementations to mark nodes as config true, in > >>> an implementation dependent manner. This would not affect our > >>> read-only interoperability goal. > >>> > >>> We already know from this ML that some vendors (including myself) will > >>> provide config true access to parts of the MIBs. (We're using a bunch > >>> of directives to the compiler to control which parts). As the > >>> document is written today, the output from my tool is non-compliant, > >>> but I do not think this is necessary. > >>> > >> Our tool also allows config true under some conditions. > > I don't think we ever reached a conclusion on this topic. I don't have a > > good answer, but my current implementation uses config true for some > > objects, > > which is non-compliant. Is there a way we can soften the MUST be config > > false > > statement such that config false is all that is required, but config true is > > not considered non-compliant? > > Unless you can define a standard algorithm for deciding when to generate > config true > instead of config false, I don't think this can go into the draft. Can you elaborate on why it would be a problem to allow this? Earlier in this thread I wrote: A client can only rely on config false for full interoperability, just like today, I don't want to change that. So if a client that knows a module w/ config false gets a capability with the right namespace and revision, it knows how to from the server, regardless of how many config trues that server is using. /martin From andy@netconfcentral.org Thu Jan 5 15:04:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E621F88A7 for ; Thu, 5 Jan 2012 15:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TBww6l6G64s for ; Thu, 5 Jan 2012 15:04:48 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id D5D6A21F883E for ; Thu, 5 Jan 2012 15:04:45 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q05N4iok012656 for ; Thu, 5 Jan 2012 18:04:44 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37675] helo=[192.168.0.126]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 81/BA-23837-B8C260F4; Thu, 05 Jan 2012 18:04:44 -0500 Message-ID: <4F062C8B.9030007@netconfcentral.org> Date: Thu, 05 Jan 2012 15:04:43 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Bjorklund References: <201201052217.RAA29125@adminfs.snmp.com> <4F0623E7.5020407@netconfcentral.org> <20120105.234831.260163695.mbj@tail-f.com> In-Reply-To: <20120105.234831.260163695.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:04:48 -0000 On 01/05/2012 02:48 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On 01/05/2012 02:17 PM, David Reid wrote: >>>>> Hi, >>>>> >>>>> Martin Bjorklund wrote: >>>>>> This makes me wonder what the 2119 language tries to convey in this >>>>>> document. What does interoperability mean for this spec? The text >>>>>> says that it is used for: >>>>>> >>>>>> enabling read-only access to data objects defined in SMIv2 MIB >>>>>> modules via NETCONF >>>>> The document says that all nodes MUST be config false, which is >>>>> natural since the interoperability goal is read-only access. But I >>>>> think we should allow implementations to mark nodes as config true, in >>>>> an implementation dependent manner. This would not affect our >>>>> read-only interoperability goal. >>>>> >>>>> We already know from this ML that some vendors (including myself) will >>>>> provide config true access to parts of the MIBs. (We're using a bunch >>>>> of directives to the compiler to control which parts). As the >>>>> document is written today, the output from my tool is non-compliant, >>>>> but I do not think this is necessary. >>>>> >>>> Our tool also allows config true under some conditions. >>> I don't think we ever reached a conclusion on this topic. I don't have a >>> good answer, but my current implementation uses config true for some >>> objects, >>> which is non-compliant. Is there a way we can soften the MUST be config >>> false >>> statement such that config false is all that is required, but config true is >>> not considered non-compliant? >> >> Unless you can define a standard algorithm for deciding when to generate >> config true >> instead of config false, I don't think this can go into the draft. > > Can you elaborate on why it would be a problem to allow this? > > Earlier in this thread I wrote: > > A client can only rely on config false for full interoperability, > just like today, I don't want to change that. So if a client that > knows a module w/ config false gets a capability with the right > namespace and revision, it knows how to from the server, > regardless of how many config trues that server is using. > I do want to allow this. So you want to punt on the issue of a user knowing what a 'standard' translator will generate? IMO, a plain, default translation is all config false. All YANG tools have to deal with config true or false, so there is no reason to restrict the SMIv2 translation output to config false. Perhaps the draft can mention somehow that 'plain SMIv2' always generates config false, and it is outside scope of doc, but tool may allow proprietary mechanisms to generate config true for some or all objects. > > /martin > > Andy From andy@netconfcentral.org Thu Jan 5 15:18:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4838521F88CB for ; Thu, 5 Jan 2012 15:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIPSdH8SM2y5 for ; Thu, 5 Jan 2012 15:18:04 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 892F921F88C1 for ; Thu, 5 Jan 2012 15:18:02 -0800 (PST) Received: from cm-omr7 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q05NI2AH001371 for ; Thu, 5 Jan 2012 18:18:02 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:40784] helo=[192.168.0.126]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 54/CC-03964-9AF260F4; Thu, 05 Jan 2012 18:18:02 -0500 Message-ID: <4F062FA9.8010606@netconfcentral.org> Date: Thu, 05 Jan 2012 15:18:01 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid References: <201201052220.RAA29212@adminfs.snmp.com> In-Reply-To: <201201052220.RAA29212@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:18:05 -0000 On 01/05/2012 02:20 PM, David Reid wrote: > I'm looking at implementing the current smi to yang conversion rules in > the netconf server. More specifically, I'm trying to use the converted > yang module as the data model for netconf, snmp, cli, web, etc. I'm a > little concerned about the current containment hierarchy. Maybe this isn't > a problem, but let me try to explain my concern. > I guess I am agreeing with you that an extra container for scalars should be removed. It just makes tools harder to implement and use because it creates a special corner-case when there is no need for one. > -David Reid Andy From spakes@snmp.com Thu Jan 5 16:16:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E603411E8086 for ; Thu, 5 Jan 2012 16:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9EhZ2QcGm9z for ; Thu, 5 Jan 2012 16:16:43 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4811E8080 for ; Thu, 5 Jan 2012 16:16:42 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id TAA26433; Thu, 5 Jan 2012 19:16:32 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id TAA01888; Thu, 5 Jan 2012 19:16:25 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 5 Jan 2012 19:16:25 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4F0623E7.5020407@netconfcentral.org> Message-ID: References: <201201052217.RAA29125@adminfs.snmp.com> <4F0623E7.5020407@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:16:44 -0000 On Thu, 5 Jan 2012, Andy Bierman wrote: > On 01/05/2012 02:17 PM, David Reid wrote: > >>> Hi, > >>> > >>> Martin Bjorklund wrote: > >>>> This makes me wonder what the 2119 language tries to convey in this > >>>> document. What does interoperability mean for this spec? The text > >>>> says that it is used for: > >>>> > >>>> enabling read-only access to data objects defined in SMIv2 MIB > >>>> modules via NETCONF > >>> The document says that all nodes MUST be config false, which is > >>> natural since the interoperability goal is read-only access. But I > >>> think we should allow implementations to mark nodes as config true, in > >>> an implementation dependent manner. This would not affect our > >>> read-only interoperability goal. > >>> > >>> We already know from this ML that some vendors (including myself) will > >>> provide config true access to parts of the MIBs. (We're using a bunch > >>> of directives to the compiler to control which parts). As the > >>> document is written today, the output from my tool is non-compliant, > >>> but I do not think this is necessary. > >>> > >> Our tool also allows config true under some conditions. > > I don't think we ever reached a conclusion on this topic. I don't have a > > good answer, but my current implementation uses config true for some objects, > > which is non-compliant. Is there a way we can soften the MUST be config false > > statement such that config false is all that is required, but config true is > > not considered non-compliant? > > Unless you can define a standard algorithm for deciding when to generate > config true instead of config false, I don't think this can go into the > draft. IMO, if a user adds special extensions to the SMIv2 file (or the > translator config), then it is implicitly requesting a non-standard > translation, so it is OK if it does not follow the 'config false' rule > all the time. At one time, the task of coming up with such an algorithm seemed daunting. However, now that we have collapsed the containment down to a single level (and maybe no levels for scalars), shouldn't it be much easier? e.g., 1. If the SMIv2 OBJECT-TYPE macro invocation has a SYNTAX of "TestAndIncr", do not translate it to a YANG data tree leaf; 2. Otherwise, if the SMIv2 OBJECT-TYPE macro invocation has a MAX-ACCESS of "read-only", it MUST be translated to a YANG data tree leaf with a "config false" substatement; 3. Otherwise, if the SMIv2 OBJECT-TYPE macro invocation is translated as a YANG data tree leaf, it MUST have a "config true" substatement. There may be some other corner cases besides the TestAndIncr TC that may need special consideration, but that's the only one I can think of at the moment. I believe the RowStatus TC does not need to have special consideration in the translation. However, the spec should note the following about RowStatus: (a) the state machine is meaningless to a NETCONF client; and, (b) a NETCONF server interacting with an SNMP engine should be prepared to handle the transitions properly in order to apply a correct configuration. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Thu Jan 5 21:00:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D399E1F0C5B for ; Thu, 5 Jan 2012 21:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ckNwCN8SVX3 for ; Thu, 5 Jan 2012 21:00:47 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C99441F0C59 for ; Thu, 5 Jan 2012 21:00:46 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id AAA03162; Fri, 6 Jan 2012 00:00:34 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id AAA07832; Fri, 6 Jan 2012 00:00:24 -0500 (EST) Message-Id: <201201060500.AAA07832@adminfs.snmp.com> To: David Spakes From: David Reid In-reply-to: Your message of Thu, 05 Jan 2012 19:16:25 -0500. Date: Fri, 06 Jan 2012 00:00:23 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 05:00:47 -0000 > On Thu, 5 Jan 2012, Andy Bierman wrote: > > > On 01/05/2012 02:17 PM, David Reid wrote: > > >>> Hi, > > >>> > > >>> Martin Bjorklund wrote: > > >>>> This makes me wonder what the 2119 language tries to convey in this > > >>>> document. What does interoperability mean for this spec? The text > > >>>> says that it is used for: > > >>>> > > >>>> enabling read-only access to data objects defined in SMIv2 MIB > > >>>> modules via NETCONF > > >>> The document says that all nodes MUST be config false, which is > > >>> natural since the interoperability goal is read-only access. But I > > >>> think we should allow implementations to mark nodes as config true, in > > >>> an implementation dependent manner. This would not affect our > > >>> read-only interoperability goal. > > >>> > > >>> We already know from this ML that some vendors (including myself) will > > >>> provide config true access to parts of the MIBs. (We're using a bunch > > >>> of directives to the compiler to control which parts). As the > > >>> document is written today, the output from my tool is non-compliant, > > >>> but I do not think this is necessary. > > >>> > > >> Our tool also allows config true under some conditions. > > > I don't think we ever reached a conclusion on this topic. I don't have a > > > good answer, but my current implementation uses config true for some objects, > > > which is non-compliant. Is there a way we can soften the MUST be config false > > > statement such that config false is all that is required, but config true is > > > not considered non-compliant? > > > > Unless you can define a standard algorithm for deciding when to generate > > config true instead of config false, I don't think this can go into the > > draft. IMO, if a user adds special extensions to the SMIv2 file (or the > > translator config), then it is implicitly requesting a non-standard > > translation, so it is OK if it does not follow the 'config false' rule > > all the time. > Does that mean my non-standard translation would need to use a different namespace? I really want to produce a translation that is interoperable with other translations for read-only operations, but also allows config true for clients using the same translated module. > > At one time, the task of coming up with such an algorithm seemed daunting. > However, now that we have collapsed the containment down to a single level > (and maybe no levels for scalars), shouldn't it be much easier? e.g., > I don't care if we come up with a standard algorithm or not. All I want is a way for my implementation to have writable objects without the entire translation being considered non-compliant because it has some config true nodes. -David Reid From j.schoenwaelder@jacobs-university.de Thu Jan 5 23:25:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3543711E8099 for ; Thu, 5 Jan 2012 23:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdXnLT+xaP47 for ; Thu, 5 Jan 2012 23:25:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6C21F8733 for ; Thu, 5 Jan 2012 23:25:04 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D4C320BDB; Fri, 6 Jan 2012 08:25:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tNhxE1j2UPf3; Fri, 6 Jan 2012 08:25:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DD6120BDF; Fri, 6 Jan 2012 08:25:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A47591C5BA3B; Fri, 6 Jan 2012 08:24:44 +0100 (CET) Date: Fri, 6 Jan 2012 08:24:43 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20120106072443.GA85155@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , netmod@ietf.org References: <201201052217.RAA29125@adminfs.snmp.com> <4F0623E7.5020407@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:25:10 -0000 On Thu, Jan 05, 2012 at 07:16:25PM -0500, David Spakes wrote: > > At one time, the task of coming up with such an algorithm seemed daunting. > However, now that we have collapsed the containment down to a single level > (and maybe no levels for scalars), shouldn't it be much easier? e.g., > > 1. If the SMIv2 OBJECT-TYPE macro invocation has a SYNTAX of > "TestAndIncr", do not translate it to a YANG data tree leaf; > > 2. Otherwise, if the SMIv2 OBJECT-TYPE macro invocation has a > MAX-ACCESS of "read-only", it MUST be translated to a YANG data > tree leaf with a "config false" substatement; > > 3. Otherwise, if the SMIv2 OBJECT-TYPE macro invocation is > translated as a YANG data tree leaf, it MUST have a > "config true" substatement. > > > There may be some other corner cases besides the TestAndIncr TC that > may need special consideration, but that's the only one I can think of > at the moment. > > I believe the RowStatus TC does not need to have special consideration in > the translation. However, the spec should note the following about > RowStatus: > > (a) the state machine is meaningless to a NETCONF client; and, > > (b) a NETCONF server interacting with an SNMP engine should be > prepared to handle the transitions properly in order to apply a > correct configuration. My understanding is that the NETCONF and SNMP persistency models are fundamentally different. With SNMP, you have lots of writable knobs and whether changes are persistent or not is either not specified or hidden in DESCRIPTION clauses or implied by the usage of storage type conventions. With today's NETCONF operations, writing always means editing a configuration datastore and not some operational state. Note also that YANG has config true/false which is not the same as writable true/false. To do a single data model that can drive both NETCONF and SNMP properly, I believe one needs several extensions to YANG that go well beyond what we have (and it would likely also require to work out how to deal with operational state and in particular writable operational state in NETCONF properly). /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 Jan 5 23:32:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEBA11E80B7 for ; Thu, 5 Jan 2012 23:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQKUrmUZ+FKr for ; Thu, 5 Jan 2012 23:32:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CDADB11E8099 for ; Thu, 5 Jan 2012 23:32:23 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 330F720BED; Fri, 6 Jan 2012 08:32:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Uu7WR2UtSi5D; Fri, 6 Jan 2012 08:32:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C072620BDF; Fri, 6 Jan 2012 08:32:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 192A21C5BAD6; Fri, 6 Jan 2012 08:32:05 +0100 (CET) Date: Fri, 6 Jan 2012 08:32:04 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20120106073203.GB85155@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201201052220.RAA29212@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201052220.RAA29212@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:32:24 -0000 On Thu, Jan 05, 2012 at 05:20:51PM -0500, David Reid wrote: > I'm looking at implementing the current smi to yang conversion rules in > the netconf server. More specifically, I'm trying to use the converted > yang module as the data model for netconf, snmp, cli, web, etc. I'm a > little concerned about the current containment hierarchy. Maybe this isn't > a problem, but let me try to explain my concern. > > I know that our charter only specifies a data modeling language for netconf, > but I think there is a vision to use yang for more than just netconf and I > know that this is happening in practice. What I would like to see in the > future are documents kind of like RFC 3781 (SMIng mappings to SNMP) to > define YANG mappings other protocols. One such mapping I would like to see > is YANG to an EOS-like (Evolution of SNMP) version of SNMP. It might also > include a mapping from a subset of yang to SNMPv3, allowing someone to write > the model in yang (using the defined subset) and produce a MIB for SNMPv3 > retrieval in addition to netconf. I'm not suggesting we do that now, but > the current smi to yang mapping provides a very good foundation for that > type of document. The only problem I see is that if the yang containment > in the converted module conflicts with the OID hierarchy, a yang mapping to > SNMP will be more difficult, and I don't want to do anything now that would > make such a mapping document difficult or impossible in the future. > > It seems to me that allowing the yang containment to not match the OID > hierarchy will make a yang mapping to SNMP more difficult. I'm not sure the > best solution. It seems like we would need to flatten scalars (like the -01 > draft) and remove the top level container. The problem with the top-level > container is that it has no OID and thus does not fit in the SNMP world. The > unflattened scalars make containers like "interfaces" contain different data > depending on if it is retrieved in netconf or retrieved in SNMP. > > Of course I have all the OIDs in the converted yang module, so I can extract > what I need for SNMP. But it seems wrong to have the data organized differently > if retrieved through SNMP than through netconf. And I'm not sure which way > to organize it when retrieved through the web interface or cli. > > I'm not sure if I stated my concern clearly, but I'm curious as to what some > of the rest of you think. I think I do not understand your message. - Stuff that does not have an OID does not exist in the SNMP world. Where is the problem? - We put scalars into containers for a specific reason. Is this not true anymore? And why is this problematic? - The OID tree and the NETCONF containment tree are different things. Just look at how augmentations work. For example, the ifXTable sits somewhere pretty unrelated to the ifTable in the OID tree. Has this ever been a serious problem? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Fri Jan 6 03:33:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8A21F8889 for ; Fri, 6 Jan 2012 03:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mes+0wYYyhLn for ; Fri, 6 Jan 2012 03:33:58 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id EF3ED21F8884 for ; Fri, 6 Jan 2012 03:33:57 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q06BXrEZ029298 for ; Fri, 6 Jan 2012 06:33:55 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:41035] helo=[192.168.0.126]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5F/B6-28181-12CD60F4; Fri, 06 Jan 2012 06:33:53 -0500 Message-ID: <4F06DC20.6030304@netconfcentral.org> Date: Fri, 06 Jan 2012 03:33:52 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid , netmod@ietf.org References: <201201052220.RAA29212@adminfs.snmp.com> <20120106073203.GB85155@elstar.local> In-Reply-To: <20120106073203.GB85155@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 11:33:58 -0000 On 01/05/2012 11:32 PM, Juergen Schoenwaelder wrote: ... > - We put scalars into containers for a specific reason. Is this not > true anymore? And why is this problematic? > This text on page 8 has huge implications: A top-level YANG container is generated. The container's name is the SMIv2 module name and the container MUST be config false. The generation of the top-level container MAY be skipped if the SMIv2 module does not define any objects that go into the top-level container (e.g., an SMIv2 module only defining textual conventions). It seems that there MUST be a top-level container, and it MUST be config true. Otherwise it will be too difficult to use the translations, and they can't even be augmented in the future with config objects. I do not agree with you that we can simply generate config true and ignore RowStatus, StorageType, read-write MAX-ACCESS, writable OID nodes, etc. But blinding forcing all OBJECT-TYPE macros to be read-only is not going to be compatible with anything. (Consider how useful a converted RMON-MIB would be if all the control tables were read-only, and the app could not create any alarms/events, host, matrix, or other collections.) As for scalars: As long as the translation algorithm is deterministic, tools can deal with it. IMO, one top-level container is OK, and won't be as optimal as hand-converted, but easy to remember and construct XPath: augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" { ... } leaf dumb-example { type leafref { path "/if-mib:IF-MIB/if-mib:ifNumber"; } } I prefer to have all the top-level MIB objects be child nodes of the NP container according to the module name. In the MIB module, ifNumber and ifTable are siblings, so they should be at the same level in the YANG translation. I don't see the value of preserving fooTable.fooEntry everywhere either. The translated objects could really boil down to a sequence of leaf or list statements. module if-mib { container IF-MIB { leaf ifNumber { config false; ... } list ifEntry { ... } } notification linkUp { ... } notification linkDown { ... } } > /js > Andy From andy@netconfcentral.org Fri Jan 6 03:58:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1021F85C3 for ; Fri, 6 Jan 2012 03:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRgDfY1-zgZE for ; Fri, 6 Jan 2012 03:58:16 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id C938A21F86A6 for ; Fri, 6 Jan 2012 03:58:15 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q06BwFGa010818 for ; Fri, 6 Jan 2012 06:58:15 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:46624] helo=[192.168.0.126]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B8/59-15882-6D1E60F4; Fri, 06 Jan 2012 06:58:15 -0500 Message-ID: <4F06E1D6.5010303@netconfcentral.org> Date: Fri, 06 Jan 2012 03:58:14 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid , netmod@ietf.org References: <201201052220.RAA29212@adminfs.snmp.com> <20120106073203.GB85155@elstar.local> In-Reply-To: <20120106073203.GB85155@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 11:58:16 -0000 .... 3 more comments: 1) Why not just use exact-case, and the same string for module name and top-level container? OLD: module if-mib { container IF-MIB {} } NEW: module IF-MIB { container IF-MIB {} } 2) We should think very carefully about how SMIv2-converted YANG is going to coexist with "new YANG", either vendor or SDO created. IMO, we don't have a good solution for integrated data organization yet. 3) We cannot rely on assumed translated output as the canonical standard YANG version of an SMIv2 module, if the translation is non-deterministic and implementations are free to choose important details like config true/false. We want to be able to reuse standard MIB modules without writing new RFCs for each one. > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Jan 6 05:14:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FEE21F8470 for ; Fri, 6 Jan 2012 05:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T24zr34BfAmd for ; Fri, 6 Jan 2012 05:14:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEEC21F844F for ; Fri, 6 Jan 2012 05:14:31 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1FB520C06; Fri, 6 Jan 2012 14:14:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Wx1m-qAt8Weu; Fri, 6 Jan 2012 14:14:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F8E220C04; Fri, 6 Jan 2012 14:14:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 729971C5BF55; Fri, 6 Jan 2012 14:14:11 +0100 (CET) Date: Fri, 6 Jan 2012 14:14:11 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120106131410.GA85995@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , netmod@ietf.org References: <201201052220.RAA29212@adminfs.snmp.com> <20120106073203.GB85155@elstar.local> <4F06DC20.6030304@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F06DC20.6030304@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:14:33 -0000 On Fri, Jan 06, 2012 at 03:33:52AM -0800, Andy Bierman wrote: > On 01/05/2012 11:32 PM, Juergen Schoenwaelder wrote: > ... > >- We put scalars into containers for a specific reason. Is this not > > true anymore? And why is this problematic? > > > > This text on page 8 has huge implications: > > A top-level YANG container is generated. The container's name is > the SMIv2 module name and the container MUST be config false. The > generation of the top-level container MAY be skipped if the SMIv2 > module does not define any objects that go into the top-level > container (e.g., an SMIv2 module only defining textual > conventions). > > It seems that there MUST be a top-level container, and it MUST be config true. > Otherwise it will be too difficult to use the translations, and they can't even be > augmented in the future with config objects. > > I do not agree with you that we can simply generate config true and ignore > RowStatus, StorageType, read-write MAX-ACCESS, writable OID nodes, etc. > But blinding forcing all OBJECT-TYPE macros to be read-only is not going to > be compatible with anything. (Consider how useful a converted RMON-MIB would > be if all the control tables were read-only, and the app could not create > any alarms/events, host, matrix, or other collections.) > > As for scalars: > > As long as the translation algorithm is deterministic, tools can deal with it. > IMO, one top-level container is OK, and won't be as optimal as hand-converted, > but easy to remember and construct XPath: > > augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" { ... } > > > leaf dumb-example { > type leafref { path "/if-mib:IF-MIB/if-mib:ifNumber"; } > } > > I prefer to have all the top-level MIB objects be child nodes of the NP container > according to the module name. In the MIB module, ifNumber and ifTable are siblings, > so they should be at the same level in the YANG translation. > > I don't see the value of preserving fooTable.fooEntry everywhere either. > The translated objects could really boil down to a sequence of leaf or list statements. > > module if-mib { > > container IF-MIB { > leaf ifNumber { config false; ... } > list ifEntry { ... } > } > notification linkUp { ... } > notification linkDown { ... } > > } Having all scalars flat was considered to be a bad idea. Please re-read the discussions we had about this. /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 Fri Jan 6 05:18:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37D21F8802 for ; Fri, 6 Jan 2012 05:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbXV1GQkHZDB for ; Fri, 6 Jan 2012 05:18:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B001121F87EF for ; Fri, 6 Jan 2012 05:18:53 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1030720BFA; Fri, 6 Jan 2012 14:18:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id puUWbRuFBFxO; Fri, 6 Jan 2012 14:18:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A909620BED; Fri, 6 Jan 2012 14:18:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AE89C1C5BF9B; Fri, 6 Jan 2012 14:18:35 +0100 (CET) Date: Fri, 6 Jan 2012 14:18:35 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120106131835.GB85995@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , netmod@ietf.org References: <201201052220.RAA29212@adminfs.snmp.com> <20120106073203.GB85155@elstar.local> <4F06E1D6.5010303@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F06E1D6.5010303@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:18:54 -0000 On Fri, Jan 06, 2012 at 03:58:14AM -0800, Andy Bierman wrote: > .... > > 3 more comments: > > 1) Why not just use exact-case, and the same string for module name and top-level container? > > OLD: > > module if-mib { > container IF-MIB {} > } > > NEW: > > module IF-MIB { > container IF-MIB {} > } Which problem is being solved? > 2) We should think very carefully about how SMIv2-converted YANG is going to > coexist with "new YANG", either vendor or SDO created. IMO, we don't > have a good solution for integrated data organization yet. How do we determine that we are done thinking carefully? > 3) We cannot rely on assumed translated output as the canonical > standard YANG version of an SMIv2 module, if the translation is > non-deterministic and implementations are free to choose > important details like config true/false. We want to be able to > reuse standard MIB modules without writing new RFCs for each one. The standard says it is read-only. As long as you assume just that, we are fine. And if an implementation implements something as a config object, it should announce this with proper deviations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Fri Jan 6 06:49:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5521F85A7 for ; Fri, 6 Jan 2012 06:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGbjRV1bpwUx for ; Fri, 6 Jan 2012 06:49:49 -0800 (PST) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4A54121F85A8 for ; Fri, 6 Jan 2012 06:49:47 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q06Eni4E029411 for ; Fri, 6 Jan 2012 09:49:46 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:58094] helo=[192.168.0.126]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4F/26-11818-80A070F4; Fri, 06 Jan 2012 09:49:44 -0500 Message-ID: <4F070A07.8040208@netconfcentral.org> Date: Fri, 06 Jan 2012 06:49:43 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid , netmod@ietf.org References: <201201052220.RAA29212@adminfs.snmp.com> <20120106073203.GB85155@elstar.local> <4F06E1D6.5010303@netconfcentral.org> <20120106131835.GB85995@elstar.local> In-Reply-To: <20120106131835.GB85995@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 14:49:50 -0000 On 01/06/2012 05:18 AM, Juergen Schoenwaelder wrote: > On Fri, Jan 06, 2012 at 03:58:14AM -0800, Andy Bierman wrote: >> .... >> >> 3 more comments: >> >> 1) Why not just use exact-case, and the same string for module name and top-level container? >> >> OLD: >> >> module if-mib { >> container IF-MIB {} >> } >> >> NEW: >> >> module IF-MIB { >> container IF-MIB {} >> } > > Which problem is being solved? IMO this is simpler -- less special cases. > >> 2) We should think very carefully about how SMIv2-converted YANG is going to >> coexist with "new YANG", either vendor or SDO created. IMO, we don't >> have a good solution for integrated data organization yet. > > How do we determine that we are done thinking carefully? I guess we just see if anybody uses converted SMI modules for anything. Those that really care about SNMP and NETCONF integration will figure it out. > >> 3) We cannot rely on assumed translated output as the canonical >> standard YANG version of an SMIv2 module, if the translation is >> non-deterministic and implementations are free to choose >> important details like config true/false. We want to be able to >> reuse standard MIB modules without writing new RFCs for each one. > > The standard says it is read-only. As long as you assume just that, we > are fine. And if an implementation implements something as a config > object, it should announce this with proper deviations. OK -- there aren't really enough writable SMIv2 objects to make that set of problems worth solving. People should use new YANG modules if any writable objects are needed. > > /js > Andy From reid@snmp.com Fri Jan 6 06:51:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812E621F87B9 for ; Fri, 6 Jan 2012 06:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EL4pMpeYV0p for ; Fri, 6 Jan 2012 06:51:49 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id A471121F8780 for ; Fri, 6 Jan 2012 06:51:48 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA26350; Fri, 6 Jan 2012 09:51:47 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA18614; Fri, 6 Jan 2012 09:51:40 -0500 (EST) Message-Id: <201201061451.JAA18614@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Fri, 06 Jan 2012 08:32:04 +0100. <20120106073203.GB85155@elstar.local> Date: Fri, 06 Jan 2012 09:51:40 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 14:51:49 -0000 > On Thu, Jan 05, 2012 at 05:20:51PM -0500, David Reid wrote: > > I'm looking at implementing the current smi to yang conversion rules in > > the netconf server. More specifically, I'm trying to use the converted > > yang module as the data model for netconf, snmp, cli, web, etc. I'm a > > little concerned about the current containment hierarchy. Maybe this isn't > > a problem, but let me try to explain my concern. > > > > I know that our charter only specifies a data modeling language for netconf, > > but I think there is a vision to use yang for more than just netconf and I > > know that this is happening in practice. What I would like to see in the > > future are documents kind of like RFC 3781 (SMIng mappings to SNMP) to > > define YANG mappings other protocols. One such mapping I would like to see > > is YANG to an EOS-like (Evolution of SNMP) version of SNMP. It might also > > include a mapping from a subset of yang to SNMPv3, allowing someone to write > > the model in yang (using the defined subset) and produce a MIB for SNMPv3 > > retrieval in addition to netconf. I'm not suggesting we do that now, but > > the current smi to yang mapping provides a very good foundation for that > > type of document. The only problem I see is that if the yang containment > > in the converted module conflicts with the OID hierarchy, a yang mapping to > > SNMP will be more difficult, and I don't want to do anything now that would > > make such a mapping document difficult or impossible in the future. > > > > It seems to me that allowing the yang containment to not match the OID > > hierarchy will make a yang mapping to SNMP more difficult. I'm not sure the > > best solution. It seems like we would need to flatten scalars (like the -01 > > draft) and remove the top level container. The problem with the top-level > > container is that it has no OID and thus does not fit in the SNMP world. The > > unflattened scalars make containers like "interfaces" contain different data > > depending on if it is retrieved in netconf or retrieved in SNMP. > > > > Of course I have all the OIDs in the converted yang module, so I can extract > > what I need for SNMP. But it seems wrong to have the data organized differently > > if retrieved through SNMP than through netconf. And I'm not sure which way > > to organize it when retrieved through the web interface or cli. > > > > I'm not sure if I stated my concern clearly, but I'm curious as to what some > > of the rest of you think. > > I think I do not understand your message. > > - Stuff that does not have an OID does not exist in the SNMP > world. Where is the problem? > > - We put scalars into containers for a specific reason. Is this not > true anymore? And why is this problematic? > > - The OID tree and the NETCONF containment tree are different things. > Just look at how augmentations work. For example, the ifXTable sits > somewhere pretty unrelated to the ifTable in the OID tree. Has this > ever been a serious problem? Augments has been one of the biggest pains to implement simply because of the difference in containment. (There is also a small performance hit, but I think it's negligible). I guess that's my problem with unflattened scalars. I implemented scalars based on the 01 draft and it was very easy. Now I'm looking to update to the 03 draft and it's going to be more challenging. Maybe implementation cost shouldn't be a big concern. It's not unimplementable, just harder. I think we put scalars into containers so that scalars in yang modules would have the same logical grouping that the MIB module has, which is a reasonable goal. But it conflicts with the desire to have the yang containment match the OID tree. -David Reid From reid@snmp.com Fri Jan 6 07:04:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8997121F8808 for ; Fri, 6 Jan 2012 07:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC2uxCoXuect for ; Fri, 6 Jan 2012 07:04:59 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id D3BAB21F864B for ; Fri, 6 Jan 2012 07:04:58 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA28422; Fri, 6 Jan 2012 10:04:57 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA19060; Fri, 6 Jan 2012 10:04:57 -0500 (EST) Message-Id: <201201061504.KAA19060@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Fri, 06 Jan 2012 06:49:43 -0800. <4F070A07.8040208@netconfcentral.org> Date: Fri, 06 Jan 2012 10:04:57 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:04:59 -0000 > On 01/06/2012 05:18 AM, Juergen Schoenwaelder wrote: > > On Fri, Jan 06, 2012 at 03:58:14AM -0800, Andy Bierman wrote: > >> .... > >> > >> 3 more comments: > >> > >> 1) Why not just use exact-case, and the same string for module name and top-level container? > >> > >> OLD: > >> > >> module if-mib { > >> container IF-MIB {} > >> } > >> > >> NEW: > >> > >> module IF-MIB { > >> container IF-MIB {} > >> } > > > > Which problem is being solved? > > IMO this is simpler -- less special cases. I'm confused. The current draft specifies the "NEW:" case above, correct? What is the proposed change? -David Reid From andy@netconfcentral.org Fri Jan 6 09:09:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C4021F8540 for ; Fri, 6 Jan 2012 09:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYJ4dW9sfj+D for ; Fri, 6 Jan 2012 09:09:42 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 67A5321F854E for ; Fri, 6 Jan 2012 09:09:39 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q06H9aHI019236 for ; Fri, 6 Jan 2012 12:09:38 -0500 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33898] helo=[192.168.0.126]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 84/03-12338-0DA270F4; Fri, 06 Jan 2012 12:09:36 -0500 Message-ID: <4F072ACF.7040703@netconfcentral.org> Date: Fri, 06 Jan 2012 09:09:35 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid References: <201201061504.KAA19060@adminfs.snmp.com> In-Reply-To: <201201061504.KAA19060@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:09:42 -0000 On 01/06/2012 07:04 AM, David Reid wrote: >> On 01/06/2012 05:18 AM, Juergen Schoenwaelder wrote: >>> On Fri, Jan 06, 2012 at 03:58:14AM -0800, Andy Bierman wrote: >>>> .... >>>> >>>> 3 more comments: >>>> >>>> 1) Why not just use exact-case, and the same string for module name and top-level container? >>>> >>>> OLD: >>>> >>>> module if-mib { >>>> container IF-MIB {} >>>> } >>>> >>>> NEW: >>>> >>>> module IF-MIB { >>>> container IF-MIB {} >>>> } >>> >>> Which problem is being solved? >> >> IMO this is simpler -- less special cases. > > I'm confused. The current draft specifies the "NEW:" case above, correct? > What is the proposed change? > None I guess. I was confused too -- the prefixes are still lower-case, even though the module name is now upper-case. I suppose forcing lower-case prefixes is some sort of feature in somebody's mind. > -David Reid > > Andy From mbj@tail-f.com Fri Jan 6 12:30:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1539B21F857D for ; Fri, 6 Jan 2012 12:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsJQMNj483Ir for ; Fri, 6 Jan 2012 12:30:31 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 857F321F8582 for ; Fri, 6 Jan 2012 12:30:31 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DFC21200AE5; Fri, 6 Jan 2012 21:30:23 +0100 (CET) Date: Fri, 06 Jan 2012 21:30:23 +0100 (CET) Message-Id: <20120106.213023.241597289.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F072ACF.7040703@netconfcentral.org> References: <201201061504.KAA19060@adminfs.snmp.com> <4F072ACF.7040703@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:30:32 -0000 Andy, Andy Bierman wrote: > I suppose forcing lower-case prefixes is some sort of > feature in somebody's mind. What is this forcing of lower case prefix you are talking about? If you read the latest document (-03), you will see that an implementation is free to pick any prefix it wants. /martin From mbj@tail-f.com Fri Jan 6 13:03:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75B21F8779 for ; Fri, 6 Jan 2012 13:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF0p0kNI9fdl for ; Fri, 6 Jan 2012 13:03:42 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAF321F876D for ; Fri, 6 Jan 2012 13:03:42 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8403F1200AE5; Fri, 6 Jan 2012 22:03:40 +0100 (CET) Date: Fri, 06 Jan 2012 22:03:39 +0100 (CET) Message-Id: <20120106.220339.395527808.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201201060500.AAA07832@adminfs.snmp.com> References: <201201060500.AAA07832@adminfs.snmp.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:03:46 -0000 David Reid wrote: > Does that mean my non-standard translation would need to use a different > namespace? I really want to produce a translation that is interoperable > with other translations for read-only operations, but also allows config > true for clients using the same translated module. The way we do this now (not yet released) is that we generate the config false module, and an additional module (with another namespace) with deviation statements, changing config from false to true on the proper nodes. Then the deviation module is advertised as specified in 6020. A client that uses the same translated module + the same deviation module, will be able to use the config true nodes. A client that uses the same translated module, maybe from another compliant implementation, but without the deviations, will be able to the nodes that he thinks is config false. The only potential problem is what the client does when it sees the deviation module it doesn't know about... my guess it will just work since most clients won't care about the deviations ;) /martin From spakes@snmp.com Fri Jan 6 14:29:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414AE21F860E for ; Fri, 6 Jan 2012 14:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN7U568lvHse for ; Fri, 6 Jan 2012 14:29:49 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 26F9D21F860D for ; Fri, 6 Jan 2012 14:29:49 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA00918; Fri, 6 Jan 2012 17:29:45 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA29244; Fri, 6 Jan 2012 17:29:44 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 6 Jan 2012 17:29:44 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund In-Reply-To: <20120106.220339.395527808.mbj@tail-f.com> Message-ID: References: <201201060500.AAA07832@adminfs.snmp.com> <20120106.220339.395527808.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:29:50 -0000 On Fri, 6 Jan 2012, Martin Bjorklund wrote: > David Reid wrote: > > Does that mean my non-standard translation would need to use a different > > namespace? I really want to produce a translation that is interoperable > > with other translations for read-only operations, but also allows config > > true for clients using the same translated module. > > The way we do this now (not yet released) is that we generate the > config false module, and an additional module (with another namespace) > with deviation statements, changing config from false to true on the > proper nodes. Then the deviation module is advertised as specified in > 6020. > > A client that uses the same translated module + the same deviation > module, will be able to use the config true nodes. > > A client that uses the same translated module, maybe from another > compliant implementation, but without the deviations, will be able to > the nodes that he thinks is config false. The only potential > problem is what the client does when it sees the deviation module it > doesn't know about... my guess it will just work since most clients > won't care about the deviations ;) I have been thinking about a solution similar to yours, Martin, but one that does not require that the creation of an additional module of deviations. What I propose is that if a NETCONF client and server both understand smiv2:max-access, then for any object that is "config false" and either "smiv2:max-access read-write" or "smiv2:max-access read-create", 1. the NETCONF server can decide at run time to deliver the object in response to a or operation; and, 2. for any object that is returned for a , the NETCONF client can configure that object in an operation. Essentially, this is a protocol change between two capable and consenting NETCONF communication partners. There is a precedent for this in the RFCs: RFC 6241 describes a base NETCONF capability, "urn:ietf:params:netconf:base:1.1" (Section 8.1 on Page 50). RFC 6242 describes a use-case of the NETCONF agreeing to use a common capability that results in a protocol change (Section 4.1, on Page 5). What I propose is that we should define a new NETCONF capability to be used in conjunction with smiv2:max-access. The document should describe its use-case as I have outlined above. There are some other benefits to this approach: 1. If either NETCONF client or NETCONF server does not support the max-access capability, then the protocol works the "normal" way with respect to "config false"; i.e., the server will only return these objects in response to a , and the server will not accept these objects as part of an . 2. When a NETCONF server that understands smiv2:max-access communicates with two clients--one that does understand smiv2:max-access and one that does not understand smiv2:max-access--it negotiates the common set of features separately for each communication session. The server can behave differently (appropriately) for each client. 3. The server does not need to send a bunch of deviations in the message that some clients would not care about. 4. Some implementations may implement read-write objects as read-only. That's okay, because when the NETCONF client and NETCONF server both understand smiv2:max-access, the NETCONF server has the freedom to determine at run time whether it will return the "read-write" object in response to a or . The 'max' in 'max-access' becomes a true upper limit rather than a hard requirement of the server's capabilites. 5. The differences between NETCONF and SNMP persistency models only matter to applications that care about them and are prepared to deal with them. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Mon Jan 9 07:15:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DA121F87FA for ; Mon, 9 Jan 2012 07:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfB8snKqU+mn for ; Mon, 9 Jan 2012 07:15:04 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2B67E21F8797 for ; Mon, 9 Jan 2012 07:15:03 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA23929; Mon, 9 Jan 2012 10:14:58 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA03134; Mon, 9 Jan 2012 10:14:53 -0500 (EST) Message-Id: <201201091514.KAA03134@adminfs.snmp.com> To: David Spakes From: David Reid In-reply-to: Your message of Fri, 06 Jan 2012 17:29:44 -0500. Date: Mon, 09 Jan 2012 10:14:53 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:15:05 -0000 > On Fri, 6 Jan 2012, Martin Bjorklund wrote: > > > David Reid wrote: > > > Does that mean my non-standard translation would need to use a different > > > namespace? I really want to produce a translation that is interoperable > > > with other translations for read-only operations, but also allows config > > > true for clients using the same translated module. > > > > The way we do this now (not yet released) is that we generate the > > config false module, and an additional module (with another namespace) > > with deviation statements, changing config from false to true on the > > proper nodes. Then the deviation module is advertised as specified in > > 6020. > > > > A client that uses the same translated module + the same deviation > > module, will be able to use the config true nodes. > > > > A client that uses the same translated module, maybe from another > > compliant implementation, but without the deviations, will be able to > > the nodes that he thinks is config false. The only potential > > problem is what the client does when it sees the deviation module it > > doesn't know about... my guess it will just work since most clients > > won't care about the deviations ;) > > > I have been thinking about a solution similar to yours, Martin, but > one that does not require that the creation of an additional module of > deviations. > > What I propose is that > if a NETCONF client and server both understand smiv2:max-access, > then for any object that is "config false" and either > "smiv2:max-access read-write" or > "smiv2:max-access read-create", > > 1. the NETCONF server can decide at run time to deliver the > object in response to a or operation; and, > > 2. for any object that is returned for a , the > NETCONF client can configure that object in an > operation. > > > Essentially, this is a protocol change between two capable and > consenting NETCONF communication partners. There is a precedent > for this in the RFCs: > > RFC 6241 describes a base NETCONF capability, > "urn:ietf:params:netconf:base:1.1" (Section 8.1 on Page 50). > > RFC 6242 describes a use-case of the NETCONF agreeing to use a > common capability that results in a protocol change > (Section 4.1, on Page 5). > > > What I propose is that we should define a new NETCONF capability > to be used in conjunction with smiv2:max-access. The document > should describe its use-case as I have outlined above. > > There are some other benefits to this approach: > > 1. If either NETCONF client or NETCONF server does not support > the max-access capability, then the protocol works the "normal" > way with respect to "config false"; i.e., the server will only > return these objects in response to a , and the server > will not accept these objects as part of an . > > 2. When a NETCONF server that understands smiv2:max-access > communicates with two clients--one that does understand > smiv2:max-access and one that does not understand > smiv2:max-access--it negotiates the common set of features > separately for each communication session. The server can > behave differently (appropriately) for each client. > > 3. The server does not need to send a bunch of deviations in > the message that some clients would not care about. > > 4. Some implementations may implement read-write objects as > read-only. That's okay, because when the NETCONF client > and NETCONF server both understand smiv2:max-access, the > NETCONF server has the freedom to determine at run time > whether it will return the "read-write" object in response > to a or . The 'max' in 'max-access' > becomes a true upper limit rather than a hard requirement > of the server's capabilites. > > 5. The differences between NETCONF and SNMP persistency models > only matter to applications that care about them and are > prepared to deal with them. > > > -dss Could we put something in the document to indicate that proprietary mechanisms to allow config true for some objects is OK so that things like what Martin is doing or what David Spakes is thinking about are not considered non-compliant? -David Reid From andy@netconfcentral.org Mon Jan 9 07:56:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7780111E8071 for ; Mon, 9 Jan 2012 07:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQhwSkfMUwNF for ; Mon, 9 Jan 2012 07:56:23 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6182E11E8080 for ; Mon, 9 Jan 2012 07:56:21 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q09FuIck018090 for ; Mon, 9 Jan 2012 10:56:20 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:52099] helo=[192.168.0.126]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 81/51-28181-22E0B0F4; Mon, 09 Jan 2012 10:56:18 -0500 Message-ID: <4F0B0E1E.3080207@netconfcentral.org> Date: Mon, 09 Jan 2012 07:56:14 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Reid References: <201201091514.KAA03134@adminfs.snmp.com> In-Reply-To: <201201091514.KAA03134@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:56:24 -0000 On 01/09/2012 07:14 AM, David Reid wrote: >> On Fri, 6 Jan 2012, Martin Bjorklund wrote: >> >>> David Reid wrote: >>>> Does that mean my non-standard translation would need to use a different >>>> namespace? I really want to produce a translation that is interoperable >>>> with other translations for read-only operations, but also allows config >>>> true for clients using the same translated module. >>> >>> The way we do this now (not yet released) is that we generate the >>> config false module, and an additional module (with another namespace) >>> with deviation statements, changing config from false to true on the >>> proper nodes. Then the deviation module is advertised as specified in >>> 6020. >>> >>> A client that uses the same translated module + the same deviation >>> module, will be able to use the config true nodes. >>> >>> A client that uses the same translated module, maybe from another >>> compliant implementation, but without the deviations, will be able to >>> the nodes that he thinks is config false. The only potential >>> problem is what the client does when it sees the deviation module it >>> doesn't know about... my guess it will just work since most clients >>> won't care about the deviations ;) >> >> >> I have been thinking about a solution similar to yours, Martin, but >> one that does not require that the creation of an additional module of >> deviations. >> >> What I propose is that >> if a NETCONF client and server both understand smiv2:max-access, >> then for any object that is "config false" and either >> "smiv2:max-access read-write" or >> "smiv2:max-access read-create", >> >> 1. the NETCONF server can decide at run time to deliver the >> object in response to a or operation; and, >> >> 2. for any object that is returned for a, the >> NETCONF client can configure that object in an >> operation. >> >> >> Essentially, this is a protocol change between two capable and >> consenting NETCONF communication partners. There is a precedent >> for this in the RFCs: >> >> RFC 6241 describes a base NETCONF capability, >> "urn:ietf:params:netconf:base:1.1" (Section 8.1 on Page 50). >> >> RFC 6242 describes a use-case of the NETCONF agreeing to use a >> common capability that results in a protocol change >> (Section 4.1, on Page 5). >> >> >> What I propose is that we should define a new NETCONF capability >> to be used in conjunction with smiv2:max-access. The document >> should describe its use-case as I have outlined above. >> >> There are some other benefits to this approach: >> >> 1. If either NETCONF client or NETCONF server does not support >> the max-access capability, then the protocol works the "normal" >> way with respect to "config false"; i.e., the server will only >> return these objects in response to a, and the server >> will not accept these objects as part of an. >> >> 2. When a NETCONF server that understands smiv2:max-access >> communicates with two clients--one that does understand >> smiv2:max-access and one that does not understand >> smiv2:max-access--it negotiates the common set of features >> separately for each communication session. The server can >> behave differently (appropriately) for each client. >> >> 3. The server does not need to send a bunch of deviations in >> the message that some clients would not care about. >> >> 4. Some implementations may implement read-write objects as >> read-only. That's okay, because when the NETCONF client >> and NETCONF server both understand smiv2:max-access, the >> NETCONF server has the freedom to determine at run time >> whether it will return the "read-write" object in response >> to a or. The 'max' in 'max-access' >> becomes a true upper limit rather than a hard requirement >> of the server's capabilites. >> >> 5. The differences between NETCONF and SNMP persistency models >> only matter to applications that care about them and are >> prepared to deal with them. >> >> >> -dss > > Could we put something in the document to indicate that proprietary mechanisms > to allow config true for some objects is OK so that things like what Martin > is doing or what David Spakes is thinking about are not considered > non-compliant? I do not support this change. I do not see a lot of value in this standard if every 'compliant' implementation can produce a different outcome for a core YANG statements like config-stmt. The argument "a client can only count on read-only" doesn't really make sense to me. What client? A YANG-aware client will just use the valid YANG it is given and may know nothing about the source SMIv2. An SMIv2-aware client will expect the NETCONF translation of its SNMP operations to work, and read-only does not help. The config-stmt cannot be ignored by the server, even if a client can "just use ". It seems to me the most interesting use-case is a device which provides SNMP access or NETCONF access to the same data model. Key word: 'same'. Converting the MAX-ACCESS incorrectly is pointless for this use-case. So what is the use-case for blanket read-only? Is it supposed to be "NETCONF access to SNMP monitoring data"? Is anybody implementing that? > > -David Reid Andy From spakes@snmp.com Mon Jan 9 08:56:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D1B21F8499 for ; Mon, 9 Jan 2012 08:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ascYD0ukqat7 for ; Mon, 9 Jan 2012 08:56:22 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id A15EA21F849C for ; Mon, 9 Jan 2012 08:56:21 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA15513; Mon, 9 Jan 2012 11:56:20 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA04346; Mon, 9 Jan 2012 11:56:19 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 9 Jan 2012 11:56:19 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4F0B0E1E.3080207@netconfcentral.org> Message-ID: References: <201201091514.KAA03134@adminfs.snmp.com> <4F0B0E1E.3080207@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:56:26 -0000 On Mon, 9 Jan 2012, Andy Bierman wrote: > On 01/09/2012 07:14 AM, David Reid wrote: > >> On Fri, 6 Jan 2012, Martin Bjorklund wrote: > >> > >>> David Reid wrote: > >>>> Does that mean my non-standard translation would need to use a different > >>>> namespace? I really want to produce a translation that is interoperable > >>>> with other translations for read-only operations, but also allows config > >>>> true for clients using the same translated module. > >>> > >>> The way we do this now (not yet released) is that we generate the > >>> config false module, and an additional module (with another namespace) > >>> with deviation statements, changing config from false to true on the > >>> proper nodes. Then the deviation module is advertised as specified in > >>> 6020. > >>> > >>> A client that uses the same translated module + the same deviation > >>> module, will be able to use the config true nodes. > >>> > >>> A client that uses the same translated module, maybe from another > >>> compliant implementation, but without the deviations, will be able to > >>> the nodes that he thinks is config false. The only potential > >>> problem is what the client does when it sees the deviation module it > >>> doesn't know about... my guess it will just work since most clients > >>> won't care about the deviations ;) > >> > >> > >> I have been thinking about a solution similar to yours, Martin, but > >> one that does not require that the creation of an additional module of > >> deviations. > >> > >> What I propose is that > >> if a NETCONF client and server both understand smiv2:max-access, > >> then for any object that is "config false" and either > >> "smiv2:max-access read-write" or > >> "smiv2:max-access read-create", > >> > >> 1. the NETCONF server can decide at run time to deliver the > >> object in response to a or operation; and, > >> > >> 2. for any object that is returned for a, the > >> NETCONF client can configure that object in an > >> operation. > >> > >> > >> Essentially, this is a protocol change between two capable and > >> consenting NETCONF communication partners. There is a precedent > >> for this in the RFCs: > >> > >> RFC 6241 describes a base NETCONF capability, > >> "urn:ietf:params:netconf:base:1.1" (Section 8.1 on Page 50). > >> > >> RFC 6242 describes a use-case of the NETCONF agreeing to use a > >> common capability that results in a protocol change > >> (Section 4.1, on Page 5). > >> > >> > >> What I propose is that we should define a new NETCONF capability > >> to be used in conjunction with smiv2:max-access. The document > >> should describe its use-case as I have outlined above. > >> > >> There are some other benefits to this approach: > >> > >> 1. If either NETCONF client or NETCONF server does not support > >> the max-access capability, then the protocol works the "normal" > >> way with respect to "config false"; i.e., the server will only > >> return these objects in response to a, and the server > >> will not accept these objects as part of an. > >> > >> 2. When a NETCONF server that understands smiv2:max-access > >> communicates with two clients--one that does understand > >> smiv2:max-access and one that does not understand > >> smiv2:max-access--it negotiates the common set of features > >> separately for each communication session. The server can > >> behave differently (appropriately) for each client. > >> > >> 3. The server does not need to send a bunch of deviations in > >> the message that some clients would not care about. > >> > >> 4. Some implementations may implement read-write objects as > >> read-only. That's okay, because when the NETCONF client > >> and NETCONF server both understand smiv2:max-access, the > >> NETCONF server has the freedom to determine at run time > >> whether it will return the "read-write" object in response > >> to a or. The 'max' in 'max-access' > >> becomes a true upper limit rather than a hard requirement > >> of the server's capabilites. > >> > >> 5. The differences between NETCONF and SNMP persistency models > >> only matter to applications that care about them and are > >> prepared to deal with them. > >> > >> > >> -dss > > > > Could we put something in the document to indicate that proprietary > > mechanisms to allow config true for some objects is OK so that things > > like what Martin is doing or what David Spakes is thinking about are > > not considered non-compliant? > > I do not support this change. > I do not see a lot of value in this standard if every 'compliant' > implementation can produce a different outcome for a core YANG > statements like config-stmt. > > The argument "a client can only count on read-only" doesn't really make > sense to me. What client? A YANG-aware client will just use the valid > YANG it is given and may know nothing about the source SMIv2. An > SMIv2-aware client will expect the NETCONF translation of its SNMP > operations to work, and read-only does not help. > > The config-stmt cannot be ignored by the server, even if a client can > "just use ". > > It seems to me the most interesting use-case is a device which provides > SNMP access or NETCONF access to the same data model. Key word: 'same'. > Converting the MAX-ACCESS incorrectly is pointless for this use-case. > > So what is the use-case for blanket read-only? Is it supposed to be > "NETCONF access to SNMP monitoring data"? Is anybody implementing that? The situation is actually "NETCONF access to SNMP state data and SNMP configuration data". The blanket read-only is intended for applications that are YANG-aware but not SMIv2-aware. Like Juergen pointed out, with today's NETCONF operations, writing always means editing a configuration datastore and not some operational state. Applications that are SMIv2-aware are going to attempt to do something useful with the smiv2: extensions. I don't want to see application developers needing to do something proprietary in this case. I would much rather see this document open the door on a standards-based approach. I think having the smiv2:max-access extension is a superb design because applications that are only YANG-aware can ignore it. My proposal that this document also define a NETCONF "capability" is a logical extension of this same thread of compromise. NETCONF clients that do not support the capability never see the SNMP configuration data as anything other than "config false". -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@netconfcentral.org Mon Jan 9 09:56:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4B11E8080 for ; Mon, 9 Jan 2012 09:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqQVbO6FdtUx for ; Mon, 9 Jan 2012 09:56:11 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id B12D921F85EC for ; Mon, 9 Jan 2012 09:56:07 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q09Hu438029798 for ; Mon, 9 Jan 2012 12:56:06 -0500 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:51558] helo=[192.168.0.126]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D2/7C-09786-43A2B0F4; Mon, 09 Jan 2012 12:56:04 -0500 Message-ID: <4F0B2A30.2010809@netconfcentral.org> Date: Mon, 09 Jan 2012 09:56:00 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes References: <201201091514.KAA03134@adminfs.snmp.com> <4F0B0E1E.3080207@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:56:11 -0000 On 01/09/2012 08:56 AM, David Spakes wrote: ... > I think having the smiv2:max-access extension is a superb design because > applications that are only YANG-aware can ignore it. My proposal that > this document also define a NETCONF "capability" is a logical extension > of this same thread of compromise. NETCONF clients that do not support > the capability never see the SNMP configuration data as anything other > than "config false". I don't think any capability is needed. The client can use the same source YANG file as the server (with the smiv2:max-access statements in it). The standard translation can always generate 'config false' (with no exceptions). An application that chooses to pay attention to smiv2:max-access will work. The conceptual config-stmt can always be correctly derived by the application, since the translator tool must put the the smiv2 extensions in the output YANG file. > > -dss Andy From spakes@snmp.com Mon Jan 9 12:25:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2380E21F86FC for ; Mon, 9 Jan 2012 12:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B006e5t4m5w1 for ; Mon, 9 Jan 2012 12:25:20 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id EEC4221F8466 for ; Mon, 9 Jan 2012 12:25:18 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA12817; Mon, 9 Jan 2012 15:25:04 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA06747; Mon, 9 Jan 2012 15:24:53 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 9 Jan 2012 15:24:53 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4F0B2A30.2010809@netconfcentral.org> Message-ID: References: <201201091514.KAA03134@adminfs.snmp.com> <4F0B0E1E.3080207@netconfcentral.org> <4F0B2A30.2010809@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:25:21 -0000 On Mon, 9 Jan 2012, Andy Bierman wrote: > On 01/09/2012 08:56 AM, David Spakes wrote: > ... > > I think having the smiv2:max-access extension is a superb design because > > applications that are only YANG-aware can ignore it. My proposal that > > this document also define a NETCONF "capability" is a logical extension > > of this same thread of compromise. NETCONF clients that do not support > > the capability never see the SNMP configuration data as anything other > > than "config false". > > > I don't think any capability is needed. The client can use the same > source YANG file as the server (with the smiv2:max-access statements in > it). The standard translation can always generate 'config false' (with > no exceptions). An application that chooses to pay attention to > smiv2:max-access will work. The conceptual config-stmt can always be > correctly derived by the application, since the translator tool must put > the the smiv2 extensions in the output YANG file. What do you mean by the application "will work"? A NETCONF-centric SMIv2-aware application is going to be expected to modify SNMP configuration data. The question that several of us are asking is, how does such an application edit "config false" values and do it in a way that is compliant with the spec? Are you suggesting that it is compliant for a NETCONF client and server with knowledge of smiv2:max-acccess to treat some "config false" leaf objects as though they are "config true" without exercising some other mechanism like a deviation or NETCONF capability? -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From mbj@tail-f.com Mon Jan 9 13:37:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D824911E8075 for ; Mon, 9 Jan 2012 13:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9645zoL02io for ; Mon, 9 Jan 2012 13:37:02 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5280A21F86C4 for ; Mon, 9 Jan 2012 13:37:02 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D1231200AC0; Mon, 9 Jan 2012 22:36:59 +0100 (CET) Date: Mon, 09 Jan 2012 22:36:57 +0100 (CET) Message-Id: <20120109.223657.252909529.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <201201060500.AAA07832@adminfs.snmp.com> <20120106.220339.395527808.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:37:03 -0000 Hi, David Spakes wrote: > I have been thinking about a solution similar to yours, Martin, but > one that does not require that the creation of an additional module of > deviations. > > What I propose is that > if a NETCONF client and server both understand smiv2:max-access, > then for any object that is "config false" and either > "smiv2:max-access read-write" or > "smiv2:max-access read-create", > > 1. the NETCONF server can decide at run time to deliver the > object in response to a or operation; and, > > 2. for any object that is returned for a , the > NETCONF client can configure that object in an > operation. [...] > What I propose is that we should define a new NETCONF capability > to be used in conjunction with smiv2:max-access. The document > should describe its use-case as I have outlined above. I have two concerns with this idea. 1. The client has to do a in order to know which nodes are config; data model information only is not enough. Suppose there's a list that a server treats as config, but it is currently empty. It won't be part of , so the client doesn't know it is config, and cannot create anything in it. 2. It is weird if client A advertises the new capability, sends a and gets some data, but client B (assuming same access rules) gets a subset of this. This breaks the backup/restore use case. The only safe way to get the complete config db is to advertise the new capability, so essentially if a server implements this capability, clients must also implement it to function properly. /martin From mbj@tail-f.com Mon Jan 9 13:42:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5342021F87FE for ; Mon, 9 Jan 2012 13:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEQJRPfx4aV2 for ; Mon, 9 Jan 2012 13:42:02 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CF6EE21F8783 for ; Mon, 9 Jan 2012 13:41:59 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 04A6A1200AC0; Mon, 9 Jan 2012 22:41:59 +0100 (CET) Date: Mon, 09 Jan 2012 22:41:56 +0100 (CET) Message-Id: <20120109.224156.341976508.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201201091514.KAA03134@adminfs.snmp.com> References: <201201091514.KAA03134@adminfs.snmp.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:42:02 -0000 Hi, David Reid wrote: > Could we put something in the document to indicate that proprietary mechanisms > to allow config true for some objects is OK so that things like what Martin > is doing or what David Spakes is thinking about are not considered > non-compliant? My deviation-based solution does not require any changes to the current document. In fact, if we put in words that allowed a server to implemnet some nodes as config, I wouldn't have to use my deviations at all! /martin From wwwrun@rfc-editor.org Mon Jan 9 13:47:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0F011E809B for ; Mon, 9 Jan 2012 13:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOvz6RTAYyVw for ; Mon, 9 Jan 2012 13:47:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3E11E807A for ; Mon, 9 Jan 2012 13:47:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EA31872E004; Mon, 9 Jan 2012 13:44:57 -0800 (PST) To: mbj@tail-f.com, dromasca@avaya.com, rbonica@juniper.net, david.kessens@nsn.com, j.schoenwaelder@jacobs-university.de From: RFC Errata System Message-Id: <20120109214457.EA31872E004@rfc-editor.org> Date: Mon, 9 Jan 2012 13:44:57 -0800 (PST) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3087) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:47:31 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3087 -------------------------------------- Type: Technical Reported by: Martin Bjorklund Section: 12 Original Text ------------- deviate-add-stmt = deviate-keyword sep add-keyword optsep (";" / "{" stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") deviate-delete-stmt = deviate-keyword sep delete-keyword optsep (";" / "{" stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] "}") deviate-replace-stmt = deviate-keyword sep replace-keyword optsep (";" / "{" stmtsep [type-stmt stmtsep] [units-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") Corrected Text -------------- deviate-add-stmt = deviate-keyword sep add-keyword optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") deviate-delete-stmt = deviate-keyword sep delete-keyword optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] "}") deviate-replace-stmt = deviate-keyword sep replace-keyword optsep (";" / "{" stmtsep ;; these stmts can appear in any order [type-stmt stmtsep] [units-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") Notes ----- The comment "these stmts can appear in any order" is missing from these three statements. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From andy@netconfcentral.org Mon Jan 9 13:53:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523A921F85EA for ; Mon, 9 Jan 2012 13:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, DIET_1=0.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roq3typKL+ED for ; Mon, 9 Jan 2012 13:53:15 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id C480821F85D5 for ; Mon, 9 Jan 2012 13:53:15 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q09LrCGn023632 for ; Mon, 9 Jan 2012 16:53:14 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:49747] helo=[192.168.0.126]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4F/DE-23837-7C16B0F4; Mon, 09 Jan 2012 16:53:12 -0500 Message-ID: <4F0B61C7.7040506@netconfcentral.org> Date: Mon, 09 Jan 2012 13:53:11 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes References: <201201091514.KAA03134@adminfs.snmp.com> <4F0B0E1E.3080207@netconfcentral.org> <4F0B2A30.2010809@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:53:16 -0000 On 01/09/2012 12:24 PM, David Spakes wrote: > On Mon, 9 Jan 2012, Andy Bierman wrote: > >> On 01/09/2012 08:56 AM, David Spakes wrote: >> ... >>> I think having the smiv2:max-access extension is a superb design because >>> applications that are only YANG-aware can ignore it. My proposal that >>> this document also define a NETCONF "capability" is a logical extension >>> of this same thread of compromise. NETCONF clients that do not support >>> the capability never see the SNMP configuration data as anything other >>> than "config false". >> >> >> I don't think any capability is needed. The client can use the same >> source YANG file as the server (with the smiv2:max-access statements in >> it). The standard translation can always generate 'config false' (with >> no exceptions). An application that chooses to pay attention to >> smiv2:max-access will work. The conceptual config-stmt can always be >> correctly derived by the application, since the translator tool must put >> the the smiv2 extensions in the output YANG file. > > > What do you mean by the application "will work"? It can use the smiv2:max-access statement to figure out what the device will support, or the server can use deviation statements to patch in the config true statements as needed. > > A NETCONF-centric SMIv2-aware application is going to be expected to > modify SNMP configuration data. The question that several of us are > asking is, how does such an application edit "config false" values > and do it in a way that is compliant with the spec? > > Are you suggesting that it is compliant for a NETCONF client and server > with knowledge of smiv2:max-acccess to treat some "config false" leaf > objects as though they are "config true" without exercising some other > mechanism like a deviation or NETCONF capability? The deviations would be needed in order for the server to advertise the YANG module with altered config-stmts. > > -dss > Andy From mbj@tail-f.com Mon Jan 9 14:00:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A247611E8079 for ; Mon, 9 Jan 2012 14:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2VogNr70L-y for ; Mon, 9 Jan 2012 14:00:11 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7011E8075 for ; Mon, 9 Jan 2012 14:00:10 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2C56B1200AC0; Mon, 9 Jan 2012 23:00:10 +0100 (CET) Date: Mon, 09 Jan 2012 23:00:08 +0100 (CET) Message-Id: <20120109.230008.324257545.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F0B61C7.7040506@netconfcentral.org> References: <4F0B2A30.2010809@netconfcentral.org> <4F0B61C7.7040506@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 22:00:11 -0000 Andy Bierman wrote: > On 01/09/2012 12:24 PM, David Spakes wrote: > > On Mon, 9 Jan 2012, Andy Bierman wrote: > > > >> On 01/09/2012 08:56 AM, David Spakes wrote: > >> ... > >>> I think having the smiv2:max-access extension is a superb design because > >>> applications that are only YANG-aware can ignore it. My proposal that > >>> this document also define a NETCONF "capability" is a logical extension > >>> of this same thread of compromise. NETCONF clients that do not support > >>> the capability never see the SNMP configuration data as anything other > >>> than "config false". > >> > >> > >> I don't think any capability is needed. The client can use the same > >> source YANG file as the server (with the smiv2:max-access statements in > >> it). The standard translation can always generate 'config false' (with > >> no exceptions). An application that chooses to pay attention to > >> smiv2:max-access will work. The conceptual config-stmt can always be > >> correctly derived by the application, since the translator tool must put > >> the the smiv2 extensions in the output YANG file. > > > > > > What do you mean by the application "will work"? > > It can use the smiv2:max-access statement to figure out what the device will > support, The problem is that max-access >= read-write does not imply that it is config. Also, it is *max* access; an SNMP agent may implement some of these objects read-only. /martin From andy@netconfcentral.org Mon Jan 9 14:04:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C759821F85BE for ; Mon, 9 Jan 2012 14:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dVLg6PQRRx3 for ; Mon, 9 Jan 2012 14:04:52 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4F21F855E for ; Mon, 9 Jan 2012 14:04:35 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q09M4Y7r011120 for ; Mon, 9 Jan 2012 17:04:34 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:52313] helo=[192.168.0.126]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 99/22-15882-2746B0F4; Mon, 09 Jan 2012 17:04:34 -0500 Message-ID: <4F0B6471.3070101@netconfcentral.org> Date: Mon, 09 Jan 2012 14:04:33 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Bjorklund References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> In-Reply-To: <20120109.224156.341976508.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 22:04:52 -0000 On 01/09/2012 01:41 PM, Martin Bjorklund wrote: > Hi, > > David Reid wrote: >> Could we put something in the document to indicate that proprietary mechanisms >> to allow config true for some objects is OK so that things like what Martin >> is doing or what David Spakes is thinking about are not considered >> non-compliant? > > My deviation-based solution does not require any changes to the > current document. In fact, if we put in words that allowed a server > to implemnet some nodes as config, I wouldn't have to use my > deviations at all! > I think the deviations solution is fine. Or a vendor can edit the file as needed, change the revision-date, and advertise the 'update' instead of the direct translation. I do not agree that simply allowing translators to ad-hoc generate config true instead of config false is an inter-operable solution. The output of this standard is the YANG module, not the server implementation of the YANG module. Two independent implementations of the standard translator should produce equivalent results. The deviations approach is a good start, and maybe in the future there can be additional mechanisms for standard translators to produce config true. > > /martin Andy From spakes@snmp.com Mon Jan 9 14:37:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D823121F85D4 for ; Mon, 9 Jan 2012 14:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPJGRS4wJsEh for ; Mon, 9 Jan 2012 14:37:13 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id E4F9F21F8569 for ; Mon, 9 Jan 2012 14:37:12 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA23195; Mon, 9 Jan 2012 17:36:59 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA07644; Mon, 9 Jan 2012 17:36:54 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 9 Jan 2012 17:36:53 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4F0B6471.3070101@netconfcentral.org> Message-ID: References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 22:37:14 -0000 On Mon, 9 Jan 2012, Andy Bierman wrote: > On 01/09/2012 01:41 PM, Martin Bjorklund wrote: > > Hi, > > > > David Reid wrote: > >> Could we put something in the document to indicate that proprietary mechanisms > >> to allow config true for some objects is OK so that things like what Martin > >> is doing or what David Spakes is thinking about are not considered > >> non-compliant? > > > > My deviation-based solution does not require any changes to the > > current document. In fact, if we put in words that allowed a server > > to implemnet some nodes as config, I wouldn't have to use my > > deviations at all! One of my concerns about the deviation-based solution is that software that implements it is not considered to be compliant to the spec. RFC 6020, Section 7.18.3, Page 103: Device deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. A device that deviates from a module is not fully compliant with the module. I believe this text was written for the case that an implementation can't meet the minimum requirements of the YANG contract. However, Martin's implementation goes beyond the contract to provide additional abilities that are not specified in the contract. It seems unfair to Martin that his approach might be considered by some to be non-compliant according to RFC 6020. Now, if the ietf-yang-smiv2 included a paragraph that states explicitly that going beyond the contract in this case is not considered to be non-compliant, then all is well. Is everyone comfortable adding such a paragraph? > I think the deviations solution is fine. > Or a vendor can edit the file as needed, change the revision-date, > and advertise the 'update' instead of the direct translation. You are suggesting that a leaf can be changed from "config false" to "config true" in a subsequent revision? I didn't think that was allowed by the YANG spec... > I do not agree that simply allowing translators to ad-hoc generate > config true instead of config false is an inter-operable solution. The solution I proposed would allow the translation to always be "config false". The document would define the NETCONF capability in order to leave the door open for implementations to do on objects that are "smiv2:max-access read-write" or "smiv2:max-access read-create". > The output of this standard is the YANG module, not the server > implementation of the YANG module. Right. The mechanism that NETCONF clients and servers use to accomplish edits on "config false" leaf objects need not be spelled out in this document. Adding the aforementioned paragraph and/or defining the NETCONF capability just leaves the door open for this eventuality. > Two independent implementations of the standard translator should > produce equivalent results. Two independent implementations of the standard translator should produce the equivalent YANG document from the same SMIv2 document. > The deviations approach is a good start, and maybe in the future there > can be additional mechanisms for standard translators to produce config > true. Which is where my compromise proposal comes in. This document just props the door open with regard to this point. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@netconfcentral.org Mon Jan 9 15:25:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DC811E80D6 for ; Mon, 9 Jan 2012 15:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omA9d2rOgC3m for ; Mon, 9 Jan 2012 15:25:25 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1511E80D8 for ; Mon, 9 Jan 2012 15:25:25 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q09NPLSA022609 for ; Mon, 9 Jan 2012 18:25:24 -0500 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:42709] helo=[192.168.0.126]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EF/AB-09786-1677B0F4; Mon, 09 Jan 2012 18:25:21 -0500 Message-ID: <4F0B7760.6050409@netconfcentral.org> Date: Mon, 09 Jan 2012 15:25:20 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:25:26 -0000 On 01/09/2012 02:36 PM, David Spakes wrote: > On Mon, 9 Jan 2012, Andy Bierman wrote: > I think YANG deviations already provides a solution. I think the original charter scope (read-only translation) is still appropriate. IMO, the standard says the translation is read-only. That is what a compliant translator must produce. As for editing the file, I meant that a vendor would never advertise the original, so there would not really be a 2nd revision. But deviations are the standard approach. Andy >> On 01/09/2012 01:41 PM, Martin Bjorklund wrote: >>> Hi, >>> >>> David Reid wrote: >>>> Could we put something in the document to indicate that proprietary mechanisms >>>> to allow config true for some objects is OK so that things like what Martin >>>> is doing or what David Spakes is thinking about are not considered >>>> non-compliant? >>> >>> My deviation-based solution does not require any changes to the >>> current document. In fact, if we put in words that allowed a server >>> to implemnet some nodes as config, I wouldn't have to use my >>> deviations at all! > > > One of my concerns about the deviation-based solution is that software > that implements it is not considered to be compliant to the spec. > > RFC 6020, Section 7.18.3, Page 103: > > Device deviations are strongly discouraged and MUST only be used as a > last resort. Telling the application how a device fails to follow a > standard is no substitute for implementing the standard correctly. A > device that deviates from a module is not fully compliant with the > module. > > I believe this text was written for the case that an implementation can't > meet the minimum requirements of the YANG contract. However, Martin's > implementation goes beyond the contract to provide additional abilities > that are not specified in the contract. It seems unfair to Martin that > his approach might be considered by some to be non-compliant according > to RFC 6020. > > Now, if the ietf-yang-smiv2 included a paragraph that states explicitly > that going beyond the contract in this case is not considered to be > non-compliant, then all is well. Is everyone comfortable adding such > a paragraph? > > >> I think the deviations solution is fine. >> Or a vendor can edit the file as needed, change the revision-date, >> and advertise the 'update' instead of the direct translation. > > You are suggesting that a leaf can be changed from "config false" to > "config true" in a subsequent revision? I didn't think that was allowed > by the YANG spec... > > >> I do not agree that simply allowing translators to ad-hoc generate >> config true instead of config false is an inter-operable solution. > > The solution I proposed would allow the translation to always be > "config false". The document would define the NETCONF capability > in order to leave the door open for implementations to do > on objects that are "smiv2:max-access read-write" or > "smiv2:max-access read-create". > > >> The output of this standard is the YANG module, not the server >> implementation of the YANG module. > > Right. The mechanism that NETCONF clients and servers use to accomplish > edits on "config false" leaf objects need not be spelled out in this > document. Adding the aforementioned paragraph and/or defining the NETCONF > capability just leaves the door open for this eventuality. > > >> Two independent implementations of the standard translator should >> produce equivalent results. > > Two independent implementations of the standard translator should > produce the equivalent YANG document from the same SMIv2 document. > > >> The deviations approach is a good start, and maybe in the future there >> can be additional mechanisms for standard translators to produce config >> true. > > Which is where my compromise proposal comes in. This document just > props the door open with regard to this point. > > -dss > > > ------------------------------------------------------------- > David Spakes email: spakes@snmp.com > SNMP Research voice: +1 865 573 1434 > 3001 Kimberlin Heights Road fax: +1 865 573 9197 > Knoxville, TN 37920-9716 USA http://www.snmp.com > ------------------------------------------------------------- > > > From dromasca@avaya.com Tue Jan 10 04:25:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386DE21F86A3 for ; Tue, 10 Jan 2012 04:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33hvwqeKnL3M for ; Tue, 10 Jan 2012 04:25:10 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0E03021F8694 for ; Tue, 10 Jan 2012 04:25:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABktDE+HCzI1/2dsb2JhbAApGqxagQWBcgEBAQEDEh4KPwwEAgEIDQMBBAEBCwYMCwEGAUUJCAEBBAESCBqHYCOaaZtJizBjBJp9jEpr X-IronPort-AV: E=Sophos;i="4.71,486,1320642000"; d="scan'208";a="323630560" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jan 2012 07:25:03 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jan 2012 07:11:53 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 13:25:00 +0100 Message-ID: In-Reply-To: <20120109214457.EA31872E004@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC6020 (3087) Thread-Index: AczPGExqzU2ljB/aRnu1kXh1Ezj6CgAeiNtA References: <20120109214457.EA31872E004@rfc-editor.org> From: "Romascanu, Dan (Dan)" To: , , , Cc: netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3087) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 12:25:11 -0000 Question - if this errata is approved, would not this cause interoperability problems between pre and post-errata implementations? Would not a pre-errata parser shout 'error' when encountering statements in 'any order'?=20 Dan > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, January 09, 2012 11:45 PM > To: mbj@tail-f.com; Romascanu, Dan (Dan); rbonica@juniper.net; > david.kessens@nsn.com; j.schoenwaelder@jacobs-university.de > Cc: mbj@tail-f.com; netmod@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC6020 (3087) >=20 >=20 > The following errata report has been submitted for RFC6020, > "YANG - A Data Modeling Language for the Network Configuration Protocol > (NETCONF)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3087 >=20 > -------------------------------------- > Type: Technical > Reported by: Martin Bjorklund >=20 > Section: 12 >=20 > Original Text > ------------- > deviate-add-stmt =3D deviate-keyword sep add-keyword optsep >=20 > (";" / >=20 > "{" stmtsep >=20 > [units-stmt stmtsep] >=20 > *(must-stmt stmtsep) >=20 > *(unique-stmt stmtsep) >=20 > [default-stmt stmtsep] >=20 > [config-stmt stmtsep] >=20 > [mandatory-stmt stmtsep] >=20 > [min-elements-stmt stmtsep] >=20 > [max-elements-stmt stmtsep] >=20 > "}") >=20 >=20 >=20 > deviate-delete-stmt =3D deviate-keyword sep delete-keyword optsep >=20 > (";" / >=20 > "{" stmtsep >=20 > [units-stmt stmtsep] >=20 > *(must-stmt stmtsep) >=20 > *(unique-stmt stmtsep) >=20 > [default-stmt stmtsep] >=20 > "}") >=20 >=20 >=20 > deviate-replace-stmt =3D deviate-keyword sep replace-keyword optsep >=20 > (";" / >=20 > "{" stmtsep >=20 > [type-stmt stmtsep] >=20 > [units-stmt stmtsep] >=20 > [default-stmt stmtsep] >=20 > [config-stmt stmtsep] >=20 > [mandatory-stmt stmtsep] >=20 > [min-elements-stmt stmtsep] >=20 > [max-elements-stmt stmtsep] >=20 > "}") >=20 >=20 >=20 >=20 >=20 > Corrected Text > -------------- > deviate-add-stmt =3D deviate-keyword sep add-keyword optsep >=20 > (";" / >=20 > "{" stmtsep >=20 > ;; these stmts can appear in any order >=20 > [units-stmt stmtsep] >=20 > *(must-stmt stmtsep) >=20 > *(unique-stmt stmtsep) >=20 > [default-stmt stmtsep] >=20 > [config-stmt stmtsep] >=20 > [mandatory-stmt stmtsep] >=20 > [min-elements-stmt stmtsep] >=20 > [max-elements-stmt stmtsep] >=20 > "}") >=20 >=20 >=20 > deviate-delete-stmt =3D deviate-keyword sep delete-keyword optsep >=20 > (";" / >=20 > "{" stmtsep >=20 > ;; these stmts can appear in any order >=20 > [units-stmt stmtsep] >=20 > *(must-stmt stmtsep) >=20 > *(unique-stmt stmtsep) >=20 > [default-stmt stmtsep] >=20 > "}") >=20 >=20 >=20 > deviate-replace-stmt =3D deviate-keyword sep replace-keyword optsep >=20 > (";" / >=20 > "{" stmtsep >=20 > ;; these stmts can appear in any order >=20 > [type-stmt stmtsep] >=20 > [units-stmt stmtsep] >=20 > [default-stmt stmtsep] >=20 > [config-stmt stmtsep] >=20 > [mandatory-stmt stmtsep] >=20 > [min-elements-stmt stmtsep] >=20 > [max-elements-stmt stmtsep] >=20 > "}") >=20 >=20 >=20 > Notes > ----- > The comment "these stmts can appear in any order" is missing from these > three statements. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6020 (draft-ietf-netmod-yang-13) > -------------------------------------- > Title : YANG - A Data Modeling Language for the Network > Configuration Protocol (NETCONF) > Publication Date : October 2010 > Author(s) : M. Bjorklund, Ed. > Category : PROPOSED STANDARD > Source : NETCONF Data Modeling Language > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From j.schoenwaelder@jacobs-university.de Tue Jan 10 06:32:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC8621F862F for ; Tue, 10 Jan 2012 06:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fafDQYw5OmD6 for ; Tue, 10 Jan 2012 06:32:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB721F8613 for ; Tue, 10 Jan 2012 06:32:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20C5A20BE6; Tue, 10 Jan 2012 15:32:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pIoiA1K12q2P; Tue, 10 Jan 2012 15:32:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C6B120BDC; Tue, 10 Jan 2012 15:32:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1FDA51C618E3; Tue, 10 Jan 2012 15:31:57 +0100 (CET) Date: Tue, 10 Jan 2012 15:31:57 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120110143156.GB95306@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , netmod@ietf.org References: <201201061504.KAA19060@adminfs.snmp.com> <4F072ACF.7040703@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F072ACF.7040703@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:32:18 -0000 On Fri, Jan 06, 2012 at 09:09:35AM -0800, Andy Bierman wrote: > I was confused too -- the prefixes are still lower-case, even though > the module name is now upper-case. I suppose forcing lower-case > prefixes is some sort of feature in somebody's mind. The prefixes are not forced to be lower-case anymore in the current I-D. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jan 10 06:36:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3789121F86D3 for ; Tue, 10 Jan 2012 06:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lb5VLlnskVY for ; Tue, 10 Jan 2012 06:36:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7566221F84A3 for ; Tue, 10 Jan 2012 06:36:02 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7CAA20BE9; Tue, 10 Jan 2012 15:36:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id s1DC3-glS6IB; Tue, 10 Jan 2012 15:36:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 409EC20BE6; Tue, 10 Jan 2012 15:36:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A3C671C6194B; Tue, 10 Jan 2012 15:35:44 +0100 (CET) Date: Tue, 10 Jan 2012 15:35:44 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20120110143544.GC95306@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20120106073203.GB85155@elstar.local> <201201061451.JAA18614@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201061451.JAA18614@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:36:03 -0000 On Fri, Jan 06, 2012 at 09:51:40AM -0500, David Reid wrote: > > Augments has been one of the biggest pains to implement simply > because of the difference in containment. (There is also a small > performance hit, but I think it's negligible). I guess that's my > problem with unflattened scalars. I implemented scalars based on > the 01 draft and it was very easy. Now I'm looking to update to the > 03 draft and it's going to be more challenging. Maybe > implementation cost shouldn't be a big concern. It's not > unimplementable, just harder. > > I think we put scalars into containers so that scalars in yang > modules would have the same logical grouping that the MIB module > has, which is a reasonable goal. And somehow I felt the WG was willing to pay the implementation costs for this instead of facing some long lists of collections of scalars. > But it conflicts with the desire to have the yang containment match > the OID tree. This is where I stop following you. The scalars are not put in arbitrary containers - the containers are derived from the registration tree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jan 10 07:13:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F36621F8613 for ; Tue, 10 Jan 2012 07:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DUHhc-xgz3U for ; Tue, 10 Jan 2012 07:13:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 569A421F85FD for ; Tue, 10 Jan 2012 07:13:11 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9D5320BF4; Tue, 10 Jan 2012 16:13:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3tPGQPEDB4uv; Tue, 10 Jan 2012 16:13:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2E9B20BDF; Tue, 10 Jan 2012 16:13:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 364721C70D51; Tue, 10 Jan 2012 16:12:50 +0100 (CET) Date: Tue, 10 Jan 2012 16:12:48 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20120110151248.GA96013@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , netmod@ietf.org References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:13:12 -0000 On Mon, Jan 09, 2012 at 05:36:53PM -0500, David Spakes wrote: > On Mon, 9 Jan 2012, Andy Bierman wrote: > > > On 01/09/2012 01:41 PM, Martin Bjorklund wrote: > > > Hi, > > > > > > David Reid wrote: > > >> Could we put something in the document to indicate that proprietary mechanisms > > >> to allow config true for some objects is OK so that things like what Martin > > >> is doing or what David Spakes is thinking about are not considered > > >> non-compliant? > > > > > > My deviation-based solution does not require any changes to the > > > current document. In fact, if we put in words that allowed a server > > > to implemnet some nodes as config, I wouldn't have to use my > > > deviations at all! > > > One of my concerns about the deviation-based solution is that software > that implements it is not considered to be compliant to the spec. > > RFC 6020, Section 7.18.3, Page 103: > > Device deviations are strongly discouraged and MUST only be used as a > last resort. Telling the application how a device fails to follow a > standard is no substitute for implementing the standard correctly. A > device that deviates from a module is not fully compliant with the > module. > > I believe this text was written for the case that an implementation can't > meet the minimum requirements of the YANG contract. However, Martin's > implementation goes beyond the contract to provide additional abilities > that are not specified in the contract. It seems unfair to Martin that > his approach might be considered by some to be non-compliant according > to RFC 6020. > > Now, if the ietf-yang-smiv2 included a paragraph that states explicitly > that going beyond the contract in this case is not considered to be > non-compliant, then all is well. Is everyone comfortable adding such > a paragraph? I would be comfortable with that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Tue Jan 10 08:13:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7257D21F84E7 for ; Tue, 10 Jan 2012 08:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ion7L4apwOIc for ; Tue, 10 Jan 2012 08:13:05 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0CA21F84F0 for ; Tue, 10 Jan 2012 08:13:03 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0AGD3hK011936 for ; Tue, 10 Jan 2012 11:13:03 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44118] helo=[192.168.0.126]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 47/06-24407-F836C0F4; Tue, 10 Jan 2012 11:13:03 -0500 Message-ID: <4F0C638B.8070809@netconfcentral.org> Date: Tue, 10 Jan 2012 08:12:59 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes , netmod@ietf.org References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> <20120110151248.GA96013@elstar.local> In-Reply-To: <20120110151248.GA96013@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:13:06 -0000 On 01/10/2012 07:12 AM, Juergen Schoenwaelder wrote: > On Mon, Jan 09, 2012 at 05:36:53PM -0500, David Spakes wrote: >> On Mon, 9 Jan 2012, Andy Bierman wrote: >> >>> On 01/09/2012 01:41 PM, Martin Bjorklund wrote: >>>> Hi, >>>> >>>> David Reid wrote: >>>>> Could we put something in the document to indicate that proprietary mechanisms >>>>> to allow config true for some objects is OK so that things like what Martin >>>>> is doing or what David Spakes is thinking about are not considered >>>>> non-compliant? >>>> >>>> My deviation-based solution does not require any changes to the >>>> current document. In fact, if we put in words that allowed a server >>>> to implemnet some nodes as config, I wouldn't have to use my >>>> deviations at all! >> >> >> One of my concerns about the deviation-based solution is that software >> that implements it is not considered to be compliant to the spec. >> >> RFC 6020, Section 7.18.3, Page 103: >> >> Device deviations are strongly discouraged and MUST only be used as a >> last resort. Telling the application how a device fails to follow a >> standard is no substitute for implementing the standard correctly. A >> device that deviates from a module is not fully compliant with the >> module. >> >> I believe this text was written for the case that an implementation can't >> meet the minimum requirements of the YANG contract. However, Martin's >> implementation goes beyond the contract to provide additional abilities >> that are not specified in the contract. It seems unfair to Martin that >> his approach might be considered by some to be non-compliant according >> to RFC 6020. >> >> Now, if the ietf-yang-smiv2 included a paragraph that states explicitly >> that going beyond the contract in this case is not considered to be >> non-compliant, then all is well. Is everyone comfortable adding such >> a paragraph? > > I would be comfortable with that. I strongly oppose this approach. The config-stmt is a rather important detail in the YANG translation. Implementations of the standard translation algorithm need to generate the same YANG module for a given input SMIv2 module. The standard has no value to users if there is no chance of a replacing one implementation of the standard with a different one. If the WG thinks read-write and read-create access needs to be covered in the standard, then come up with a standard solution. IMO, read-only + deviations is a good first step. IMO, tool vendors do not need this 'free pass' text added. An implementation must be capable of producing the all-read-only translation. That doesn't mean it cannot also be capable of generating a custom non-standard translation using proprietary mechanisms. There is no value whatsoever in the 'conceptual' translated version of the FOO-MIB if there is no agreement on the config-stmt values within FOO-MIB.yang. There needs to be a canonical, correct translation for every possible SMIv2 module. > > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Jan 10 08:18:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42F21F8705 for ; Tue, 10 Jan 2012 08:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iq5+W8xAxyI for ; Tue, 10 Jan 2012 08:18:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A35E21F86FF for ; Tue, 10 Jan 2012 08:18:24 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE66920C02; Tue, 10 Jan 2012 17:18:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EiaLdgt7-sVc; Tue, 10 Jan 2012 17:18:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CF7E20BF9; Tue, 10 Jan 2012 17:18:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F63D1C77305; Tue, 10 Jan 2012 17:18:05 +0100 (CET) Date: Tue, 10 Jan 2012 17:18:04 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120110161804.GA11659@elstar.local> Mail-Followup-To: Andy Bierman , David Spakes , netmod@ietf.org References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> <20120110151248.GA96013@elstar.local> <4F0C638B.8070809@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F0C638B.8070809@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:18:25 -0000 On Tue, Jan 10, 2012 at 08:12:59AM -0800, Andy Bierman wrote: > On 01/10/2012 07:12 AM, Juergen Schoenwaelder wrote: > >On Mon, Jan 09, 2012 at 05:36:53PM -0500, David Spakes wrote: > >>On Mon, 9 Jan 2012, Andy Bierman wrote: > >> > >>>On 01/09/2012 01:41 PM, Martin Bjorklund wrote: > >>>>Hi, > >>>> > >>>>David Reid wrote: > >>>>>Could we put something in the document to indicate that proprietary mechanisms > >>>>>to allow config true for some objects is OK so that things like what Martin > >>>>>is doing or what David Spakes is thinking about are not considered > >>>>>non-compliant? > >>>> > >>>>My deviation-based solution does not require any changes to the > >>>>current document. In fact, if we put in words that allowed a server > >>>>to implemnet some nodes as config, I wouldn't have to use my > >>>>deviations at all! > >> > >> > >>One of my concerns about the deviation-based solution is that software > >>that implements it is not considered to be compliant to the spec. > >> > >>RFC 6020, Section 7.18.3, Page 103: > >> > >> Device deviations are strongly discouraged and MUST only be used as a > >> last resort. Telling the application how a device fails to follow a > >> standard is no substitute for implementing the standard correctly. A > >> device that deviates from a module is not fully compliant with the > >> module. > >> > >>I believe this text was written for the case that an implementation can't > >>meet the minimum requirements of the YANG contract. However, Martin's > >>implementation goes beyond the contract to provide additional abilities > >>that are not specified in the contract. It seems unfair to Martin that > >>his approach might be considered by some to be non-compliant according > >>to RFC 6020. > >> > >>Now, if the ietf-yang-smiv2 included a paragraph that states explicitly > >>that going beyond the contract in this case is not considered to be > >>non-compliant, then all is well. Is everyone comfortable adding such > >>a paragraph? > > > >I would be comfortable with that. > > I strongly oppose this approach. > The config-stmt is a rather important detail in the YANG translation. > Implementations of the standard translation algorithm need to generate > the same YANG module for a given input SMIv2 module. It does. > The standard has no value to users if there is no chance of a replacing one implementation > of the standard with a different one. This works. > If the WG thinks read-write and read-create access needs to be covered in the > standard, then come up with a standard solution. IMO, read-only + deviations > is a good first step. This is what this was about. > IMO, tool vendors do not need this 'free pass' text added. > An implementation must be capable of producing the all-read-only translation. > That doesn't mean it cannot also be capable of generating a custom non-standard translation > using proprietary mechanisms. Either I am confused or you are. > There is no value whatsoever in the 'conceptual' translated version of the FOO-MIB if there is no > agreement on the config-stmt values within FOO-MIB.yang. There needs to be a canonical, correct > translation for every possible SMIv2 module. There is. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Tue Jan 10 08:25:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8121F875E for ; Tue, 10 Jan 2012 08:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zkTuuawUB-C for ; Tue, 10 Jan 2012 08:25:55 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0B59D21F8750 for ; Tue, 10 Jan 2012 08:25:54 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0AGPrrd027347 for ; Tue, 10 Jan 2012 11:25:53 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:47101] helo=[192.168.0.126]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BE/E0-23837-1966C0F4; Tue, 10 Jan 2012 11:25:53 -0500 Message-ID: <4F0C668D.109@netconfcentral.org> Date: Tue, 10 Jan 2012 08:25:49 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120109214457.EA31872E004@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbonica@juniper.net, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3087) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:25:55 -0000 On 01/10/2012 04:25 AM, Romascanu, Dan (Dan) wrote: > Question - if this errata is approved, would not this cause > interoperability problems between pre and post-errata implementations? > Would not a pre-errata parser shout 'error' when encountering statements > in 'any order'? I know yangdump allows any statement order and I think pyang does as well. I think this change is safe, especially since deviations are not really being used. > > Dan > Andy From spakes@snmp.com Tue Jan 10 08:26:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7021F8762 for ; Tue, 10 Jan 2012 08:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk4DM6UWWKX1 for ; Tue, 10 Jan 2012 08:26:11 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA36321F8750 for ; Tue, 10 Jan 2012 08:26:10 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA10794; Tue, 10 Jan 2012 11:26:09 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA17456; Tue, 10 Jan 2012 11:26:09 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 10 Jan 2012 11:26:09 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4F0C638B.8070809@netconfcentral.org> Message-ID: References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> <20120110151248.GA96013@elstar.local> <4F0C638B.8070809@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:26:11 -0000 On Tue, 10 Jan 2012, Andy Bierman wrote: > On 01/10/2012 07:12 AM, Juergen Schoenwaelder wrote: > > On Mon, Jan 09, 2012 at 05:36:53PM -0500, David Spakes wrote: > >> On Mon, 9 Jan 2012, Andy Bierman wrote: > >> > >>> On 01/09/2012 01:41 PM, Martin Bjorklund wrote: > >>>> Hi, > >>>> > >>>> David Reid wrote: > >>>>> Could we put something in the document to indicate that proprietary mechanisms > >>>>> to allow config true for some objects is OK so that things like what Martin > >>>>> is doing or what David Spakes is thinking about are not considered > >>>>> non-compliant? > >>>> > >>>> My deviation-based solution does not require any changes to the > >>>> current document. In fact, if we put in words that allowed a server > >>>> to implemnet some nodes as config, I wouldn't have to use my > >>>> deviations at all! > >> > >> > >> One of my concerns about the deviation-based solution is that software > >> that implements it is not considered to be compliant to the spec. > >> > >> RFC 6020, Section 7.18.3, Page 103: > >> > >> Device deviations are strongly discouraged and MUST only be used as a > >> last resort. Telling the application how a device fails to follow a > >> standard is no substitute for implementing the standard correctly. A > >> device that deviates from a module is not fully compliant with the > >> module. > >> > >> I believe this text was written for the case that an implementation can't > >> meet the minimum requirements of the YANG contract. However, Martin's > >> implementation goes beyond the contract to provide additional abilities > >> that are not specified in the contract. It seems unfair to Martin that > >> his approach might be considered by some to be non-compliant according > >> to RFC 6020. > >> > >> Now, if the ietf-yang-smiv2 included a paragraph that states explicitly > >> that going beyond the contract in this case is not considered to be > >> non-compliant, then all is well. Is everyone comfortable adding such > >> a paragraph? > > > > I would be comfortable with that. > > I strongly oppose this approach. > The config-stmt is a rather important detail in the YANG translation. > Implementations of the standard translation algorithm need to generate > the same YANG module for a given input SMIv2 module. Andy, no one is suggesting that the YANG module needs to be generated any differently. The topic being discussed is simply about adding a paragraph to the ietf-yang-smiv2 document that states Martin's use of deviation is considered to be compliant. > The standard has no value to users if there is no chance of a replacing > one implementation of the standard with a different one. > > If the WG thinks read-write and read-create access needs to be covered > in the standard, then come up with a standard solution. IMO, read-only > + deviations is a good first step. You just said that the deviation approach is good in this case. So let's put that language in a paragraph and add it to the document and I think we're done here. -dss > IMO, tool vendors do not need this 'free pass' text added. An > implementation must be capable of producing the all-read-only > translation. That doesn't mean it cannot also be capable of generating a > custom non-standard translation using proprietary mechanisms. > > There is no value whatsoever in the 'conceptual' translated version of > the FOO-MIB if there is no agreement on the config-stmt values within > FOO-MIB.yang. There needs to be a canonical, correct translation for > every possible SMIv2 module. > > > > > /js > > > > Andy > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@netconfcentral.org Tue Jan 10 08:35:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5E221F8692 for ; Tue, 10 Jan 2012 08:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IrJrBi8KYe4 for ; Tue, 10 Jan 2012 08:35:11 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5F321F868A for ; Tue, 10 Jan 2012 08:35:11 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0AGZ8e7007299 for ; Tue, 10 Jan 2012 11:35:08 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:49216] helo=[192.168.0.126]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 44/78-17660-CB86C0F4; Tue, 10 Jan 2012 11:35:08 -0500 Message-ID: <4F0C68BB.6070209@netconfcentral.org> Date: Tue, 10 Jan 2012 08:35:07 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes , netmod@ietf.org References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> <20120110151248.GA96013@elstar.local> <4F0C638B.8070809@netconfcentral.org> <20120110161804.GA11659@elstar.local> In-Reply-To: <20120110161804.GA11659@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:35:12 -0000 On 01/10/2012 08:18 AM, Juergen Schoenwaelder wrote: ... > Either I am confused or you are. It must be me. So you want a paragraph that says that the SMIv2 translation to YANG MAY include deviation statements for config statements, and that a compliant translator is allowed to generate these deviation statements? OK -- that is fine with me. > >> There is no value whatsoever in the 'conceptual' translated version of the FOO-MIB if there is no >> agreement on the config-stmt values within FOO-MIB.yang. There needs to be a canonical, correct >> translation for every possible SMIv2 module. > > There is. > > /js > Andy From andy@netconfcentral.org Tue Jan 10 08:40:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E1921F86C8 for ; Tue, 10 Jan 2012 08:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfCrjc32BX8E for ; Tue, 10 Jan 2012 08:40:22 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id DB28821F8644 for ; Tue, 10 Jan 2012 08:40:21 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0AGeLuw027377 for ; Tue, 10 Jan 2012 11:40:21 -0500 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:50392] helo=[192.168.0.126]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 30/D7-17039-4F96C0F4; Tue, 10 Jan 2012 11:40:21 -0500 Message-ID: <4F0C69F4.2000408@netconfcentral.org> Date: Tue, 10 Jan 2012 08:40:20 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> <20120110151248.GA96013@elstar.local> <4F0C638B.8070809@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:40:22 -0000 On 01/10/2012 08:26 AM, David Spakes wrote: > On Tue, 10 Jan 2012, Andy Bierman wrote: > sorry -- I misunderstood your comment about going beyond the contract to mean the contract to generate all-read-only. In general, standard-output + deviations is the correct YANG solution, and implementors may find more than 'config true/false' that needs to change sometimes. Andy >> On 01/10/2012 07:12 AM, Juergen Schoenwaelder wrote: >>> On Mon, Jan 09, 2012 at 05:36:53PM -0500, David Spakes wrote: >>>> On Mon, 9 Jan 2012, Andy Bierman wrote: >>>> >>>>> On 01/09/2012 01:41 PM, Martin Bjorklund wrote: >>>>>> Hi, >>>>>> >>>>>> David Reid wrote: >>>>>>> Could we put something in the document to indicate that proprietary mechanisms >>>>>>> to allow config true for some objects is OK so that things like what Martin >>>>>>> is doing or what David Spakes is thinking about are not considered >>>>>>> non-compliant? >>>>>> >>>>>> My deviation-based solution does not require any changes to the >>>>>> current document. In fact, if we put in words that allowed a server >>>>>> to implemnet some nodes as config, I wouldn't have to use my >>>>>> deviations at all! >>>> >>>> >>>> One of my concerns about the deviation-based solution is that software >>>> that implements it is not considered to be compliant to the spec. >>>> >>>> RFC 6020, Section 7.18.3, Page 103: >>>> >>>> Device deviations are strongly discouraged and MUST only be used as a >>>> last resort. Telling the application how a device fails to follow a >>>> standard is no substitute for implementing the standard correctly. A >>>> device that deviates from a module is not fully compliant with the >>>> module. >>>> >>>> I believe this text was written for the case that an implementation can't >>>> meet the minimum requirements of the YANG contract. However, Martin's >>>> implementation goes beyond the contract to provide additional abilities >>>> that are not specified in the contract. It seems unfair to Martin that >>>> his approach might be considered by some to be non-compliant according >>>> to RFC 6020. >>>> >>>> Now, if the ietf-yang-smiv2 included a paragraph that states explicitly >>>> that going beyond the contract in this case is not considered to be >>>> non-compliant, then all is well. Is everyone comfortable adding such >>>> a paragraph? >>> >>> I would be comfortable with that. >> >> I strongly oppose this approach. >> The config-stmt is a rather important detail in the YANG translation. >> Implementations of the standard translation algorithm need to generate >> the same YANG module for a given input SMIv2 module. > > Andy, no one is suggesting that the YANG module needs to be generated > any differently. > > The topic being discussed is simply about adding a paragraph to the > ietf-yang-smiv2 document that states Martin's use of deviation is > considered to be compliant. > > >> The standard has no value to users if there is no chance of a replacing >> one implementation of the standard with a different one. >> >> If the WG thinks read-write and read-create access needs to be covered >> in the standard, then come up with a standard solution. IMO, read-only >> + deviations is a good first step. > > You just said that the deviation approach is good in this case. So > let's put that language in a paragraph and add it to the document and > I think we're done here. > > -dss > > > >> IMO, tool vendors do not need this 'free pass' text added. An >> implementation must be capable of producing the all-read-only >> translation. That doesn't mean it cannot also be capable of generating a >> custom non-standard translation using proprietary mechanisms. >> >> There is no value whatsoever in the 'conceptual' translated version of >> the FOO-MIB if there is no agreement on the config-stmt values within >> FOO-MIB.yang. There needs to be a canonical, correct translation for >> every possible SMIv2 module. >> >>> >>> /js >>> >> >> Andy >> > > > ------------------------------------------------------------- > David Spakes email: spakes@snmp.com > SNMP Research voice: +1 865 573 1434 > 3001 Kimberlin Heights Road fax: +1 865 573 9197 > Knoxville, TN 37920-9716 USA http://www.snmp.com > ------------------------------------------------------------- > > > From spakes@snmp.com Tue Jan 10 09:56:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6421F86AD for ; Tue, 10 Jan 2012 09:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+Pba2mfwnMl for ; Tue, 10 Jan 2012 09:56:50 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id DEBCE21F8694 for ; Tue, 10 Jan 2012 09:56:49 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA19249; Tue, 10 Jan 2012 12:56:47 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA18477; Tue, 10 Jan 2012 12:56:47 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 10 Jan 2012 12:56:47 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: netmod@ietf.org In-Reply-To: <4F0C69F4.2000408@netconfcentral.org> Message-ID: References: <201201091514.KAA03134@adminfs.snmp.com> <20120109.224156.341976508.mbj@tail-f.com> <4F0B6471.3070101@netconfcentral.org> <20120110151248.GA96013@elstar.local> <4F0C638B.8070809@netconfcentral.org> <4F0C69F4.2000408@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 17:56:51 -0000 On Tue, 10 Jan 2012, Andy Bierman wrote: > sorry -- I misunderstood your comment about going beyond the contract to > mean the contract to generate all-read-only. In general, > standard-output + deviations is the correct YANG solution, and > implementors may find more than 'config true/false' that needs to change > sometimes. > > So you want a paragraph that says that the SMIv2 translation to YANG MAY > include deviation statements for config statements, and that a compliant > translator is allowed to generate these deviation statements? > > OK -- that is fine with me. With the addition of the paragraph, then I am in agreement as well. I withdraw my previous suggestion about adding a NETCONF capability. Re-reading everyone's previous comments, I think we are in rough concensus. Are there any details that need to be discussed from Martin's message on Friday (below)? There is an issue that I would like clarity on. According to the current draft, in Section 4.1 (Page 8), "A top-level YANG container is generated...and the container MUST be config false." And in RFC 6020, Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no node underneath it can have 'config' set to 'true'. Martin, does your deviation module change the top-level YANG container from 'config false' to 'config true'? -dss On Fri, 6 Jan 2012, Martin Bjorklund wrote: > The way we do this now (not yet released) is that we generate the > config false module, and an additional module (with another namespace) > with deviation statements, changing config from false to true on the > proper nodes. Then the deviation module is advertised as specified in > 6020. > > A client that uses the same translated module + the same deviation > module, will be able to use the config true nodes. > > A client that uses the same translated module, maybe from another > compliant implementation, but without the deviations, will be able to > the nodes that he thinks is config false. The only potential > problem is what the client does when it sees the deviation module it > doesn't know about... my guess it will just work since most clients > won't care about the deviations ;) ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From mbj@tail-f.com Tue Jan 10 11:54:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF421F86D7 for ; Tue, 10 Jan 2012 11:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5fwwgAuYypD for ; Tue, 10 Jan 2012 11:54:19 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8B21F86A2 for ; Tue, 10 Jan 2012 11:54:18 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 13EF11200AC0; Tue, 10 Jan 2012 20:54:14 +0100 (CET) Date: Tue, 10 Jan 2012 20:54:13 +0100 (CET) Message-Id: <20120110.205413.459299923.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F0C668D.109@netconfcentral.org> References: <20120109214457.EA31872E004@rfc-editor.org> <4F0C668D.109@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, rbonica@juniper.net Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3087) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:54:19 -0000 Andy Bierman wrote: > On 01/10/2012 04:25 AM, Romascanu, Dan (Dan) wrote: > > Question - if this errata is approved, would not this cause > > interoperability problems between pre and post-errata implementations? > > Would not a pre-errata parser shout 'error' when encountering statements > > in 'any order'? > > I know yangdump allows any statement order and I think pyang does as well. It does, and I also checked two other open source tools, libsmi and jYang. So all four of these implementations already allow this. > I think this change is safe, especially since deviations are not really being > used. Right. And, more importantly, any module already written according to these strict rules is still valid. /martin From mbj@tail-f.com Tue Jan 10 11:57:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCE221F881D for ; Tue, 10 Jan 2012 11:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV2qg8C-K-fH for ; Tue, 10 Jan 2012 11:57:06 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E022B11E8071 for ; Tue, 10 Jan 2012 11:57:05 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 12BA61200AC0; Tue, 10 Jan 2012 20:57:05 +0100 (CET) Date: Tue, 10 Jan 2012 20:57:03 +0100 (CET) Message-Id: <20120110.205703.512548944.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F0C68BB.6070209@netconfcentral.org> References: <4F0C638B.8070809@netconfcentral.org> <20120110161804.GA11659@elstar.local> <4F0C68BB.6070209@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:57:06 -0000 Andy Bierman wrote: > On 01/10/2012 08:18 AM, Juergen Schoenwaelder wrote: > ... > > > Either I am confused or you are. > > It must be me. > > So you want a paragraph that says that the SMIv2 translation to YANG MAY > include deviation statements > for config statements, and that a compliant translator is allowed to generate > these deviation statements? Just a note here - the correct way to do this is to generate the deviation statements in another module, so that the server can advertise the proper translated module with the deviation. It must not be legal to generate the deviation statements in the translated module itself. /martin From mbj@tail-f.com Tue Jan 10 12:04:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319E021F85EF for ; Tue, 10 Jan 2012 12:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQQKqHR1VvqI for ; Tue, 10 Jan 2012 12:04:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEA521F85D5 for ; Tue, 10 Jan 2012 12:04:34 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D8E5D1200AC0; Tue, 10 Jan 2012 21:04:33 +0100 (CET) Date: Tue, 10 Jan 2012 21:04:32 +0100 (CET) Message-Id: <20120110.210432.290435654.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <4F0C69F4.2000408@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 20:04:35 -0000 Hi, David Spakes wrote: > On Tue, 10 Jan 2012, Andy Bierman wrote: > > > sorry -- I misunderstood your comment about going beyond the contract to > > mean the contract to generate all-read-only. In general, > > standard-output + deviations is the correct YANG solution, and > > implementors may find more than 'config true/false' that needs to change > > sometimes. > > > > So you want a paragraph that says that the SMIv2 translation to YANG MAY > > include deviation statements for config statements, and that a compliant > > translator is allowed to generate these deviation statements? > > > > OK -- that is fine with me. > > > With the addition of the paragraph, then I am in agreement as well. > I withdraw my previous suggestion about adding a NETCONF capability. > > Re-reading everyone's previous comments, I think we are in rough > concensus. > > Are there any details that need to be discussed from Martin's message > on Friday (below)? > > There is an issue that I would like clarity on. According to the > current draft, in Section 4.1 (Page 8), "A top-level YANG container is > generated...and the container MUST be config false." And in RFC 6020, > Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no > node underneath it can have 'config' set to 'true'. Martin, does your > deviation module change the top-level YANG container from 'config false' > to 'config true'? Yes. It generates 'config true' up in the hierarchy as needed. (I found a bug or two in the handling of deviations in pyang in the process, but I guess that's expected ;) /martin From reid@snmp.com Tue Jan 10 14:23:51 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9813921F8755 for ; Tue, 10 Jan 2012 14:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CINjND7rgySW for ; Tue, 10 Jan 2012 14:23:51 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5414921F86A3 for ; Tue, 10 Jan 2012 14:23:47 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA08483; Tue, 10 Jan 2012 17:23:34 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA21669; Tue, 10 Jan 2012 17:23:24 -0500 (EST) Message-Id: <201201102223.RAA21669@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Tue, 10 Jan 2012 15:35:44 +0100. <20120110143544.GC95306@elstar.local> Date: Tue, 10 Jan 2012 17:23:24 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 22:23:51 -0000 > On Fri, Jan 06, 2012 at 09:51:40AM -0500, David Reid wrote: > > > > Augments has been one of the biggest pains to implement simply > > because of the difference in containment. (There is also a small > > performance hit, but I think it's negligible). I guess that's my > > problem with unflattened scalars. I implemented scalars based on > > the 01 draft and it was very easy. Now I'm looking to update to the > > 03 draft and it's going to be more challenging. Maybe > > implementation cost shouldn't be a big concern. It's not > > unimplementable, just harder. > > > > I think we put scalars into containers so that scalars in yang > > modules would have the same logical grouping that the MIB module > > has, which is a reasonable goal. > > And somehow I felt the WG was willing to pay the implementation costs > for this instead of facing some long lists of collections of scalars. > > > But it conflicts with the desire to have the yang containment match > > the OID tree. > > This is where I stop following you. The scalars are not put in > arbitrary containers - the containers are derived from the > registration tree. An SNMP subtree walk on interfaces would return the scalars and ifTable. A netconf get on interfaces would only return the scalars. -David Reid From j.schoenwaelder@jacobs-university.de Tue Jan 10 23:48:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B8521F8853 for ; Tue, 10 Jan 2012 23:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDV9oqWPGMCS for ; Tue, 10 Jan 2012 23:48:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 63D5521F8852 for ; Tue, 10 Jan 2012 23:48:01 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9022D20BCD; Wed, 11 Jan 2012 08:48:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YQgNlxH07Gni; Wed, 11 Jan 2012 08:48:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34D5820A1F; Wed, 11 Jan 2012 08:47:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 939171C77BA6; Wed, 11 Jan 2012 08:47:42 +0100 (CET) Date: Wed, 11 Jan 2012 08:47:42 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20120111074742.GA12804@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20120110143544.GC95306@elstar.local> <201201102223.RAA21669@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201102223.RAA21669@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 07:48:02 -0000 On Tue, Jan 10, 2012 at 05:23:24PM -0500, David Reid wrote: > > > But it conflicts with the desire to have the yang containment match > > > the OID tree. > > > > This is where I stop following you. The scalars are not put in > > arbitrary containers - the containers are derived from the > > registration tree. > > An SNMP subtree walk on interfaces would return the scalars and ifTable. A > netconf get on interfaces would only return the scalars. OK, now I see what you mean. The question is whether this matters. SNMP walks are in general not the same as NETCONF gets. And as mentioned earlier, ifTable and ifXTable are quite far away in the SNMP OID tree while the YANG augment puts things together. With the YANG models derived from SNMP MIB modules, you actually get all interface augments when you retrieve ifTable unless you put specific filters in place. /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 Wed Jan 11 01:05:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B404921F8852 for ; Wed, 11 Jan 2012 01:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2ZfThfv8fgg for ; Wed, 11 Jan 2012 01:05:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8693C21F8543 for ; Wed, 11 Jan 2012 01:05:18 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6AE820BD8; Wed, 11 Jan 2012 10:05:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rEZyM1X7SHQn; Wed, 11 Jan 2012 10:05:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84F5F20BDE; Wed, 11 Jan 2012 10:05:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 38FC11C77E44; Wed, 11 Jan 2012 10:04:58 +0100 (CET) Date: Wed, 11 Jan 2012 10:04:58 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120111090458.GA13074@elstar.local> Mail-Followup-To: Martin Bjorklund , spakes@snmp.com, netmod@ietf.org References: <4F0C69F4.2000408@netconfcentral.org> <20120110.210432.290435654.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120110.210432.290435654.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 09:05:19 -0000 On Tue, Jan 10, 2012 at 09:04:32PM +0100, Martin Bjorklund wrote: > > There is an issue that I would like clarity on. According to the > > current draft, in Section 4.1 (Page 8), "A top-level YANG container is > > generated...and the container MUST be config false." And in RFC 6020, > > Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no > > node underneath it can have 'config' set to 'true'. Martin, does your > > deviation module change the top-level YANG container from 'config false' > > to 'config true'? > > Yes. It generates 'config true' up in the hierarchy as needed. > > (I found a bug or two in the handling of deviations in pyang in the > process, but I guess that's expected ;) Martin, if you deviate the top-level node to config true, you will in turn have to add config false to all leafs that remain config false, no? If this is the case, would we then perhaps make life simpler by having explicit config false statements generated for the leafs, either in addition to the top-level config false or as a replacement of the top-level config false? /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 Wed Jan 11 01:46:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52321F884C for ; Wed, 11 Jan 2012 01:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q9zsyjtRF3C for ; Wed, 11 Jan 2012 01:46:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03821F8845 for ; Wed, 11 Jan 2012 01:46:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8027920AFE; Wed, 11 Jan 2012 10:46:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zArbuyhX9WOY; Wed, 11 Jan 2012 10:46:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A6EE205A3; Wed, 11 Jan 2012 10:46:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 902ED1C78021; Wed, 11 Jan 2012 10:46:15 +0100 (CET) Date: Wed, 11 Jan 2012 10:46:15 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120111094615.GB13402@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 09:46:33 -0000 * smi2yang-23: config true deviations [open] One approach to support edit-config writable MIB objects is to use YANG deviations, i.e., an implementation announces an additional YANG module that provides config true information via YANG deviations. RFC 6020, Section 7.18.3, Page 103 says: Device deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. A device that deviates from a module is not fully compliant with the module. This text apparently was written for the case that an implementation can't meet the minimum requirements of the YANG contract, which is not the case here. ** Solution #23-01 Add text to clarify that config true deviations that add functionality do not impact the compliance of an implementation: Implementations may choose to implement some data nodes as configuration data nodes. Such a deviation from the generated YANG module should be formally documented in a separate YANG module that details the changes using YANG deviation statements changing the config tag of the data nodes implemented as configuration data nodes from false to true. Deviations that change the config false tag to true without any other changes to the semantics of the data node do not affect the compliance with the YANG module generated from an SMIv2 module. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jan 11 02:18:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67621F8537 for ; Wed, 11 Jan 2012 02:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5COfTFu9Gze for ; Wed, 11 Jan 2012 02:18:18 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C009721F883C for ; Wed, 11 Jan 2012 02:18:17 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 462891200050; Wed, 11 Jan 2012 11:18:15 +0100 (CET) Date: Wed, 11 Jan 2012 11:18:14 +0100 (CET) Message-Id: <20120111.111814.421335561013996052.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120111090458.GA13074@elstar.local> References: <20120110.210432.290435654.mbj@tail-f.com> <20120111090458.GA13074@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:18:18 -0000 Juergen Schoenwaelder wrote: > On Tue, Jan 10, 2012 at 09:04:32PM +0100, Martin Bjorklund wrote: > > > > There is an issue that I would like clarity on. According to the > > > current draft, in Section 4.1 (Page 8), "A top-level YANG container is > > > generated...and the container MUST be config false." And in RFC 6020, > > > Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no > > > node underneath it can have 'config' set to 'true'. Martin, does your > > > deviation module change the top-level YANG container from 'config false' > > > to 'config true'? > > > > Yes. It generates 'config true' up in the hierarchy as needed. > > > > (I found a bug or two in the handling of deviations in pyang in the > > process, but I guess that's expected ;) > > Martin, > > if you deviate the top-level node to config true, you will in turn > have to add config false to all leafs that remain config false, no? I don't think I have to do that, but unfortunately the rfc is a bit unclear in this case. The config statement sets the "config" property on the node, and this property is inherited by child nodes. The deviate statement modifies the config property on the specified node only. By example: container a { config false; container b; container c; } gives the tree: a { config=false } | +- b { config=false } | +- c { config=false } and applying a deviation: deviation /a { deviate replace { config true; } deviation /a/b { deviate replace { config true; } gives the tree: a { config=true } | +- b { config=true } | +- c { config=false } /martin From j.schoenwaelder@jacobs-university.de Wed Jan 11 02:35:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339D721F8687 for ; Wed, 11 Jan 2012 02:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3fpDGabEqc1 for ; Wed, 11 Jan 2012 02:35:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 340F921F8663 for ; Wed, 11 Jan 2012 02:35:19 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8799720BCD; Wed, 11 Jan 2012 11:35:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vXorEQp9TwNv; Wed, 11 Jan 2012 11:35:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F312420590; Wed, 11 Jan 2012 11:35:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9EFEF1C7854F; Wed, 11 Jan 2012 11:35:00 +0100 (CET) Date: Wed, 11 Jan 2012 11:35:00 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120111103458.GB13647@elstar.local> Mail-Followup-To: Martin Bjorklund , spakes@snmp.com, netmod@ietf.org References: <20120110.210432.290435654.mbj@tail-f.com> <20120111090458.GA13074@elstar.local> <20120111.111814.421335561013996052.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120111.111814.421335561013996052.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:35:20 -0000 On Wed, Jan 11, 2012 at 11:18:14AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 10, 2012 at 09:04:32PM +0100, Martin Bjorklund wrote: > > > > > > There is an issue that I would like clarity on. According to the > > > > current draft, in Section 4.1 (Page 8), "A top-level YANG container is > > > > generated...and the container MUST be config false." And in RFC 6020, > > > > Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no > > > > node underneath it can have 'config' set to 'true'. Martin, does your > > > > deviation module change the top-level YANG container from 'config false' > > > > to 'config true'? > > > > > > Yes. It generates 'config true' up in the hierarchy as needed. > > > > > > (I found a bug or two in the handling of deviations in pyang in the > > > process, but I guess that's expected ;) > > > > Martin, > > > > if you deviate the top-level node to config true, you will in turn > > have to add config false to all leafs that remain config false, no? > > I don't think I have to do that, but unfortunately the rfc is a bit > unclear in this case. > > The config statement sets the "config" property on the node, and this > property is inherited by child nodes. The deviate statement modifies > the config property on the specified node only. > > By example: > > container a { > config false; > container b; > container c; > } > > gives the tree: > > a { config=false } > | > +- b { config=false } > | > +- c { config=false } > > and applying a deviation: > > deviation /a { > deviate replace { > config true; > } > deviation /a/b { > deviate replace { > config true; > } > > gives the tree: > > a { config=true } > | > +- b { config=true } > | > +- c { config=false } Not sure how I read that out of RFC 6020. But even if this is what RFC 6020 intends to mean in this case, you would have to create config=true deviations all the way from the top-level down to the affected leaf in the schema tree (and I guess that is what you are doing). Since RFC 6020 seems unclear and this is kind of a subtle point, we might need explicit text explaining how this would work. It is likely difficult to find a good example... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jan 11 06:58:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12521F862A for ; Wed, 11 Jan 2012 06:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99aY91Lu1+Kh for ; Wed, 11 Jan 2012 06:58:40 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4721F84F5 for ; Wed, 11 Jan 2012 06:58:40 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A2971200AC8; Wed, 11 Jan 2012 15:58:39 +0100 (CET) Date: Wed, 11 Jan 2012 15:58:38 +0100 (CET) Message-Id: <20120111.155838.1662300458992651968.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120111074742.GA12804@elstar.local> References: <20120110143544.GC95306@elstar.local> <201201102223.RAA21669@adminfs.snmp.com> <20120111074742.GA12804@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 14:58:41 -0000 Juergen Schoenwaelder wrote: > On Tue, Jan 10, 2012 at 05:23:24PM -0500, David Reid wrote: > > > > > But it conflicts with the desire to have the yang containment match > > > > the OID tree. > > > > > > This is where I stop following you. The scalars are not put in > > > arbitrary containers - the containers are derived from the > > > registration tree. > > > > An SNMP subtree walk on interfaces would return the scalars and ifTable. A > > netconf get on interfaces would only return the scalars. > > OK, now I see what you mean. The question is whether this matters. > > SNMP walks are in general not the same as NETCONF gets. And as > mentioned earlier, ifTable and ifXTable are quite far away in the SNMP > OID tree while the YANG augment puts things together. With the YANG > models derived from SNMP MIB modules, you actually get all interface > augments when you retrieve ifTable unless you put specific filters in > place. I prefer to keep things as they are. Incidentally, the result of all this moving scalars around is that the current draft exactly matches the structure we've been using the last five years :) /martin From spakes@snmp.com Wed Jan 11 07:02:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BA821F84F5 for ; Wed, 11 Jan 2012 07:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNq5yRC24oBr for ; Wed, 11 Jan 2012 07:02:25 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 93B9C21F865F for ; Wed, 11 Jan 2012 07:02:18 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA16286; Wed, 11 Jan 2012 10:02:09 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA08765; Wed, 11 Jan 2012 10:02:09 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 11 Jan 2012 10:02:08 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20120111103458.GB13647@elstar.local> Message-ID: References: <20120110.210432.290435654.mbj@tail-f.com> <20120111090458.GA13074@elstar.local> <20120111.111814.421335561013996052.mbj@tail-f.com> <20120111103458.GB13647@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:02:26 -0000 On Wed, 11 Jan 2012, Juergen Schoenwaelder wrote: > if you deviate the top-level node to config true, you will in turn > have to add config false to all leafs that remain config false, no? > If this is the case, would we then perhaps make life simpler by having > explicit config false statements generated for the leafs, either in > addition to the top-level config false or as a replacement of the > top-level config false? I was also going to make this suggestion. I think for clarity with the deviations, it would be better to move the config false statements to the leaf statements. The text for bullet 6 in Section 4.1 would need to change. > Not sure how I read that out of RFC 6020. But even if this is what RFC > 6020 intends to mean in this case, you would have to create > config=true deviations all the way from the top-level down to the > affected leaf in the schema tree (and I guess that is what you are > doing). I was thinking about this topic when I composed my message on January 5th (below). I equated collapsed hierarchy with a simpler algorithm because there are fewer levels of config inheritance. -dss On Thu, 5 Jan 2012, David Spakes wrote: > On Thu, 5 Jan 2012, Andy Bierman wrote: > > > Unless you can define a standard algorithm for deciding when to > > generate config true instead of config false, I don't think this > > can go into the draft. ... > > At one time, the task of coming up with such an algorithm seemed > daunting. However, now that we have collapsed the containment down to a > single level (and maybe no levels for scalars), shouldn't it be much > easier? e.g., > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From mbj@tail-f.com Wed Jan 11 07:15:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA0D21F8629 for ; Wed, 11 Jan 2012 07:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IkZJ5TmSdIr for ; Wed, 11 Jan 2012 07:15:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B91C721F85F1 for ; Wed, 11 Jan 2012 07:15:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F21271200AF6; Wed, 11 Jan 2012 16:15:23 +0100 (CET) Date: Wed, 11 Jan 2012 16:15:22 +0100 (CET) Message-Id: <20120111.161522.1545405804146287985.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120111103458.GB13647@elstar.local> References: <20120111090458.GA13074@elstar.local> <20120111.111814.421335561013996052.mbj@tail-f.com> <20120111103458.GB13647@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:15:25 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 11, 2012 at 11:18:14AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Jan 10, 2012 at 09:04:32PM +0100, Martin Bjorklund wrote: > > > > > > > > There is an issue that I would like clarity on. According to the > > > > > current draft, in Section 4.1 (Page 8), "A top-level YANG container is > > > > > generated...and the container MUST be config false." And in RFC 6020, > > > > > Section 7.19.1 (Page 105), "If a node has 'config' set to 'false', no > > > > > node underneath it can have 'config' set to 'true'. Martin, does your > > > > > deviation module change the top-level YANG container from 'config false' > > > > > to 'config true'? > > > > > > > > Yes. It generates 'config true' up in the hierarchy as needed. > > > > > > > > (I found a bug or two in the handling of deviations in pyang in the > > > > process, but I guess that's expected ;) > > > > > > Martin, > > > > > > if you deviate the top-level node to config true, you will in turn > > > have to add config false to all leafs that remain config false, no? > > > > I don't think I have to do that, but unfortunately the rfc is a bit > > unclear in this case. > > > > The config statement sets the "config" property on the node, and this > > property is inherited by child nodes. The deviate statement modifies > > the config property on the specified node only. > > > > By example: > > > > container a { > > config false; > > container b; > > container c; > > } > > > > gives the tree: > > > > a { config=false } > > | > > +- b { config=false } > > | > > +- c { config=false } > > > > and applying a deviation: > > > > deviation /a { > > deviate replace { > > config true; > > } > > deviation /a/b { > > deviate replace { > > config true; > > } > > > > gives the tree: > > > > a { config=true } > > | > > +- b { config=true } > > | > > +- c { config=false } > > Not sure how I read that out of RFC 6020. That's what I meant; the RFC is unclear... > But even if this is what RFC > 6020 intends to mean in this case, you would have to create > config=true deviations all the way from the top-level down to the > affected leaf in the schema tree (and I guess that is what you are > doing). > > Since RFC 6020 seems unclear and this is kind of a subtle point, we > might need explicit text explaining how this would work. It is likely > difficult to find a good example... Here's an example output from our tool that makes the addressMapControlTable from RMON2-MIB configuration: module RMON2-MIB-deviations { namespace "http://tail-f.com/yang/deviations/RMON2-MIB"; prefix "rmon2-mib-dev"; import RMON2-MIB { prefix "rmon2-mib"; revision-date 2006-05-02; } revision 2012-01-11 { description "First version."; } deviation "/rmon2-mib:RMON2-MIB" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlIndex" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlDataSource" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlOwner" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlStatus" { deviate replace { config true; } } } /martin From j.schoenwaelder@jacobs-university.de Wed Jan 11 07:38:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F30121F86C5 for ; Wed, 11 Jan 2012 07:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJjFrl0coLxg for ; Wed, 11 Jan 2012 07:38:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08921F860E for ; Wed, 11 Jan 2012 07:37:55 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC51A20BEE; Wed, 11 Jan 2012 16:37:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jYziGS0_WE3n; Wed, 11 Jan 2012 16:37:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1944B20BEA; Wed, 11 Jan 2012 16:37:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC06A1C79522; Wed, 11 Jan 2012 16:37:35 +0100 (CET) Date: Wed, 11 Jan 2012 16:37:35 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120111153734.GA15872@elstar.local> Mail-Followup-To: Martin Bjorklund , reid@snmp.com, netmod@ietf.org References: <20120110143544.GC95306@elstar.local> <201201102223.RAA21669@adminfs.snmp.com> <20120111074742.GA12804@elstar.local> <20120111.155838.1662300458992651968.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120111.155838.1662300458992651968.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:38:16 -0000 On Wed, Jan 11, 2012 at 03:58:38PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 10, 2012 at 05:23:24PM -0500, David Reid wrote: > > > > > > > But it conflicts with the desire to have the yang containment match > > > > > the OID tree. > > > > > > > > This is where I stop following you. The scalars are not put in > > > > arbitrary containers - the containers are derived from the > > > > registration tree. > > > > > > An SNMP subtree walk on interfaces would return the scalars and ifTable. A > > > netconf get on interfaces would only return the scalars. > > > > OK, now I see what you mean. The question is whether this matters. > > > > SNMP walks are in general not the same as NETCONF gets. And as > > mentioned earlier, ifTable and ifXTable are quite far away in the SNMP > > OID tree while the YANG augment puts things together. With the YANG > > models derived from SNMP MIB modules, you actually get all interface > > augments when you retrieve ifTable unless you put specific filters in > > place. > > I prefer to keep things as they are. Incidentally, the result of all > this moving scalars around is that the current draft exactly matches > the structure we've been using the last five years :) Just in case this has not been clear, I also prefer to stop moving things around since I feel we go in circles. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jan 11 12:15:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2C11E80AC for ; Wed, 11 Jan 2012 12:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4eU-5vaDUAf for ; Wed, 11 Jan 2012 12:15:32 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E67B711E80AB for ; Wed, 11 Jan 2012 12:15:31 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 893E71200050; Wed, 11 Jan 2012 21:15:30 +0100 (CET) Date: Wed, 11 Jan 2012 21:15:28 +0100 (CET) Message-Id: <20120111.211528.98508658.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120111094615.GB13402@elstar.local> References: <20120111094615.GB13402@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:15:32 -0000 Juergen Schoenwaelder wrote: > * smi2yang-23: config true deviations [open] > > One approach to support edit-config writable MIB objects is to use > YANG deviations, i.e., an implementation announces an additional > YANG module that provides config true information via YANG > deviations. RFC 6020, Section 7.18.3, Page 103 says: > > Device deviations are strongly discouraged and MUST only be used as a > last resort. Telling the application how a device fails to follow a > standard is no substitute for implementing the standard correctly. A > device that deviates from a module is not fully compliant with the > module. > > This text apparently was written for the case that an > implementation can't meet the minimum requirements of the YANG > contract, which is not the case here. > > ** Solution #23-01 > > Add text to clarify that config true deviations that add > functionality do not impact the compliance of an implementation: > > Implementations may choose to implement some data nodes as > configuration data nodes. Such a deviation from the generated > YANG module should be formally documented in a separate YANG > module that details the changes using YANG deviation statements > changing the config tag of the data nodes implemented as > configuration data nodes from false to true. Deviations that > change the config false tag to true without any other changes to > the semantics of the data node do not affect the compliance with > the YANG module generated from an SMIv2 module. I am fine with adding this text. However, I would not use the term "tag", since it is not used in 6020. I think I would use the term "property", since that's what's being used in the text about deviations: Implementations may choose to implement some data nodes as configuration data nodes. Such a deviation from the generated YANG module should be formally documented in a separate YANG module that details the changes using YANG deviation statements changing the "config" property of the data nodes implemented as configuration data nodes from false to true. Deviations that change the "config" property to true without any other changes to the semantics of the data node do not affect the compliance with the YANG module generated from an SMIv2 module. And probably add the example I sent, or something similar. /martin From reid@snmp.com Wed Jan 11 12:22:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFDE11E80C2 for ; Wed, 11 Jan 2012 12:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 490txfD2mCw2 for ; Wed, 11 Jan 2012 12:22:39 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8BE11E80AB for ; Wed, 11 Jan 2012 12:22:38 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA14185; Wed, 11 Jan 2012 15:22:38 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA23033; Wed, 11 Jan 2012 15:22:37 -0500 (EST) Message-Id: <201201112022.PAA23033@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Wed, 11 Jan 2012 10:46:15 +0100. <20120111094615.GB13402@elstar.local> Date: Wed, 11 Jan 2012 15:22:37 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:22:39 -0000 > * smi2yang-23: config true deviations [open] > > One approach to support edit-config writable MIB objects is to use > YANG deviations, i.e., an implementation announces an additional > YANG module that provides config true information via YANG > deviations. RFC 6020, Section 7.18.3, Page 103 says: > > Device deviations are strongly discouraged and MUST only be used as a > last resort. Telling the application how a device fails to follow a > standard is no substitute for implementing the standard correctly. A > device that deviates from a module is not fully compliant with the > module. > > This text apparently was written for the case that an > implementation can't meet the minimum requirements of the YANG > contract, which is not the case here. > > ** Solution #23-01 > > Add text to clarify that config true deviations that add > functionality do not impact the compliance of an implementation: > > Implementations may choose to implement some data nodes as > configuration data nodes. Such a deviation from the generated > YANG module should be formally documented in a separate YANG > module that details the changes using YANG deviation statements > changing the config tag of the data nodes implemented as > configuration data nodes from false to true. Deviations that > change the config false tag to true without any other changes to > the semantics of the data node do not affect the compliance with > the YANG module generated from an SMIv2 module. > > /js I like this solution. -David Reid From reid@snmp.com Wed Jan 11 12:31:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1611E80C6 for ; Wed, 11 Jan 2012 12:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4570NK+7YjT6 for ; Wed, 11 Jan 2012 12:31:26 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 931AB11E80AB for ; Wed, 11 Jan 2012 12:31:25 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA14605; Wed, 11 Jan 2012 15:31:24 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA23193; Wed, 11 Jan 2012 15:31:24 -0500 (EST) Message-Id: <201201112031.PAA23193@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Wed, 11 Jan 2012 08:47:42 +0100. <20120111074742.GA12804@elstar.local> Date: Wed, 11 Jan 2012 15:31:24 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang containment hierarchy X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:31:26 -0000 > On Tue, Jan 10, 2012 at 05:23:24PM -0500, David Reid wrote: > > > > > But it conflicts with the desire to have the yang containment match > > > > the OID tree. > > > > > > This is where I stop following you. The scalars are not put in > > > arbitrary containers - the containers are derived from the > > > registration tree. > > > > An SNMP subtree walk on interfaces would return the scalars and ifTable. A > > netconf get on interfaces would only return the scalars. > > OK, now I see what you mean. The question is whether this matters. > > SNMP walks are in general not the same as NETCONF gets. And as > mentioned earlier, ifTable and ifXTable are quite far away in the SNMP > OID tree while the YANG augment puts things together. With the YANG > models derived from SNMP MIB modules, you actually get all interface > augments when you retrieve ifTable unless you put specific filters in > place. > > /js We had to add special hacks to handle augments since SNMP and NETCONF are so different in this respect. We'll have to do similar things in this case if the SNMP and NETCONF containment is different. It can be done, it's just more work. I seem to be in the minority on this, so I'm OK leaving it as it is. -David Reid From j.schoenwaelder@jacobs-university.de Wed Jan 11 23:46:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5473921F8655 for ; Wed, 11 Jan 2012 23:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs4mMWOi6nF7 for ; Wed, 11 Jan 2012 23:46:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDF721F864B for ; Wed, 11 Jan 2012 23:46:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D53220BD8; Thu, 12 Jan 2012 08:46:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N5RgmhXWrecB; Thu, 12 Jan 2012 08:46:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1F2720BD7; Thu, 12 Jan 2012 08:46:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 498FC1C7F29B; Thu, 12 Jan 2012 08:46:20 +0100 (CET) Date: Thu, 12 Jan 2012 08:46:20 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120112074620.GA93753@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120111094615.GB13402@elstar.local> <20120111.211528.98508658.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120111.211528.98508658.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 07:46:39 -0000 On Wed, Jan 11, 2012 at 09:15:28PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > * smi2yang-23: config true deviations [open] > > > > One approach to support edit-config writable MIB objects is to use > > YANG deviations, i.e., an implementation announces an additional > > YANG module that provides config true information via YANG > > deviations. RFC 6020, Section 7.18.3, Page 103 says: > > > > Device deviations are strongly discouraged and MUST only be used as a > > last resort. Telling the application how a device fails to follow a > > standard is no substitute for implementing the standard correctly. A > > device that deviates from a module is not fully compliant with the > > module. > > > > This text apparently was written for the case that an > > implementation can't meet the minimum requirements of the YANG > > contract, which is not the case here. > > > > ** Solution #23-01 > > > > Add text to clarify that config true deviations that add > > functionality do not impact the compliance of an implementation: > > > > Implementations may choose to implement some data nodes as > > configuration data nodes. Such a deviation from the generated > > YANG module should be formally documented in a separate YANG > > module that details the changes using YANG deviation statements > > changing the config tag of the data nodes implemented as > > configuration data nodes from false to true. Deviations that > > change the config false tag to true without any other changes to > > the semantics of the data node do not affect the compliance with > > the YANG module generated from an SMIv2 module. > > I am fine with adding this text. However, I would not use the term > "tag", since it is not used in 6020. I think I would use the term > "property", since that's what's being used in the text about > deviations: I picked 'tag' because of this: YANG can model state data, as well as configuration data, based on the "config" statement. When a node is tagged with "config false", its subhierarchy is flagged as state data, to be reported using NETCONF's operation, not the operation. Parent containers, lists, and key leafs are reported also, giving the context for the state data. I originally had property and will change it back. /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 Jan 12 01:09:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112D921F8471 for ; Thu, 12 Jan 2012 01:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rmggzTqSt1G for ; Thu, 12 Jan 2012 01:09:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C77A21F85A2 for ; Thu, 12 Jan 2012 01:09:49 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E704F20BD8; Thu, 12 Jan 2012 10:09:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ler5sjyTW4tW; Thu, 12 Jan 2012 10:09:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DB6C20BCD; Thu, 12 Jan 2012 10:09:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E58B61C7F5DB; Thu, 12 Jan 2012 10:09:29 +0100 (CET) Date: Thu, 12 Jan 2012 10:09:29 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120112090929.GA94139@elstar.local> Mail-Followup-To: Martin Bjorklund , spakes@snmp.com, netmod@ietf.org References: <20120111090458.GA13074@elstar.local> <20120111.111814.421335561013996052.mbj@tail-f.com> <20120111103458.GB13647@elstar.local> <20120111.161522.1545405804146287985.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120111.161522.1545405804146287985.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:09:59 -0000 On Wed, Jan 11, 2012 at 04:15:22PM +0100, Martin Bjorklund wrote: > Here's an example output from our tool that makes the > addressMapControlTable from RMON2-MIB configuration: [...] > deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlStatus" { > deviate replace { > config true; > } > } Does it really make sense to consider a RowStatus object a config true YANG object? The values you can write in SNMP land are createAndGo, createAndWait, and destroy. I would assume that NETCONF's edit-config takes care of creating/deleting the list entry. Note that notInService is a temporary state and such rows are garbage collected according to the RowStatus TC definition. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Jan 12 01:46:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934E321F859A for ; Thu, 12 Jan 2012 01:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7emQr771kdGu for ; Thu, 12 Jan 2012 01:46:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AF2C421F8592 for ; Thu, 12 Jan 2012 01:46:22 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09DCE20A1C; Thu, 12 Jan 2012 10:38:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dzGTLHeRmNID; Thu, 12 Jan 2012 10:38:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B43520BD8; Thu, 12 Jan 2012 10:38:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5CD4D1C7F6CA; Thu, 12 Jan 2012 10:38:32 +0100 (CET) Date: Thu, 12 Jan 2012 10:38:31 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120112093831.GA94257@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20120111094615.GB13402@elstar.local> <201201112022.PAA23033@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201112022.PAA23033@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:46:28 -0000 On Wed, Jan 11, 2012 at 09:15:28PM +0100, Martin Bjorklund wrote: > I am fine with adding this text. [...] On Wed, Jan 11, 2012 at 03:22:37PM -0500, David Reid wrote: > > I like this solution. While editing, I thought it is important to highlight the difference in the persistency models in order to explain why by default data nodes are read-only. I think this is important so that people understand that it is sometimes wrong to simply mark writable SNMP objects as config true. So I ended up writing a whole new section. Please let me know if something needs changes or whether you are fine with it. 11. Configurable Data Objects The translation of SMIv2 MIB modules into YANG modules defined above is read-only. One reason is that the persistency models of the underlying protocols, SNMP and NETCONF, are quite different. With SNMP, the persistency of a writable object depends either on the object definition itself (i.e., the text in the DESCRIPTION clause) or the persistency properties of the conceptual row it is part of, sometimes controlled via a columnar object using the StorageType textual convention. With NETCONF, the persistency of configuration objects is determined by the properties of the underlying datastore. Furthermore, NETCONF as defined in [RFC6241] does not provide a standard operation to modify operational state. The and operations only manipulate configuration data. As a consequence of these considerations, it is not possible to generate YANG configuration data nodes from SMIv2 definitions in an automated way. However, for selected SMIv2 objects where the SNMP and NETCONF persistency semantics are consistent, implementations may choose to implement some YANG data nodes generated from SMIv2 definitions as configuration data nodes. Such a deviation from the generated read- only YANG module should be formally documented in a separate YANG module that uses YANG deviation statements to change the config property of the data nodes implemented as configuration data nodes from false to true. Deviations that change the config false property to true without any other changes to the semantics of the data node do not affect the compliance with the YANG module generated from an SMIv2 module. 11.1. Example: addressMapControlTable of RMON2-MIB The following example demonstrates how certain columnar objects of the addressMapControlTable of the RMON2-MIB [RFC4502] can be turned into YANG configuration data nodes. Note that YANG deviations affect the property of the target node only and are not inherited downwards. module acme-RMON2-MIB-deviations { namespace "http://acme.example.com/RMON2-MIB-deviations"; prefix "acme-rmon2-devs"; import RMON2-MIB { prefix "rmon2-mib"; revision-date 2006-05-02; } revision 2012-01-11 { description "First version."; } deviation "/rmon2-mib:RMON2-MIB" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:addressMapControlTable" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:addressMapControlTable/" + "rmon2-mib:addressMapControlEntry" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:addressMapControlTable/" + "rmon2-mib:addressMapControlEntry/" + "rmon2-mib:addressMapControlIndex" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:addressMapControlTable/" + "rmon2-mib:addressMapControlEntry/" + "rmon2-mib:addressMapControlDataSource" { deviate replace { config true; } } deviation "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:addressMapControlTable/" + "rmon2-mib:addressMapControlEntry/" + "rmon2-mib:addressMapControlOwner" { deviate replace { config true; } } } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jan 12 03:11:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A968921F84E2 for ; Thu, 12 Jan 2012 03:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmchLhB-Lr69 for ; Thu, 12 Jan 2012 03:11:32 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 257DC21F8478 for ; Thu, 12 Jan 2012 03:11:31 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4829C1200AC8; Thu, 12 Jan 2012 12:11:30 +0100 (CET) Date: Thu, 12 Jan 2012 12:11:29 +0100 (CET) Message-Id: <20120112.121129.526915939996994158.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120112090929.GA94139@elstar.local> References: <20120111103458.GB13647@elstar.local> <20120111.161522.1545405804146287985.mbj@tail-f.com> <20120112090929.GA94139@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:11:32 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 11, 2012 at 04:15:22PM +0100, Martin Bjorklund wrote: > > > Here's an example output from our tool that makes the > > addressMapControlTable from RMON2-MIB configuration: > > [...] > > > deviation "/rmon2-mib:RMON2-MIB/rmon2-mib:addressMapControlTable/rmon2-mib:addressMapControlEntry/rmon2-mib:addressMapControlStatus" { > > deviate replace { > > config true; > > } > > } > > Does it really make sense to consider a RowStatus object a config true > YANG object? No, you're absolutely right. It should *not* be deviated. /martin From mbj@tail-f.com Thu Jan 12 03:35:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D88E21F8545 for ; Thu, 12 Jan 2012 03:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9xhyWjUgFK5 for ; Thu, 12 Jan 2012 03:35:33 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8907021F8532 for ; Thu, 12 Jan 2012 03:35:33 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A28511200052; Thu, 12 Jan 2012 12:35:32 +0100 (CET) Date: Thu, 12 Jan 2012 12:35:31 +0100 (CET) Message-Id: <20120112.123531.867295923113831967.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120112093831.GA94257@elstar.local> References: <20120111094615.GB13402@elstar.local> <201201112022.PAA23033@adminfs.snmp.com> <20120112093831.GA94257@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:35:34 -0000 Juergen Schoenwaelder wrote: > While editing, I thought it is important to highlight the difference > in the persistency models in order to explain why by default data > nodes are read-only. I think this is important so that people > understand that it is sometimes wrong to simply mark writable SNMP > objects as config true. So I ended up writing a whole new section. > Please let me know if something needs changes or whether you are fine > with it. I like this new text. > 11. Configurable Data Objects > > The translation of SMIv2 MIB modules into YANG modules defined above > is read-only. One reason is that the persistency models of the > underlying protocols, SNMP and NETCONF, are quite different. With > SNMP, the persistency of a writable object depends either on the > object definition itself (i.e., the text in the DESCRIPTION clause) > or the persistency properties of the conceptual row it is part of, > sometimes controlled via a columnar object using the StorageType > textual convention. With NETCONF, the persistency of configuration > objects is determined by the properties of the underlying datastore. > Furthermore, NETCONF as defined in [RFC6241] does not provide a > standard operation to modify operational state. The > and operations only manipulate configuration data. As > a consequence of these considerations, it is not possible to generate > YANG configuration data nodes from SMIv2 definitions in an automated > way. > > However, for selected SMIv2 objects where the SNMP and NETCONF > persistency semantics are consistent, implementations may choose to > implement some YANG data nodes generated from SMIv2 definitions as > configuration data nodes. Such a deviation from the generated read- > only YANG module should be formally documented in a separate YANG s/should/SHOULD/ ? > module that uses YANG deviation statements to change the config > property of the data nodes implemented as configuration data nodes > from false to true. Deviations that change the config false property > to true without any other changes to the semantics of the data node > do not affect the compliance with the YANG module generated from an > SMIv2 module. > > 11.1. Example: addressMapControlTable of RMON2-MIB > > The following example demonstrates how certain columnar objects of > the addressMapControlTable of the RMON2-MIB [RFC4502] can be turned > into YANG configuration data nodes. Note that YANG deviations affect > the property of the target node only and are not inherited downwards. > > module acme-RMON2-MIB-deviations { > > namespace "http://acme.example.com/RMON2-MIB-deviations"; > prefix "acme-rmon2-devs"; > > import RMON2-MIB { > prefix "rmon2-mib"; > revision-date 2006-05-02; > } > > revision 2012-01-11 { > description > "First version."; > } > > deviation "/rmon2-mib:RMON2-MIB" { > deviate replace { > config true; > } > } > > deviation "/rmon2-mib:RMON2-MIB/" > + "rmon2-mib:addressMapControlTable" { > deviate replace { > config true; > } > } > > deviation "/rmon2-mib:RMON2-MIB/" > + "rmon2-mib:addressMapControlTable/" > + "rmon2-mib:addressMapControlEntry" { > deviate replace { > config true; > } > } > > deviation "/rmon2-mib:RMON2-MIB/" > + "rmon2-mib:addressMapControlTable/" > + "rmon2-mib:addressMapControlEntry/" > + "rmon2-mib:addressMapControlIndex" { > deviate replace { > config true; > } > } > > deviation "/rmon2-mib:RMON2-MIB/" > + "rmon2-mib:addressMapControlTable/" > + "rmon2-mib:addressMapControlEntry/" > + "rmon2-mib:addressMapControlDataSource" { > deviate replace { > config true; > } > } > > deviation "/rmon2-mib:RMON2-MIB/" > + "rmon2-mib:addressMapControlTable/" > + "rmon2-mib:addressMapControlEntry/" > + "rmon2-mib:addressMapControlOwner" { > deviate replace { > config true; > } > } > } Maybe we can provide even more clarity here by giving an example how this deviations module is used. Strictly speaking it is not needed; people can connect the dots by reading 6020, but examples are often useful. A NETCONF server that implements the RMON2-MIB module with these deviations would advertise the following capabilities in its message (where whitespace has been added for readability): urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB? module=RMON2-MIB& revision=2006-05-02& deviations=acme-RMON2-MIB-deviations http://acme.example.com/RMON2-MIB-deviations? module=acme-RMON2-MIB-deviations& revision=2012-01-11 /martin From j.schoenwaelder@jacobs-university.de Thu Jan 12 03:57:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3521F852B for ; Thu, 12 Jan 2012 03:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gFeQbAGuRGT for ; Thu, 12 Jan 2012 03:57:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CF04721F852A for ; Thu, 12 Jan 2012 03:57:46 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E34920BDE; Thu, 12 Jan 2012 12:57:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lYPgMU3_J9NX; Thu, 12 Jan 2012 12:57:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C99EC20BD7; Thu, 12 Jan 2012 12:57:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 357991C807C5; Thu, 12 Jan 2012 12:57:29 +0100 (CET) Date: Thu, 12 Jan 2012 12:57:29 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120112115729.GB95631@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120111094615.GB13402@elstar.local> <201201112022.PAA23033@adminfs.snmp.com> <20120112093831.GA94257@elstar.local> <20120112.123531.867295923113831967.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120112.123531.867295923113831967.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:57:47 -0000 On Thu, Jan 12, 2012 at 12:35:31PM +0100, Martin Bjorklund wrote: > I like this new text. Great. > > However, for selected SMIv2 objects where the SNMP and NETCONF > > persistency semantics are consistent, implementations may choose to > > implement some YANG data nodes generated from SMIv2 definitions as > > configuration data nodes. Such a deviation from the generated read- > > only YANG module should be formally documented in a separate YANG > > s/should/SHOULD/ ? We can make it a SHOULD but it is not something one can implement and hence I think it is really more a should. At the end, I always do what the IESG wants me to do - so we can also leave it to them. ;-) > Maybe we can provide even more clarity here by giving an example how > this deviations module is used. Strictly speaking it is not needed; > people can connect the dots by reading 6020, but examples are often > useful. > > A NETCONF server that implements the RMON2-MIB module with these > deviations would advertise the following capabilities in its > message (where whitespace has been added for readability): > > > urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB? > module=RMON2-MIB& > revision=2006-05-02& > deviations=acme-RMON2-MIB-deviations > > > http://acme.example.com/RMON2-MIB-deviations? > module=acme-RMON2-MIB-deviations& > revision=2012-01-11 > I will add this. Examples help implementors a great deal to come up with the same conclusions or they simply save them some time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jan 12 04:34:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2069521F852E for ; Thu, 12 Jan 2012 04:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0bKgTkmRMyY for ; Thu, 12 Jan 2012 04:34:14 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2B21F852C for ; Thu, 12 Jan 2012 04:34:14 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F0EFD1200AC8; Thu, 12 Jan 2012 13:34:11 +0100 (CET) Date: Thu, 12 Jan 2012 13:34:10 +0100 (CET) Message-Id: <20120112.133410.2074931842212500467.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120112093831.GA94257@elstar.local> References: <20120111094615.GB13402@elstar.local> <201201112022.PAA23033@adminfs.snmp.com> <20120112093831.GA94257@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-23: config true deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:34:15 -0000 Hi, One small clarification below. Juergen Schoenwaelder wrote: > 11. Configurable Data Objects > > The translation of SMIv2 MIB modules into YANG modules defined above > is read-only. One reason is that the persistency models of the > underlying protocols, SNMP and NETCONF, are quite different. With > SNMP, the persistency of a writable object depends either on the > object definition itself (i.e., the text in the DESCRIPTION clause) > or the persistency properties of the conceptual row it is part of, > sometimes controlled via a columnar object using the StorageType > textual convention. With NETCONF, the persistency of configuration > objects is determined by the properties of the underlying datastore. > Furthermore, NETCONF as defined in [RFC6241] does not provide a > standard operation to modify operational state. The > and operations only manipulate configuration data. As > a consequence of these considerations, it is not possible to generate > YANG configuration data nodes from SMIv2 definitions in an automated > way. > > However, for selected SMIv2 objects where the SNMP and NETCONF > persistency semantics are consistent, implementations may choose to > implement some YANG data nodes generated from SMIv2 definitions as > configuration data nodes. Such a deviation from the generated read- > only YANG module should be formally documented in a separate YANG s/in a separate/in the form of a separate/ > module that uses YANG deviation statements to change the config > property of the data nodes implemented as configuration data nodes > from false to true. Deviations that change the config false property > to true without any other changes to the semantics of the data node > do not affect the compliance with the YANG module generated from an > SMIv2 module. /martin From internet-drafts@ietf.org Thu Jan 19 03:42:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF021F85BE; Thu, 19 Jan 2012 03:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZuUIYExReEA; Thu, 19 Jan 2012 03:42:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B46D21F84E2; Thu, 19 Jan 2012 03:42:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120119114227.15126.44690.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 03:42:27 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-smi-yang-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 11:42:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : Translation of SMIv2 MIB Modules to YANG Modules Author(s) : Juergen Schoenwaelder Filename : draft-ietf-netmod-smi-yang-04.txt Pages : 43 Date : 2012-01-19 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-04.txt From wwwrun@rfc-editor.org Fri Jan 20 06:11:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6A121F8432 for ; Fri, 20 Jan 2012 06:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZQteHVm8WPb for ; Fri, 20 Jan 2012 06:11:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4341121F859E for ; Fri, 20 Jan 2012 06:11:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0DA19B1E002; Fri, 20 Jan 2012 06:08:06 -0800 (PST) To: mbj@tail-f.com, dromasca@avaya.com, rbonica@juniper.net, david.kessens@nsn.com, j.schoenwaelder@jacobs-university.de From: RFC Errata System Message-Id: <20120120140806.0DA19B1E002@rfc-editor.org> Date: Fri, 20 Jan 2012 06:08:06 -0800 (PST) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3094) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:11:23 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3094 -------------------------------------- Type: Technical Reported by: Emmanuel Nataf Section: 12 Original Text ------------- bit-stmt = bit-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [position-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}" "}") Corrected Text -------------- bit-stmt = bit-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [position-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") Notes ----- An extra "}" Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From mbj@tail-f.com Mon Jan 23 03:22:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9CD21F86D3 for ; Mon, 23 Jan 2012 03:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96m++K+pEZfq for ; Mon, 23 Jan 2012 03:22:54 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8A221F86CF for ; Mon, 23 Jan 2012 03:22:54 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F3A91200052; Mon, 23 Jan 2012 12:22:52 +0100 (CET) Date: Mon, 23 Jan 2012 12:22:52 +0100 (CET) Message-Id: <20120123.122252.71074797327518520.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20120120140806.0DA19B1E002@rfc-editor.org> References: <20120120140806.0DA19B1E002@rfc-editor.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, rbonica@juniper.net Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3094) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 11:22:56 -0000 Hi, This is a bug in 6020, and the proposed Corrected Text is ok. /martin RFC Errata System wrote: > > The following errata report has been submitted for RFC6020, > "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3094 > > -------------------------------------- > Type: Technical > Reported by: Emmanuel Nataf > > Section: 12 > > Original Text > ------------- > bit-stmt = bit-keyword sep identifier-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [position-stmt stmtsep] > [status-stmt stmtsep] > [description-stmt stmtsep] > [reference-stmt stmtsep] > "}" > "}") > > Corrected Text > -------------- > bit-stmt = bit-keyword sep identifier-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [position-stmt stmtsep] > [status-stmt stmtsep] > [description-stmt stmtsep] > [reference-stmt stmtsep] > "}") > > Notes > ----- > An extra "}" > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6020 (draft-ietf-netmod-yang-13) > -------------------------------------- > Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) > Publication Date : October 2010 > Author(s) : M. Bjorklund, Ed. > Category : PROPOSED STANDARD > Source : NETCONF Data Modeling Language > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From david.kessens@nsn.com Mon Jan 23 19:54:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFE621F85E5 for ; Mon, 23 Jan 2012 19:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTFefF3roU89 for ; Mon, 23 Jan 2012 19:54:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DB33621F85E1 for ; Mon, 23 Jan 2012 19:54:08 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0O3s450005415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jan 2012 04:54:05 +0100 Received: from localhost.localdomain ([10.138.49.179]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0O3s09E009352 for ; Tue, 24 Jan 2012 04:54:03 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q0O3rwFv028837 for ; Mon, 23 Jan 2012 19:53:58 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q0O3rwnS028836 for netmod@ietf.org; Mon, 23 Jan 2012 19:53:58 -0800 Date: Mon, 23 Jan 2012 19:53:57 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20120124035357.GA28803@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Charter addition: Data model for configuring SNMP engines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 03:54:09 -0000 5A Working group, The chairpeople have taken a look at the discussion regarding a new chartered item for "Data model for configuring SNMP engines". We believe that we have reached a somewhat rough consensus on the following charter text addition: 5. Data model for configuring SNMP engines. The model must be capable of representing all SNMP engine configurations possible with the standard SNMPv3 MIB modules that are common operational practice. Any differences in functionality and behavior should be documented. We have asked our area director to consider the above text and to take any further actions to get our charter approved and updated. I hope this helps, David Kessens & Juergen Schoenwaelder --- From david.kessens@nsn.com Wed Jan 25 20:50:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35121F857A for ; Wed, 25 Jan 2012 20:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.885 X-Spam-Level: X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfTqPW1Y2F8B for ; Wed, 25 Jan 2012 20:50:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 717FA21F8578 for ; Wed, 25 Jan 2012 20:50:11 -0800 (PST) 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 q0Q4o7C0018531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 26 Jan 2012 05:50:07 +0100 Received: from localhost.localdomain ([10.138.49.195]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0Q4o5wd032445 for ; Thu, 26 Jan 2012 05:50:07 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q0Q4o30n005440 for ; Wed, 25 Jan 2012 20:50:03 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q0Q4o3Tu005439 for netmod@ietf.org; Wed, 25 Jan 2012 20:50:03 -0800 Date: Wed, 25 Jan 2012 20:50:03 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20120126045003.GA6827@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Last Call: draft-ietf-netmod-smi-yang-04 (20110206) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:50:12 -0000 Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/id/draft-ietf-netmod-smi-yang-04.txt Juergen has tried to address all previous last call comments and I would like to confirm with the working group that this new version of the draft resolves all remaining issues. Please indicate your support by February 6, 2012. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved. Thanks! David Kessens co-chair netmod wg ---