From reid@snmp.com Mon Oct 10 14:23:46 2011 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 B0B4921F8C8D for ; Mon, 10 Oct 2011 14:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbrgMCPRxdX8 for ; Mon, 10 Oct 2011 14:23:44 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C55D121F8C8F for ; Mon, 10 Oct 2011 14:23:43 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA17653 for ; Mon, 10 Oct 2011 17:23:42 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA29925 for ; Mon, 10 Oct 2011 17:23:42 -0400 (EDT) Message-Id: <201110102123.RAA29925@adminfs.snmp.com> To: netmod@ietf.org Date: Mon, 10 Oct 2011 17:23:42 -0400 From: David Reid Subject: [netmod] mib to yang conversion: imports 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, 10 Oct 2011 21:23:46 -0000 I modified our MIB to yang conversion tool to conform to draft-ietf-netmod-smi-yang-01. Overall, I think the document is in good shape, but I did run into a few issues for which I will try to propose solutions. To test, I converted all the current standard MIBs to yang and then ran the converted modules through pyang. I also compared my output on a couple of the modules to the smidump output. pyang generated a number of warnings and a few errors. There are also some differences between what I produce and what smidump produces. I modified my tool to produce yang modules that compile with no warnings or errors under pyang and I'm going to try to propose some text that will address these issues. I have some questions about some other issues and I need to study some of the issues more before I can make an intelligent comment. I'll address some issues with imports in this message and address other issues in subsequent messages. I found 3 basic issues with imports: 1. Lots of modules produce the pyang warning "imported module FOO not used". That's not fatal, but I think we can re-write the imports section to address this. Some examples include object identifier assignments and objects referenced in conformance and compliance statements. 2. There were a couple of errors where we reference objects in modules that were not imported. Here is an example: ADSL-LINE-EXT-MIB defines the notification adslAtucFailedFastRThreshTrap which includes the object adslAtucPerfCurr15MinFailedFastR. adslAtucPerfCurr15MinFailedFastR is defined in a table that augments adslAtucPerfDataEntry. adslAtucPerfDataEntry is imported. adslAtucPerfDataEntry is indexed by ifIndex. ifIndex is not imported in the MIB module since it is not directly referenced. But in the yang notification, we have to include ifIndex, therefore, ifIndex needs to be imported. 3. A few SMIv2 modules IMPORT from SMIv1 modules, but we don't define rules for converting SMIv1 modules. For example, RMON2-MIB is an SMIv2 module which imports from TOKEN-RING-RMON-MIB which is an SMIv1 module. Lots of modules import RMON2-MIB to get ZeroBasedCounter32, so I think it is important that RMON2-MIB work (there's also the issue with the same object used multiple times in the index clause -- I'll address that in a subsequent message). I don't want to waste a lot of time on SMIv1, but if SMIv2 modules IMPORT from SMIv1 modules I think we need to address that. See my suggestion below. Here is the text for my proposed solutions. In section 4, remove Table 3 and replace the text in the bullet points with the following: o Process each item in each SMIv2 IMPORT clause as follows: (1) If an import statement for this SMIv2 module has already been generated, then ignore this item. (2) Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2-CONF, then ignore this item. Note that these two modules can be completely ignored since all definitions in these modules are translated by translation rules. (3) Otherwise, if this item is a textual convention matching one of the textual conventions in the SMIv2 types column of Table 1 (MacAddress, PhysAddress, or TimeStamp) then ignore this item. [Note: We may want to add more TCs than just these 3. I'll address that in a separate e-mail] (4) Otherwise, if the item is used in a SYNTAX clause of an OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify, then generate an import statement as described below. (5) Otherwise, if the item is used in an OBJECTS clause of a NOTIFICATION-TYPE, then generate an import statement as described below. (6) Otherwise, if the item is used in an INDEX or AUGMENTS clause, then generate an import statement as described below. (7) Otherwise, ignore this item. Some examples of this case are OBJECT IDENTIFIER assignments and objects that are only referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or NOTIFICATION-GROUP clauses. o Generate any additional imports statements as required by the type translations according to the type mapping table (Table 1). This requires the translator to consider all the types used in the translation unit in order to produce the imports. o Generate an import statement for the yang module ietf-yang-smiv2 with the prefix smiv2 if extensions from ietf-yang-smiv2 will be used in the translated yang module. Add the following sentence somewhere, perhaps at the end of the first paragraph in section 1, to address the case where an SMIv2 module imports from an SMIv1 module: SMIv1 modules may be converted to YANG by first following the rules in RFC 3584 to convert the SMIv1 module to SMIv2, then following the rules in this document to convert to YANG. -David Reid From reid@snmp.com Mon Oct 10 14:26:31 2011 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 E464021F8CC7 for ; Mon, 10 Oct 2011 14:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW6qOB1HO24D for ; Mon, 10 Oct 2011 14:26:31 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3782521F8CA7 for ; Mon, 10 Oct 2011 14:26:31 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA17884 for ; Mon, 10 Oct 2011 17:26:30 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA00111 for ; Mon, 10 Oct 2011 17:26:30 -0400 (EDT) Message-Id: <201110102126.RAA00111@adminfs.snmp.com> To: netmod@ietf.org Date: Mon, 10 Oct 2011 17:26:30 -0400 From: David Reid Subject: [netmod] mib to yang conversion: 2 more issues 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, 10 Oct 2011 21:26:32 -0000 Here are a couple more issues with the mib to yang conversion and proposed solutions. Problem: If a table index is accessible-for-notify, it is not translated to yang. For example, in MIP-MIB (RFC 2006), the object mipSecViolatorAddress is a table index and has a MAX-ACCESS of accessible-for-notify. According to the current conversion rules (section 8.1), mipSecViolatorAddress will be dropped. But since it is a table index, it must be preserved. Proposed Solution: Add the following sentence as the second sentence in section 1.8: Additionally, columnar objects with a MAX-ACCESS of accessible-for-notify are translated to YANG leaf statements if that columnar object is part of the INDEX clause of the table containing that columnar object. Problem: RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex twice. Following the current conversion rules results in a translated document that violates the YANG rule that a leaf identifier MUST NOT appear more than once in the key. Proposed Solution: Section 8.3 in the last bullet point on page 15, add a sentence somthing like this: If the same object appears more than once in the INDEX clause, append - to the second and subsequent duplicate object names where is a number representing the number of times that object has appeared up to this point in the INDEX clause. [not sure I stated that clearly. I'm trying to say that the key statement for alHostEntry should be key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex nlHostAddress protocolDirLocalIndex-2";] -David Reid From reid@snmp.com Tue Oct 11 13:51:44 2011 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 92C3221F8DF2 for ; Tue, 11 Oct 2011 13:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQnBxhGVZoE3 for ; Tue, 11 Oct 2011 13:51:43 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87121F8CA2 for ; Tue, 11 Oct 2011 13:51:43 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA10684 for ; Tue, 11 Oct 2011 16:51:17 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA12699 for ; Tue, 11 Oct 2011 16:51:12 -0400 (EDT) Message-Id: <201110112051.QAA12699@adminfs.snmp.com> To: NETMOD Working Group From: David Reid In-reply-to: Your message of Tue, 26 Jul 2011 08:15:32 -0700. <4E2EDA14.9090605@andybierman.com> Date: Tue, 11 Oct 2011 16:51:12 -0400 Sender: reid@snmp.com Subject: Re: [netmod] comments on draft-ietf-netmod-smi-01 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, 11 Oct 2011 20:51:44 -0000 > Andy Bierman wrote: > > sec 2: > > Implementations are encouraged to provide > options to handle situations where DISPLAY-HINTs are added during a > revision of a module and backwards compatibility must be preserved. > > What are the options they are encouraged to provide? I agree that this needs more work. I don't have a good solution at this point. > > > sec 3: > > The order modules are processed by a translator will affect the > prefix algorithm, wrt/ detecting conflicts. It seems this algorithm is > ad-hoc, and there is no way to determine if the shortest unique > prefix is really found. IMO it would be better to allow a translator > to use the entire converted module name to be sure the prefix is unique. I agree with Andy about using the entire name for the prefix. I think the full name makes the document more clear to the reader. In most cases, the algorithm either does not shorten the name or only shortens it slightly. Not using the prefix algorithm can make for some long path statements in a few cases. But I still think the clarity of the full name outweighs the brevity of the shortened names. There are a few cases in standard MIBs where using the prefix algorithm results in different modules using the same prefix to refer to different modules or different prefixes to refer to the same module. That's perfectly legal yang, but I find it a bit confusing. The MIBs defined in RFC 5324 provide good examples that could support either side of this debate. That is, the prefix algorithm results in significantly shorter names, but could be confusing. > > sec. 4: > > SMIv2 modules are mapped to corresponding YANG modules. The YANG > module name MUST be the same as the SMIv2 module name. > > Do you mean the converted module name, according to the algorithm in sec. 3? > No. I see further down this is not the case. I suggest a new section > called Mapping of the Module Name to make this more clear. I didn't think this was unclear. Would it be more clear if the module name translation and imports translation were in different sections instead of the same? > sec 6.1: > > SMIv2 INTEGER enumerations and SMIv2 BITS are mapped to YANG enum > / value and bit / position statements. > > Are these forward slashes typos? (also sec. 8.1) I don't think they are typos, but I also found it confusing when I first read it. Would this be more clear: SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. SMIv2 BITS are mapped to YANG bit/position statements. > sec. 8.3: > > YANG leaf statements of type leafref pointing to the > referenced definition are created. > > then later in 8.5: > > leaf ifIndex { > type leafref { > path "/if-mib:ifMIB/if-mib:ifTable" + > "/if-mib:ifEntry/if-mib:ifIndex"; > } > description > "[Automatically generated leaf for a foreign index.]"; > } > > The text does not mention this automatic description-stmt. > Should the text say this string SHOULD (or MAY) be used? I would suggest removing description from the example. Also, if I understand the rules correctly, the path statement in this and several other examples is wrong. I thought the ifMIB container went around the scalars but not the tables. I actually don't like putting a container around the scalars for a couple of reasons. The first reason is that it gets things out of order from the MIB. In a lot of MIBs, there are several groups which each have several scalars and one or more tables that logically go together. IF-MIB and DISMAN-EVENT-MIB are two good examples. Putting all the scalars together under one container looses that logical ordering. A second reason that an SMIv1 module converted to SMIv2 might have the same module name but a MODULE-IDENTITY added in the SMIv2 version. HOST-RESOURCES-MIB is a good example (rfcs 1514 and 2790). The version without the MODULE-IDENTITY would produce a different path that the version with the MODULE-IDENTITY. Section 5.1 mentions the possibility of a module not having a MODULE-IDENTITY, but does not suggest what to do about the top level container if MODULE-IDENTITY is missing. > > Andy > -David Reid From reid@snmp.com Tue Oct 11 13:53:55 2011 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 B764F21F8E79 for ; Tue, 11 Oct 2011 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BC2hJqKNwVcP for ; Tue, 11 Oct 2011 13:53:55 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 235D421F8E77 for ; Tue, 11 Oct 2011 13:53:55 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA10843 for ; Tue, 11 Oct 2011 16:53:54 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA12845 for ; Tue, 11 Oct 2011 16:53:54 -0400 (EDT) Message-Id: <201110112053.QAA12845@adminfs.snmp.com> To: netmod@ietf.org Date: Tue, 11 Oct 2011 16:53:53 -0400 From: David Reid Subject: [netmod] mib to yang conversion: minor typos 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, 11 Oct 2011 20:53:55 -0000 Here are a few very minor nits in draft-ietf-netmod-smi-yang-01: Section 1, first sentence s/an translation/a translation/ Section 4, first sentence of 2nd paragraph: s/which followed/which is followed/ Section 8.1, first sentence. Also, section 10.1, second bullet: s/""read-create"/"read-create"/ Section 10.2 The description statement for object-1 and object-2 is mission ']'. I think it might be better to just remove the description statement from the example for automatically generated nodes. Section 11: in the alias extension, the argument statement is missing a ';'. -David Reid From reid@snmp.com Wed Oct 12 07:04:02 2011 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 4EB8321F8C7D for ; Wed, 12 Oct 2011 07:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 qYKe-1dNGUxL for ; Wed, 12 Oct 2011 07:04:01 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46121F8BEC for ; Wed, 12 Oct 2011 07:04:01 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA26938 for ; Wed, 12 Oct 2011 10:04:00 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA06302 for ; Wed, 12 Oct 2011 10:04:00 -0400 (EDT) Message-Id: <201110121404.KAA06302@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 12 Oct 2011 10:04:00 -0400 From: David Reid Subject: [netmod] yang ordering 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, 12 Oct 2011 14:04:02 -0000 I accidentally sent this to netconf instead of netmod. This is a resend of the same message... I have 2 questions about ordering in yang. Both questions are related to the mib to yang conversion tool I'm working on. 1. In YANG, does the order in which the leaf objects that are part of the key appear in a list matter? APPLICATION-MIB (RFC 2564) defines: applSrvInstToRunApplElmtEntry OBJECT-TYPE SYNTAX ApplSrvInstToRunApplElmtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "..." INDEX { applSrvIndex, sysApplElmtRunIndex } ::= { applSrvInstToRunApplElmtTable 1 } ApplSrvInstToRunApplElmtEntry ::= SEQUENCE { applSrvIndex Unsigned32 } When I convert to yang, I put sysApplElmtRunIndex in the list before applSrvIndex, which is not the order that they are defined in the MIB INDEX or YANG key. I noticed that smidump also does it this way. Here is the yang produced: list applSrvInstToRunApplElmtEntry { smiv2:oid "1.3.6.1.2.1.62.1.1.3.1"; key "applSrvIndex sysApplElmtRunIndex"; description "..."; leaf sysApplElmtRunIndex { type leafref { path "/sysappl-mib:sysApplElmtRunTable... } } leaf applSrvIndex { smiv2:oid "1.3.6.1.2.1.62.1.1.3.1.1"; type uint32 { range "1..4294967295"; } description "..."; smiv2:max-access read-only; } I believe the yang spec requires that the encoding on the wire puts applSrvIndex first and sysApplElmtRunIndex second. I'm not sure that it matters what order they are in in the yang document. It seems to me that we should agree on an ordering that we all follow, but I'm wondering if it really matters. 2. Does the order in which objects appear in a yang module matter. The IF-MIB defines the following 5 tables in this order: ifTable ifXTable ifStackTable ifRcvAddressTable ifTestTable When I convert to yang, I sort lexigraphically before printing the yang module. That results in the yang table containers or augments in this order: ifTable ifXTable ifStackTable ifTestTable ifRcvAddressTable smidump prints the table containers first followed by the augments, resulting in this order: ifTable ifStackTable ifRcvAddressTable ifXTable ifTestTable Do we need to agree on an order? Or is it OK for different tools to produce a different ordering? -David Reid From mbj@tail-f.com Wed Oct 12 07:14:05 2011 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 7DF4521F8BDE for ; Wed, 12 Oct 2011 07:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 Zgej4UhIKlD0 for ; Wed, 12 Oct 2011 07:14:05 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A75B021F8BB5 for ; Wed, 12 Oct 2011 07:14:04 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EF32E1200089; Wed, 12 Oct 2011 16:14:02 +0200 (CEST) Date: Wed, 12 Oct 2011 16:14:00 +0200 (CEST) Message-Id: <20111012.161400.102420079.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201110121404.KAA06302@adminfs.snmp.com> References: <201110121404.KAA06302@adminfs.snmp.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yang ordering 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, 12 Oct 2011 14:14:05 -0000 Hi David, David Reid wrote: > 1. In YANG, does the order in which the leaf objects that are part of the key > appear in a list matter? No. Section 7.8.2 of RFC 6020 only says: Each such leaf identifier [of a key] MUST refer to a child leaf of the list. The leafs can be defined directly in substatements to the list, or in groupings used in the list. > It seems to me that we should agree on an ordering that we all > follow, but I'm wondering if it really matters. No it doesn't matter, which means it is more a stylistic thing. I don't think the smi2yang spec should require any particular order, when the order doesn't matter. > 2. Does the order in which objects appear in a yang module matter. Not in this case, but the order within an rpc input or output statement matters. > Do we need to agree on an order? Or is it OK for different tools to produce a > different ordering? I think it is ok, since the order does not matter. /martin From bertietf@bwijnen.net Wed Oct 12 07:24:53 2011 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 8CFCC21F8C6E for ; Wed, 12 Oct 2011 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 nHRgimZuVteJ for ; Wed, 12 Oct 2011 07:24:53 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B9E7621F8BA0 for ; Wed, 12 Oct 2011 07:24:52 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RDzjl-0007A7-Ly; Wed, 12 Oct 2011 16:24:51 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RDzjl-0001MS-Hf; Wed, 12 Oct 2011 16:24:49 +0200 Message-ID: <4E95A331.3070003@bwijnen.net> Date: Wed, 12 Oct 2011 16:24:49 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: David Reid , netmod Working Group References: <201110121333.JAA05470@adminfs.snmp.com> In-Reply-To: <201110121333.JAA05470@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4507704f4e8f2967d0065f07e1507c6aa Subject: Re: [netmod] [Netconf] yang ordering 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, 12 Oct 2011 14:24:54 -0000 I suppose that this belongs in the NETMOD WG, not NETCONF Bert On 10/12/11 3:33 PM, David Reid wrote: > I have 2 questions about ordering in yang. Both questions are related to > the mib to yang conversion tool I'm working on. > > 1. In YANG, does the order in which the leaf objects that are part of the key > appear in a list matter? APPLICATION-MIB (RFC 2564) defines: > > applSrvInstToRunApplElmtEntry OBJECT-TYPE > SYNTAX ApplSrvInstToRunApplElmtEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION "..." > INDEX { applSrvIndex, sysApplElmtRunIndex } > ::= { applSrvInstToRunApplElmtTable 1 } > > ApplSrvInstToRunApplElmtEntry ::= SEQUENCE > { > applSrvIndex Unsigned32 > } > > When I convert to yang, I put sysApplElmtRunIndex in the list before > applSrvIndex, which is not the order that they are defined in the > MIB INDEX or YANG key. I noticed that smidump also does it this way. > Here is the yang produced: > > list applSrvInstToRunApplElmtEntry { > smiv2:oid "1.3.6.1.2.1.62.1.1.3.1"; > key "applSrvIndex sysApplElmtRunIndex"; > description "..."; > > leaf sysApplElmtRunIndex { > type leafref { > path "/sysappl-mib:sysApplElmtRunTable... > } > } > > leaf applSrvIndex { > smiv2:oid "1.3.6.1.2.1.62.1.1.3.1.1"; > type uint32 { > range "1..4294967295"; > } > description "..."; > smiv2:max-access read-only; > } > > I believe the yang spec requires that the encoding on the wire puts > applSrvIndex first and sysApplElmtRunIndex second. I'm not sure that > it matters what order they are in in the yang document. It seems to me > that we should agree on an ordering that we all follow, but I'm > wondering if it really matters. > > > > 2. Does the order in which objects appear in a yang module matter. The IF-MIB > defines the following 5 tables in this order: > > ifTable > ifXTable > ifStackTable > ifRcvAddressTable > ifTestTable > > When I convert to yang, I sort lexigraphically before printing the yang > module. That results in the yang table containers or augments in this order: > > ifTable > ifXTable > ifStackTable > ifTestTable > ifRcvAddressTable > > smidump prints the table containers first followed by the augments, resulting > in this order: > > ifTable > ifStackTable > ifRcvAddressTable > ifXTable > ifTestTable > > Do we need to agree on an order? Or is it OK for different tools to produce a > different ordering? > > -David Reid > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From reid@snmp.com Wed Oct 12 12:12:39 2011 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 522E921F8B7D for ; Wed, 12 Oct 2011 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YX5SBabE+kad for ; Wed, 12 Oct 2011 12:12:38 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A73E21F84A3 for ; Wed, 12 Oct 2011 12:12:38 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA25372 for ; Wed, 12 Oct 2011 15:12:35 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA25588 for ; Wed, 12 Oct 2011 15:12:35 -0400 (EDT) Message-Id: <201110121912.PAA25588@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 12 Oct 2011 15:12:34 -0400 From: David Reid Subject: [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, 12 Oct 2011 19:12:39 -0000 I have a few suggestions for ietf-yang-smiv2.yang in draft-ietf-netmod-smi-yang-01: 1. Add an extension to indicate if an index object is IMPLIED. I believe that with this one addition a tool could get all of the MIB information it needs from the converted yang module. extension implied { argument "index"; description "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then the implied statement is present in the yang module and takes as an argument the name of the IMPLIED index object."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } 2. Modify the description clause of the oid extension to allow a more user-friendly format. For example, ifEntry could be written as ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a short hand notation. extension oid { argument "value"; description "The oid statement takes as an argument the object identifier assigned to an SMIv2 definition. The object identifier value is written in dotted decimal notation. If an oid statement exists for the parent object identifier, then the value may be written in a short hand notation of the form . or just .. For example, the oid value for ifTable from IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } 3. The alias extension is a useful addition. I would like to see it mentioned in the body of the document much like the oid extension is mentioned. Here are the suggested changes: Section 7: The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER assignments MAY be translated into smiv2:alias statements, see the YANG extension defined in Section 11. Section 8.6, first paragraph: An OBJECT-TYPE macro invocation defining an augmenting conceptual table MAY be translated into an smiv2:alias statement, see the YANG extension defined in Section 11. The clauses of the macro are translated as follows: o The SMIv2 SYNTAX clause is ignored. o The SMIv2 UNITS clause is ignored. o The SMIv2 MAX-ACCESS clause is ignored. o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current. o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement. o The SMIv2 REFERENCE clause is mapped to the YANG reference statement. o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be translated into an smiv2:oid statement, see the YANG extension defined in Section 11. Section 8.6, second paragraph, add one more bullet: o The name of the SMIv2 OBJECT-TYPE macro invocation MAY be translated into an smiv2:alias statement, see the YANG extension defined in Section 11. 4. With respect to generating the smiv2 extensions, I would prefer MAY to be changed to SHOULD to encourage implementations to include the extensions. -David Reid From biermana@Brocade.com Wed Oct 12 12:17:41 2011 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 53F1F21F8B91 for ; Wed, 12 Oct 2011 12:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] 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 AITX5bwvzTUM for ; Wed, 12 Oct 2011 12:17:40 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id A0DEB21F8B85 for ; Wed, 12 Oct 2011 12:17:40 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p9CJHY3c018460; Wed, 12 Oct 2011 12:17:36 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id 10dgasg0mm-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Oct 2011 12:17:36 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 12 Oct 2011 12:31:18 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 12 Oct 2011 12:17:17 -0700 From: Andy Bierman To: David Reid , "netmod@ietf.org" Date: Wed, 12 Oct 2011 12:17:15 -0700 Thread-Topic: [netmod] ietf-yang-smiv2 Thread-Index: AcyJEuucbILw1W1dRh+gCCJXEwSC0AAADwCg Message-ID: References: <201110121912.PAA25588@adminfs.snmp.com> In-Reply-To: <201110121912.PAA25588@adminfs.snmp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-12_06:2011-10-12, 2011-10-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110120215 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, 12 Oct 2011 19:17:41 -0000 WRT/#2 below: Why do we care about flexibility in a translation tool? I prefer to always have the numeric OID in the smi:oid extension. Why would the translation tool decide .1 if fine here, or ifTable.1 or what= ever? It should just generate the full OID. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= David Reid Sent: Wednesday, October 12, 2011 12:13 PM To: netmod@ietf.org Subject: [netmod] ietf-yang-smiv2 I have a few suggestions for ietf-yang-smiv2.yang in=20 draft-ietf-netmod-smi-yang-01: 1. Add an extension to indicate if an index object is IMPLIED. I believe th= at with this one addition a tool could get all of the MIB information it=20 needs from the converted yang module. extension implied { argument "index"; description "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then=20 the implied statement is present in the yang module and takes as=20 an argument the name of the IMPLIED index object."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } 2. Modify the description clause of the oid extension to allow a more=20 user-friendly format. For example, ifEntry could be written as ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a short hand notation. extension oid { argument "value"; description "The oid statement takes as an argument the object identifier assigned to an SMIv2 definition. The object identifier value is written in dotted decimal notation. If an oid statement exists for the parent object identifier, then the value may be written in a short hand notation of the form=20 . or just=20 .. For example, the oid value for ifTable from IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be=20 '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily,=20 ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } 3. The alias extension is a useful addition. I would like to see it mention= ed in the body of the document much like the oid extension is mentioned. He= re are the suggested changes: Section 7: The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER assignments MAY be translated into smiv2:alias statements, see the=20 YANG extension defined in Section 11. Section 8.6, first paragraph: An OBJECT-TYPE macro invocation defining an augmenting conceptual table MAY be translated into an smiv2:alias statement, see the =20 YANG extension defined in Section 11. The clauses of the macro are translated as follows: o The SMIv2 SYNTAX clause is ignored. o The SMIv2 UNITS clause is ignored. o The SMIv2 MAX-ACCESS clause is ignored. o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current. o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement. o The SMIv2 REFERENCE clause is mapped to the YANG reference statement. o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be translated into an smiv2:oid statement, see the YANG extension defined in Section 11. Section 8.6, second paragraph, add one more bullet: o The name of the SMIv2 OBJECT-TYPE macro invocation MAY be translated into an smiv2:alias statement, see the YANG extension defined in Section 11. 4. With respect to generating the smiv2 extensions, I would prefer MAY to b= e changed to SHOULD to encourage implementations to include the extensions= . -David Reid _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From reid@snmp.com Wed Oct 12 13:32:11 2011 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 6662D21F8C60 for ; Wed, 12 Oct 2011 13:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 8U7BmKjfeM+y for ; Wed, 12 Oct 2011 13:32:10 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5402D21F8C44 for ; Wed, 12 Oct 2011 13:32:10 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA02237; Wed, 12 Oct 2011 16:32:09 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA28314; Wed, 12 Oct 2011 16:32:04 -0400 (EDT) Message-Id: <201110122032.QAA28314@adminfs.snmp.com> To: Andy Bierman From: David Reid In-reply-to: Your message of Wed, 12 Oct 2011 12:17:15 -0700. Date: Wed, 12 Oct 2011 16:32:04 -0400 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: Wed, 12 Oct 2011 20:32:11 -0000 I just think the translated module is more readable with ifTable.1 than 1.3.6.1.2.1.2.2.1 -David Reid > WRT/#2 below: > Why do we care about flexibility in a translation tool? > I prefer to always have the numeric OID in the smi:oid extension. > Why would the translation tool decide .1 if fine here, or ifTable.1 or whatever? > It should just generate the full OID. > > > Andy > > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of David Reid > Sent: Wednesday, October 12, 2011 12:13 PM > To: netmod@ietf.org > Subject: [netmod] ietf-yang-smiv2 > > I have a few suggestions for ietf-yang-smiv2.yang in > draft-ietf-netmod-smi-yang-01: > > 1. Add an extension to indicate if an index object is IMPLIED. I believe that > with this one addition a tool could get all of the MIB information it > needs from the converted yang module. > > extension implied { > argument "index"; > description > "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then > the implied statement is present in the yang module and takes as > an argument the name of the IMPLIED index object."; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } > > > 2. Modify the description clause of the oid extension to allow a more > user-friendly format. For example, ifEntry could be written as > ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a > short hand notation. > > extension oid { > argument "value"; > description > "The oid statement takes as an argument the object identifier > assigned to an SMIv2 definition. The object identifier value > is written in dotted decimal notation. If an oid statement > exists for the parent object identifier, then the value may > be written in a short hand notation of the form > . or just > .. For example, the oid value for ifTable from > IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be > '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, > ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } > > > 3. The alias extension is a useful addition. I would like to see it mentioned > in the body of the document much like the oid extension is mentioned. Here > are the suggested changes: > > Section 7: > > The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for > intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER > assignments MAY be translated into smiv2:alias statements, see the > YANG extension defined in Section 11. > > > Section 8.6, first paragraph: > > An OBJECT-TYPE macro invocation defining an augmenting conceptual > table MAY be translated into an smiv2:alias statement, see the > YANG extension defined in Section 11. The clauses of the macro are > translated as follows: > > o The SMIv2 SYNTAX clause is ignored. > > o The SMIv2 UNITS clause is ignored. > > o The SMIv2 MAX-ACCESS clause is ignored. > > o The SMIv2 STATUS clause is mapped to the YANG status statement. > The generation of the YANG status statement is skipped if the > value of the STATUS clause is current. > > o The SMIv2 DESCRIPTION clause is mapped to the YANG description > statement. > > o The SMIv2 REFERENCE clause is mapped to the YANG reference > statement. > > o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be > translated into an smiv2:oid statement, see the YANG extension > defined in Section 11. > > > Section 8.6, second paragraph, add one more bullet: > > o The name of the SMIv2 OBJECT-TYPE macro invocation MAY be > translated into an smiv2:alias statement, see the YANG extension > defined in Section 11. > > > 4. With respect to generating the smiv2 extensions, I would prefer MAY to be > changed to SHOULD to encourage implementations to include the extensions. > > -David Reid > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From ietf@andybierman.com Thu Oct 13 01:50:26 2011 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 67A6B21F8B72 for ; Thu, 13 Oct 2011 01:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_NAIL=2.3] 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 IIjo8EkTm-+g for ; Thu, 13 Oct 2011 01:50:25 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5B921F87C9 for ; Thu, 13 Oct 2011 01:50:24 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p9D8oLWe024692 for ; Thu, 13 Oct 2011 04:50:23 -0400 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:41591] helo=[192.168.0.6]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7D/E4-04749-D46A69E4; Thu, 13 Oct 2011 04:50:21 -0400 Message-ID: <4E96A64E.1060106@andybierman.com> Date: Thu, 13 Oct 2011 01:50:22 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: David Reid References: <201110122032.QAA28314@adminfs.snmp.com> In-Reply-To: <201110122032.QAA28314@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, 13 Oct 2011 08:50:26 -0000 On 10/12/2011 01:32 PM, David Reid wrote: > I just think the translated module is more readable with ifTable.1 > than 1.3.6.1.2.1.2.2.1 Isn't the source MIB module readable enough? IMO, having a consistent value that can be used as-is by tools is more important, especially for YANG extensions. If the app doesn't know what to expect (1 on N forms) then it has to code for all N, all the time. > > -David Reid Andy > > >> WRT/#2 below: >> Why do we care about flexibility in a translation tool? >> I prefer to always have the numeric OID in the smi:oid extension. >> Why would the translation tool decide .1 if fine here, or ifTable.1 or whatever? >> It should just generate the full OID. >> >> >> Andy >> >> >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of David Reid >> Sent: Wednesday, October 12, 2011 12:13 PM >> To: netmod@ietf.org >> Subject: [netmod] ietf-yang-smiv2 >> >> I have a few suggestions for ietf-yang-smiv2.yang in >> draft-ietf-netmod-smi-yang-01: >> >> 1. Add an extension to indicate if an index object is IMPLIED. I believe that >> with this one addition a tool could get all of the MIB information it >> needs from the converted yang module. >> >> extension implied { >> argument "index"; >> description >> "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then >> the implied statement is present in the yang module and takes as >> an argument the name of the IMPLIED index object."; >> reference >> "RFC2578: Structure of Management Information Version 2 (SMIv2)"; >> } >> >> >> 2. Modify the description clause of the oid extension to allow a more >> user-friendly format. For example, ifEntry could be written as >> ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a >> short hand notation. >> >> extension oid { >> argument "value"; >> description >> "The oid statement takes as an argument the object identifier >> assigned to an SMIv2 definition. The object identifier value >> is written in dotted decimal notation. If an oid statement >> exists for the parent object identifier, then the value may >> be written in a short hand notation of the form >> . or just >> .. For example, the oid value for ifTable from >> IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be >> '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, >> ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; >> reference >> "RFC2578: Structure of Management Information Version 2 (SMIv2)"; >> } >> >> >> 3. The alias extension is a useful addition. I would like to see it mentioned >> in the body of the document much like the oid extension is mentioned. Here >> are the suggested changes: >> >> Section 7: >> >> The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for >> intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER >> assignments MAY be translated into smiv2:alias statements, see the >> YANG extension defined in Section 11. >> >> >> Section 8.6, first paragraph: >> >> An OBJECT-TYPE macro invocation defining an augmenting conceptual >> table MAY be translated into an smiv2:alias statement, see the >> YANG extension defined in Section 11. The clauses of the macro are >> translated as follows: >> >> o The SMIv2 SYNTAX clause is ignored. >> >> o The SMIv2 UNITS clause is ignored. >> >> o The SMIv2 MAX-ACCESS clause is ignored. >> >> o The SMIv2 STATUS clause is mapped to the YANG status statement. >> The generation of the YANG status statement is skipped if the >> value of the STATUS clause is current. >> >> o The SMIv2 DESCRIPTION clause is mapped to the YANG description >> statement. >> >> o The SMIv2 REFERENCE clause is mapped to the YANG reference >> statement. >> >> o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be >> translated into an smiv2:oid statement, see the YANG extension >> defined in Section 11. >> >> >> Section 8.6, second paragraph, add one more bullet: >> >> o The name of the SMIv2 OBJECT-TYPE macro invocation MAY be >> translated into an smiv2:alias statement, see the YANG extension >> defined in Section 11. >> >> >> 4. With respect to generating the smiv2 extensions, I would prefer MAY to be >> changed to SHOULD to encourage implementations to include the extensions. >> >> -David Reid >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From j.schoenwaelder@jacobs-university.de Thu Oct 13 02:12:48 2011 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 D170021F8B11 for ; Thu, 13 Oct 2011 02:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.655 X-Spam-Level: X-Spam-Status: No, score=-101.655 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MANGLED_NAIL=2.3, 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 eaLSAufmwFRU for ; Thu, 13 Oct 2011 02:12:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C121F8AE6 for ; Thu, 13 Oct 2011 02:12:47 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCB5120DDD; Thu, 13 Oct 2011 11:12:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id y1SuyNvZrezs; Thu, 13 Oct 2011 11:12:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46DE520D77; Thu, 13 Oct 2011 11:12:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E21E11B2174E; Thu, 13 Oct 2011 11:12:30 +0200 (CEST) Date: Thu, 13 Oct 2011 11:12:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111013091230.GA23054@elstar.local> Mail-Followup-To: Andy Bierman , David Reid , "netmod@ietf.org" References: <201110122032.QAA28314@adminfs.snmp.com> <4E96A64E.1060106@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E96A64E.1060106@andybierman.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, 13 Oct 2011 09:12:48 -0000 On Thu, Oct 13, 2011 at 01:50:22AM -0700, Andy Bierman wrote: > On 10/12/2011 01:32 PM, David Reid wrote: > >I just think the translated module is more readable with ifTable.1 > >than 1.3.6.1.2.1.2.2.1 > > Isn't the source MIB module readable enough? > IMO, having a consistent value that can be used as-is by tools > is more important, especially for YANG extensions. > If the app doesn't know what to expect (1 on N forms) then it has > to code for all N, all the time. I tend to agree with Andy on this one. And there are tools like smixlate (shipped with libsmi) that scan input for full numeric OIDs and do translations on the fly, that is smidump -f yang --yang-smi IF-MIB | smixlate gives you pretty much what you want (well smixlate could have options such that it yield '.' instead of just ''). In the good old Unix idea of doing things with small dedicated programs and filter pipelines, I believe it is not necessary to build translations into the basic algorithm. And of course, you can always add additional statements if really needed by customers - I think additional statements is actually better than having smi:oid contain sometimes an absolute OID and at other times something different since this makes post-processing much simpler. /js PS: BTW, thanks a lot David for all your really helpful feedback on this document. I will go through all your comments soon when I start revising this document. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From biermana@Brocade.com Thu Oct 13 07:20:03 2011 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 286BA21F8B4B for ; Thu, 13 Oct 2011 07:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-1] 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 bJHnCVMIuUyq for ; Thu, 13 Oct 2011 07:20:02 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 75AEA21F8B46 for ; Thu, 13 Oct 2011 07:20:02 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p9DEESiI010664; Thu, 13 Oct 2011 07:20:00 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id 10du1xg5bp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Oct 2011 07:20:00 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 13 Oct 2011 07:27:31 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 13 Oct 2011 07:19:59 -0700 From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman Date: Thu, 13 Oct 2011 07:19:57 -0700 Thread-Topic: [netmod] ietf-yang-smiv2 Thread-Index: AcyJiElD6kA16ewkQIG2n/jgzBKMUQAKk6BA Message-ID: References: <201110122032.QAA28314@adminfs.snmp.com> <4E96A64E.1060106@andybierman.com> <20111013091230.GA23054@elstar.local> In-Reply-To: <20111013091230.GA23054@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-13_04:2011-10-13, 2011-10-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110130121 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, 13 Oct 2011 14:20:03 -0000 I thought there was an extension proposed already for 'oid' alias. I agree that a separate (optional) extension for the 'FooEntry.1' format is the way to go. Then the app can decide (key difference) which one to use. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Thursday, October 13, 2011 2:13 AM To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 On Thu, Oct 13, 2011 at 01:50:22AM -0700, Andy Bierman wrote: > On 10/12/2011 01:32 PM, David Reid wrote: > >I just think the translated module is more readable with ifTable.1 > >than 1.3.6.1.2.1.2.2.1 >=20 > Isn't the source MIB module readable enough? > IMO, having a consistent value that can be used as-is by tools > is more important, especially for YANG extensions. > If the app doesn't know what to expect (1 on N forms) then it has > to code for all N, all the time. I tend to agree with Andy on this one. And there are tools like smixlate (shipped with libsmi) that scan input for full numeric OIDs and do translations on the fly, that is smidump -f yang --yang-smi IF-MIB | smixlate gives you pretty much what you want (well smixlate could have options such that it yield '.' instead of just ''). In the good old Unix idea of doing things with small dedicated programs and filter pipelines, I believe it is not necessary to build translations into the basic algorithm. And of course, you can always add additional statements if really needed by customers - I think additional statements is actually better than having smi:oid contain sometimes an absolute OID and at other times something different since this makes post-processing much simpler. /js PS: BTW, thanks a lot David for all your really helpful feedback on this document. I will go through all your comments soon when I start revising this document. --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From reid@snmp.com Thu Oct 13 14:19:20 2011 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 0EAEC21F85FF for ; Thu, 13 Oct 2011 14:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 8GkFtJbFPnyl for ; Thu, 13 Oct 2011 14:19:19 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id DB91321F8B66 for ; Thu, 13 Oct 2011 14:19:18 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA08660 for ; Thu, 13 Oct 2011 17:19:11 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA06352 for ; Thu, 13 Oct 2011 17:19:11 -0400 (EDT) Message-Id: <201110132119.RAA06352@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 13 Oct 2011 17:19:10 -0400 From: David Reid Subject: [netmod] mib to yang conversion: type mapping table 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, 13 Oct 2011 21:19:20 -0000 I have a few questions about Table 1 which defines the maping of SMIv2 types to YANG types. 1. OBJECT IDENTIFIER maps to yang:object-identifier. Should it be yang:object-identifier-128? 2. Table 1 maps all the built-in SMIv2 types to yang types or typedefs, which is clearly necessary. It also maps 3 common textual conventions. I was wondering why these 3 where chosen. I guess I would have expected either that more TCs would be mapped (like ZeroBasedCounter32 for example) or none of the TCs would be mapped. I'm not suggesting any changes, just trying to understand the reasoning behind the way it is done. 3. This is related to #2 above. Would it make sense to map TruthValue to boolean since the TruthValue labels (true/false) match the netconf encoding of booleans. 4. I'm not entirely comfortable using DISPLAY-HINT to determine the type. If we didn't use DISPLAY-HINT, we could consider creating mapping rules for some of the well known string-type TCs like DisplayString, Utf8String, SnmpAdminString, etc. Although I don't really like having a lot of special case mapping rules, so I'm not sure this is a good idea. Side note: CHARACTER-MIB (rfc1658) uses DisplayString without importing it. I've seen other MIBs do that with DisplayString. I added a hack to my tool to handle that case. I don't think the document needs to account for broken MIBs, but I thought I'd point this one out since it is in a standard MIB. -David Reid From j.schoenwaelder@jacobs-university.de Fri Oct 14 13:53:36 2011 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 C2DFD21F8D4E for ; Fri, 14 Oct 2011 13:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=0.226, 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 OoSoyldDfzjm for ; Fri, 14 Oct 2011 13:53:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D54AD21F8D4C for ; Fri, 14 Oct 2011 13:53:35 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26B4120E41 for ; Fri, 14 Oct 2011 22:53:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HjAZzuNmaRsK; Fri, 14 Oct 2011 22:53:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CC8520E3F; Fri, 14 Oct 2011 22:53:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AA5F61B24BE3; Fri, 14 Oct 2011 22:53:19 +0200 (CEST) Date: Fri, 14 Oct 2011 22:53:19 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20111014205319.GA32679@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] draft ietf 82 agenda 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, 14 Oct 2011 20:53:36 -0000 Hi, here is a first draft of the agenda for IETF 82: http://www.ietf.org/proceedings/82/agenda/netmod.txt Please send suggestions for agenda changes / additions well in advance of the meeting. /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 Oct 27 09:34:28 2011 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 4EA6221F8B55 for ; Thu, 27 Oct 2011 09:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy6BpCCktyHC for ; Thu, 27 Oct 2011 09:34:27 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BAFE821F8B04 for ; Thu, 27 Oct 2011 09:34:27 -0700 (PDT) Received: from localhost (unknown [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id DB0A412008CD; Thu, 27 Oct 2011 18:34:14 +0200 (CEST) Date: Thu, 27 Oct 2011 18:34:12 +0200 (CEST) Message-Id: <20111027.183412.485760441.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <20110817.235238.347463526.mbj@tail-f.com> References: <000f01cc5120$247432a0$4001a8c0@gateway.2wire.net> <007201cc5185$ebc29580$6801a8c0@oemcomputer> <20110817.235238.347463526.mbj@tail-f.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / 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] LL review of draft-bjorklund-netmod-ip-cfg-00 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, 27 Oct 2011 16:34:28 -0000 Hi, It seems we need the data model to be able to represent non-contiguous masks, so I will add that as described below. Is this applicable to ipv6 as well...? /martin Martin Bjorklund wrote: > "Randy Presuhn" wrote: > > So where does this lead? I think... > > > > If the "contiguous" requirement is merely a SHOULD, then the configuration > > model needs to be able to represent discontiguous ones as well, since > > they are merely discouraged, but not forbidden by the base specifications. > > Otherwise, vendors whose equipment supports the possibility of being > > configured with discontiguous masks will need to resort to proprietary > > models, defeating the purpose of a standard. > > Yes, but if the usage of non-contiguous masks are rare, this might > still be ok. > > This said, if the WG believes we should support this case, we can do: > > choice subnet { > leaf prefix-length { > type uint8 { > range "0..32"; > } > } > leaf netmask { > type inet:ipv4-address; > } > } > > And if we want to be even more advanced, we can do: > > choice subnet { > leaf prefix-length { > type uint8 { > range "0..32"; > } > } > leaf netmask { > if-feature non-contiguous-netmasks; > type inet:ipv4-address; > } > } > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From internet-drafts@ietf.org Fri Oct 28 02:11:54 2011 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 3C9B521F8B02; Fri, 28 Oct 2011 02:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 XisotqclvvYH; Fri, 28 Oct 2011 02:11:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D489B21F86C3; Fri, 28 Oct 2011 02:11:53 -0700 (PDT) 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.62 Message-ID: <20111028091153.10390.42981.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 02:11:53 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-01.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: Fri, 28 Oct 2011 09:11:54 -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 : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-01.txt Pages : 13 Date : 2011-10-28 This document defines a YANG data model for configuration of IP addresses on network interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-01.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-ip-cfg-01.txt From mbj@tail-f.com Fri Oct 28 05:19:58 2011 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 EEC0021F899F for ; Fri, 28 Oct 2011 05:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.310, 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 NxAh8CpK0OZK for ; Fri, 28 Oct 2011 05:19:58 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 63B6C21F86AA for ; Fri, 28 Oct 2011 05:19:58 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BE8501200AD8 for ; Fri, 28 Oct 2011 14:19:55 +0200 (CEST) Date: Fri, 28 Oct 2011 14:19:55 +0200 (CEST) Message-Id: <20111028.141955.488159309.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] ip config issues 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, 28 Oct 2011 12:19:59 -0000 Hi, I have posted a new version (-01) of the ip-config draft. It is now possible to configure non-contiguous netmasks, as discussed previously. There are a couple of other issues, not yet handled. * ip-01 primary, secondary, and preferred address Lada suggested that we need to specify the primary address on an interface, and he pointed to the solution of two router vendors for doing this. Phil sent some links to Juniper's documentation. It seems to be that these two vendors have the same terminology, but different meaning of the term "primary address". In one case it seems to be the source address used for all outgoing packets on the interface, and in the other it seems to be the source address used for outgoing multi- and broadcast (?) packets. Phil also mentioned "preferred address", which seems to be the source address used for outgoing unicast packets on the *subnet* (i.e., there can be one "preferred address" per subnet on an interface (I think)). So it seems there are two concepts here: default source on interface default source in subnet Q. Is my understanding correct? Q. If it is, do we need any, both, or more of these concepts? * ip-02 iv6 auto-link-local-address leaf Lada suggested that maybe there should be a way to tell the server to not automatically assign a link-local unicast address for an ipv6 interface. Q. Is this a useful (and implementable) parameter? /martin From lhotka@cesnet.cz Sat Oct 29 10:25:19 2011 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 DE68321F87C2 for ; Sat, 29 Oct 2011 10:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 c-cEZHJ7iRav for ; Sat, 29 Oct 2011 10:25:19 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBBE21F8505 for ; Sat, 29 Oct 2011 10:25:18 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id A4A852CDE058 for ; Sat, 29 Oct 2011 19:25:17 +0200 (CEST) Message-ID: <4EAC36FD.5010301@cesnet.cz> Date: Sat, 29 Oct 2011 19:25:17 +0200 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] mandatory nodes with when 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: Sat, 29 Oct 2011 17:25:20 -0000 Hi, I have problems with interpreting the following fragment: leaf foo { type boolean; } leaf bar { when "../foo = 'true'"; mandatory true; type uint8; } Now, what if the instance document (datastore) contains true but the element is missing? It is not correct to classify such a document as invalid because the context node for the 'when' XPath expresion (which is 'bar', according to RFC 6020, sec. 7.19.5) doesn't exist in the data tree, so the XPath expression is not well defined and cannot be evaluated. But what is the correct answer? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Sun Oct 30 17:07:24 2011 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 84B0721F8C0C for ; Sun, 30 Oct 2011 17:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 eAnRpQP6oo2L for ; Sun, 30 Oct 2011 17:07:24 -0700 (PDT) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id D333121F8C0B for ; Sun, 30 Oct 2011 17:07:23 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p9V07Kih019125 for ; Sun, 30 Oct 2011 20:07:22 -0400 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:40016] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 44/8D-18857-8B6EDAE4; Sun, 30 Oct 2011 20:07:20 -0400 Message-ID: <4EADE6B7.6090304@andybierman.com> Date: Sun, 30 Oct 2011 17:07:19 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Fwd: I-D Action: draft-bierman-netmod-system-mgmt-01.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: Mon, 31 Oct 2011 00:07:24 -0000 FYI, This version should be reviewed for the NETMOD WG meeting, not -00. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-bierman-netmod-system-mgmt-01.txt Pages : 27 Date : 2011-10-30 This document defines a YANG data model for the configuration and identification of the management system of a device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bierman-netmod-system-mgmt-01.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-bierman-netmod-system-mgmt-01.txt From j.schoenwaelder@jacobs-university.de Mon Oct 31 03:18:09 2011 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 1F4D921F8D18 for ; Mon, 31 Oct 2011 03:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.133 X-Spam-Level: X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 TVzMcnVSmuh0 for ; Mon, 31 Oct 2011 03:18:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 70B5321F8D16 for ; Mon, 31 Oct 2011 03:18:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93C0D20E7D for ; Mon, 31 Oct 2011 11:18:06 +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 UXLngMpmtygH; Mon, 31 Oct 2011 11:18:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DEC820EC9; Mon, 31 Oct 2011 11:18:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 526571B460E7; Mon, 31 Oct 2011 11:17:48 +0100 (CET) Date: Mon, 31 Oct 2011 11:17:47 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20111031101747.GA61858@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] status of the smi to yang update 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: Mon, 31 Oct 2011 10:18:09 -0000 Hi, I am running behind deadlines and hence I won't be able to incorporate all the (IMHO very valuable) comments posted concerning the smi to yang mapping by the I-D cutoff deadline today. I apologize for this. I assume to find time to work through the comments still well before the meeting in Taipei (hopefully this week), so that we can identify any issues that require further discussion on the list before the meeting in Taipei. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103